Geek Culture
Published in

Geek Culture

Deleting the Root Directory in Your Linux OS

What happens? Well, your OS stops working, obviously.


WARNING: The following stunts were performed by an amateur whose only motive is to quench his curiosity. You have been warned not to perform such stunts in your work PC unless you are looking to add a few (mis)adventures into your life.

We know that the root directory (“/”) stands at the very top of a Linux file-system hierarchy. All the other directories and files that the OS needs for functioning comes under it.

So what happens if you execute sudo rm -rf /? What files get deleted exactly? When and how does the system reach a state where it is no more usable?

If you are in a hurry and just want to see the deletion of the root directory in action and its effect, then here is a 1-minute video for you:

Using a Fedora 33 KVM here, created using virt-manager.

Few takeaways from the above video:

  1. There is no KA-BOOOM.
  2. In fact, the system has a really graceful shutdown. Things stop working in the OS one by one — first, the df command that I had running in the other terminal stops showing its output, then applications disappear from activities followed by icons and wallpaper. After execution of the command, bash is not able to recognise any other command we pass (apart from built-in shell keywords like “echo”). In the end, the entire GUI went off when I attempted to open gnome-settings. Only a black screen remained, displaying an _ cursor blinking.
  3. The rm command can complete it’s execution before the OS stops working entirely. This makes sense because the binary of the rm program (and also watch from the other terminal) is already loaded into memory and deleting /usr/bin/rm does not stop its execution.
  4. The rm command has a special check to see if the user is performing a recursive operation (-r) on /. If yes, then rm displays a warning and stops the execution. To bypass this, you have to provide the --no-preserve-root argument.

Once I reached the black screen, there was no other choice but to “Force Off” the virtual machine. On rebooting it, I was greeted with a Grub Rescue terminal screen. The partitions of the hard disk were still intact. But the main partition which contained the / directory was empty (look at the output of ls (hd0,msdos1)/).

A grub-rescue screen loading up
hd0 is the hard disk. (hd0, msdos1) is the main partition which used to contain the “/” directory. (hd0, msdos2) is the boot partition (or EFI partition in EFI supported systems).

At this point, the system is not usable. One could recover it by using a live USB OS to restore a previous backup of the entire hard disk or by running partition recovery tools like Testdisk.

Going a bit deeper

What I did above was a deletion of the entire file-system. While it was fun to watch, there was not much we could infer/learn from it. So I would like to go a little bit deeper into the subject of Linux file-system by deleting the main sub-directories of "/" one by one and finding out what functionalities the OS loses as a result. Doing this is synonymous to asking “What purpose do each sub-folders in the root directory of a Linux system hold?” or “How is the division of core functionality done in Linux at a file-system level?”.

First, let's have a look at the sub-directories of root:

I wrote a small script to get a fair idea of the total count of files in each directory with the help of rsync. Inspired from this answer in Stackoverflow:

Running this script using sudo ./ 2>/dev/null returned:

I won’t be covering bin, lib, lib64 and sbin as they are symlinks to same folder names inside theusr directory.

NOTE: My test environment is a Fedora 33 workstation KVM (I used virt-manager to create the VM). A snapshot of the VM was taken right after installation. I will be deleting sub-directories of / one at a time, play around and make observations, revert back to the saved snapshot and repeat the same steps again with the next sub-directory. So let’s begin:


The boot directory contains the kernel image (vmlinuz) and other important boot files. Essentially, this is the directory that is accessed for booting of the OS. This helps us understand why we encountered the Grub Rescue screen when rebooting our OS before (after deleting everything with sudo rm -rf / -no-preserve-root) — because there is no kernel for Grub to load at bootup.

Deleting the /boot folder doesn’t affect the running OS as seen below. Problems come up when you reboot it:


If you have been a Linux user for some while then you would have definitely come across Linux’s philosophy of “Everything is a File”. This philosophy extends to hardware devices too — like how your hard disks and its partitions are represented by files /dev/hda[x] (or /dev/nvme[x] for SSDs). This is actually cool, I use this feature of Linux to create a Live Bootable USB using a single command like this:

sudo dd if=./elementaryos-5.1.iso of=/dev/sda bs=4M oflag=sync status=progress

This command writes the data of an Elementary OS ISO file into my pen-drive which is represented by a device file /dev/sda.

So what happens when you delete the /dev directory?

A lot of things actually.

  • First, you will not be able to open a new terminal instance. Whenever you open a new terminal window/tab, a new file (named a number) is created in /dev/pts. You could find out the pts file of your current terminal by entering the commandtty. pts, also called as “pseudo-terminal slave”, is created by your terminal emulator application which is a pty, also called “pseudo-terminal device” (gnome-terminal in my case). Terminal emulators are the masters that need to open the /dev/ptmx device file to create more pts slaves. And since we had just deleted this file (/dev/ptmx), it fails to open new tabs:
  • Other effects of deleting /dev include not being able to open a GUI application. It may or may not lead to a system crash and show a lot of different error messages when you enter journalctl -r to check. Also, you can’t play any audio files. You will be greeted with this message when reading your journcalctl logs:
Jan 14 16:58:18 localhost.localdomain pulseaudio[1661]: Error opening PCM device front:0: No such file or directory

(PCM stands for Pulse-Code Modulation. PCM device here probably refers to your system’s sound card.)

  • A lot of programs depend on these device files to get information and display it to users. Removing those files means these programs also become useless. For example, fdisk -l and parted fail to find any disks/partitions after deleting the dev directory probably because they depended on the hard disk device files (/dev/hda[x]):

That said, deleting the dev directory is not as catastrophic as it might look like. Its because this directory and all of its files are created/modified by the kernel or it’s modules every time you boot up your OS. So after you delete the dev directory, you just need to force-reboot your machine, and voila! The dev directory and all its files that you had removed earlier are back and your system works completely fine.


The etc directory essentially contains configuration files used by system application and other programs to function properly. You can only find static files in here and no binaries.

Deleting the etc directory means all the programs that depend on their configuration files when called from the shell fail to function. Example, journalctl command returns “No journal files were found.”. This is because the configuration file /etc/systemd/journalctl.conf contains a lot of configuration information required by journalctl to startup and manage the logs. Not having this information prevents it from starting normally. Several other programs like iptableswill face similar problems.

There is also /etc/fstab, the files which contain details about the disks and filesystem that the OS needs to mount on bootup. I deleted /etc/fstab (and not /etc) to see how Fedora fared without it. When I rebooted the VM, things were working a bit weird:

  • Fedora showed me a welcome screen and asked me to set up my new user account and password. This is the same screen you get when you install Fedora for the first time.
  • After set up, there was no “Activites” button at the top right corner, neither were there any options of “Settings”. Pressing meta-key (the windows key) didn’t open anything. Basically, I was stuck not being able to open anything.
There is no “Activities” menu or “Settings” button (“Wired Connected” did not have any menu inside). Pressing keys don’t open anything either.
  • I pressed Ctrl+Alt+F2, to open a virtual terminal, and luckily things seemed to work fine here. I couldn’t find any error logs in journalctl.

I was actually expecting the system to never boot up in the absence of fstab file, but somehow it did and showed a lot of strange behaviours.

Probably the most significant problem when deleting etc directory is the removal of /etc/passwd file which stores information of all user accounts in your system. So if you were to log-out/shutdown your system after the current session, you will never be able to log-in again. In fact, my Fedora wasn’t able to reach the log-in screen after a forced-reboot (The OS removed all shutdown options immediately after deleting /etc/passwd, so “Force-off” was the only option). Deleting the /etc/passwd file also prevents you from doing a lot of things in the current session itself. You can’t use ssh, scp, sftp, rsync commands. Since /etc/passwd is the file that contains the “sudoers” list (users with sudo privilege), deleting it now prevents you from using sudo or any root log-in sessions. So any command that needs you to run as sudo fails— like tcpdump, fdisk, parted, reboot, etc (*etcetera :D ).


Deleting the home directory fails because it’s marked as a disk mount point in Fedora. So using rm command aborts with the message: rm: cannot remove '/home': Device or resource busy.

But that doesn’t matter. You should be able to delete everything else inside the home folder, and that should be enough for us to test out the adverse effects of the absence of user directories.

Surprisingly a lot of applications fail to start without the user directories.

  • Certain gnome applications depend on storing data in the user directory.
  • Firefox never opens as it is dependent on the config files and data it stores in /home/username/.mozilla folder.
  • gnome-software displays a blank screen every time I open it because it was unable to create certain cache files that it usually stores in /home/username/.cache/gnome-software/ folder.
  • Bash’s prompt falls back to: bash-5.0$ (since there is no .bashrc file where I define my PS1 value).
Firefox and Rythmbox fail to start

The absence of user directory is not as bad as above covered directories since the OS never crashed ( I could be wrong though since I did my tests on a fresh installation of Fedora with no extra applications installed. With more programs, more problems could arise).


This is the directory where corrupted or incorrectly deleted files are recovered and stored from file-system checks by fsck. I have never found any recovered files here in my experience with Linux (that said, I never had many situations to perform fsck checks in the first place). Deleting this folder didn’t really affect my OS.

/media and /mnt

media and mnt are the two directories where users mount hard-disks or removable devices. Their sole purpose is to serve as mount-points for other storage devices. You can’t delete these folders if any storage device is mounted on them as rm will return a “Device or resource busy” error. So you have to first unmount those devices.

Absence of these folders doesn’t really affect a normal user unless you have a fstab entry where some hard disk is set to mount in /mnt or /media at bootup (speaking from my experience, wrong entries in fstab could actually be a really nasty problem). It’s also to be noted that whenever you plug in a pen-drive, the OS mounts it by default inside the /media directory. So I’m not sure if you can stay problem-free without having these two directories. When I tried to connect a pen-drive after removing both media and mnt, my OS mounted it inside folder /run/media.


This directory is reserved to store data related to user-installed applications. As my test environment is a fresh Fedora 33, the opt directory is empty. My working operating system contains data stored by applications like brave, docker, zoom and packet tracer. So it should be obvious that deleting the opt directory means these applications will surely malfunction.


The /proc directory can’t be deleted. Even if you log in as root. The “files” in this directory are created/modified at bootup and removed from memory when shutdown by kernel since it completely depends on the state of the system — like what processes are running and what modules are loaded. A lot of programs depend on proc for providing system or process information. I would highly recommend exploring this directory and simply cat all possible files and find out what information you can get.


This is the “home” directory of the root account. It contains config files which will be used when the root account is logged into. This includes separate .bashrc, .profile files, and other application-specific config files (inside /root/.config) like those used by wireshark, an external application, which can only be run by a root account. Deleting this folder changes the way prompt looks into a simple bash-5.0#. In my work OS, snap had placed a folder inside /root containing snap-installed application’s data. I didn’t see any system changes when I deleted the root folder. When checking journalctl for any related errors, I found this:

Jan 14 18:01:01 localhost.localdomain CROND[31729]: (CRON) ERROR chdir failed (/root): No such file or direct
Jan 14 18:01:01 localhost.localdomain CROND[31729]: (root) CMD (run-parts /etc/cron.hourly)

This gives us a lead. cron jobs always run from the user’s environment (i.e, the current directory when they run a cron job is the user’s home directory). For cron jobs set by the root user (using sudo crontab -e), it needs to go to the root directory and execute the cron jobs from there. But now it seems like root’s cron jobs aren’t able to execute due to the absence of root folder. To confirm this I tried to run a cron job every minute from root user’s account:

sudo crontab -e# Inside the crontab file:
* * * * * echo "yolooo" > /tmp/trial # this runs every minute

And I was right, the file/tmp/trial was never created. This showed us that cron jobs (of root) fail to start when you delete the root folder. This is just one problem that I found, there should be a lot of other applications that depend on the root folder’s existence to function.

/run and /var

I’m taking /run and /var together because /var has a folder named /var/run which is a symbolic link to /run. /var/run used to be the original directory for storing run-time information of various processes and services. This shift from /var/run to /run was done for better organization of data.

/run is mounted in most OS as tmpfs, which is a special type of file-system that stores data only in the volatile memory (RAM/swap). Therefore the data in /run is not persistent and lost on system shutdown.

tmpfs filesystem of “/run”

/var, which stands for “variable”, contains state information of process and applications that are prone to change depending on the state of the running application/process. The journalctl log files are stored either in /run/log/journal/<machine-id>/*.journal or inside /var/log/journal/<machine-id>/*.journal. A lot of other application log files are stored in /var/log/ directory (eg apache, lib-virt, nginx, cups, etc).

/var also stores information about your OS package manager. In Fedora, you can find databases in /var/lib/dnf/ containing information about installed rpm packages, history, repos, etc. Without these files, dnf simply fails to install anything:

Note how `dnf` doesn’t look up any other default repositories.

Similarly the /var/lib directory contains a lot of state information of many running applications and services. Deleting this folder in a fresh installation of Fedora result in immediate failure of two services:

Output of `systemctl -failed`

Surely, with more applications and daemons installed, more services are bound to fail. Apache web server, by default, serves web pages placed in /var/www/html. There is also a /var/cache directory where certain application cache data is stored.

The run directory contains important run time files needed by a lot of system services. For example, you can find socket files of services like cups, dbus, udev, etc. systemd has a folder in /run to store its run-time information. Every time I deleted the /run/systemd folder, my screen froze and system hanged. This basically means removing /run results in systemd crashing and you know that your system isn’t usable when PID 1 has stopped working. There was this one attempt of deleting the /run directory where the screen froze 10 seconds after deletion, so I had time to run systemctl status. Here is the output:

systemd-failure message

Well, we just removed systemd from the RAM, so it makes sense.


This folder contains specific data related to a service that your system is providing. An example could be some data related to ftp service being stored in this folder for a running FTP server in the system. I have never seen this directory populated with any data in my usage. Deleting this empty directory in my Fedora caused no issues because there was no service using it for any purpose.


This is probably the coolest sub-directory in /. Just like proc, it is another virtual file-system which contains information and provides an interface for the user to interact/configure the devices attached to the system. The “files” (these are not actual files stored in hard disk) in this directory are essentially just information of various devices, stored in RAM.

My laptop has certain heat issues. To reduce the load on battery and prevent CPU bursts which result in high temperature during heavy load, I disable Intel Turbo Boost by editing a file in /sys:

# run this as root. Ain't this simple?
$ echo "1" | tee /sys/devices/system/cpu/intel_pstate/no_turbo

/sys directory and it’s contents are not removable. Even when logged in as root. The data in this directory are lost when the system shuts down (volatile memory data) and re-created at bootup depending on all the devices that OS can find.


tmp stands for “temporary” and that should explain what purpose this directory serves — to store temporarily required files. This is another directory which is mounted as a tmpfs file-system. The contents of this directory are deleted during shutdown and are not persistent. Deleting the contents of tmp didn’t raise any problems in my Fedora. The journalctl logs were quiet too. You can’t delete the directory because it is marked as “busy” since it’s a tmpfs mount point.


We finally come to the usr directory which contains the largest portion of the data and programs that comprise our working OS.

  • The /usr/bin and /usr/sbin contains all the program binaries that we use. (the difference between /usr/bin and /usr/sbin is that sbin contains binaries that usually require root privileges to run or to perform certain tasks, examples being fdisk, insmod, fsck, mkfs, etc ).
  • /usr/share is the largest sub-directory in /usr. Its main purpose is to contain data and files that are not hardware-architecture dependent thus allowing them to be “shareable” across different devices. This includes a variety of different files like the ever-reliable man pages (found in /usr/share/man ), icons (inside /usr/share/icons/ , source code of certain libraries of different programming languages ( you can find Jquery source code inside /usr/share/javascript/jquery/. There is also a lot of Perl code inside /usr/share/perl ) and other program-specific data.
  • Ever played with cowsay? Its binary is stored in /usr/games/cowsay.
< moooooo >
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
  • The /usr/lib and /usr/lib64 directories primarily contain object files (compiled C code) and other code/data which will be used as libraries by different applications installed in the system. These are not meant to be executed by users directly. All the kernel modules and drivers are installed into the /usr/lib/modules/<kernel-version>/ directory.
  • /usr/include is the directory that contains C header files. For example, when you write #include <stdio.h> in your C program, then the compiler looks for the file inside /usr/include directory by default (you can pass the -I argument to gcc to make it search in other directories too).
  • The /usr/libexec is a relatively new implementation in Linux operating systems which allows certain binaries to be stored in a way to express that they are not meant to be executed by users directly and are only used internally by various services/programs installed in your system.
  • /usr/local has the same internal directory structure as it’s parent /usr. This directory is where user compiled software and external application should be installed. Data related to such applications are also stored here.
  • The /usr/src is where source code of the kernel is usually stored (In Fedora 33, this directory is empty).

An operating system is useless by itself. We, users, use programs to do our work and the OS provides us with a platform to run these programs. Deleting the /usr directory leaves us with no programs to run. I tried to save a copy of /usr/bin/journalctl to a separate directory so that I could run it from the same terminal where I run my sudo rm -rfv /usr command after its execution (as this terminal is currently loaded in memory, it should be able to work fine and run another binary I pass, right? ). But turns out, after deleting /usr, when I ran /copied-path-to/journalctl, bash wasn’t able to understand what I wrote:

This could mean that bash is not able to parse anything that we pass it (and that it uses sed every time we pass an input command?). The only thing that bash was able to run at this point were shell-builtin commands, like echo.

So, even our shell which is loaded in memory isn’t able to do anything significant with no other programs and libraries available. At this point, there wasn’t much I could do to play around and get more information. The system also crashes a short while after deleting /usr, displaying just a black screen.

And that marks the end of our experiments. I would like to conclude this article with a few end-points that could be of some use/interest to the reader:

  • Sometimes deleting a sub-directory would instantly lead to GUI of the system to freeze (I wasn’t able to open a second virtual terminal too). This made it impossible to see the real reason for the crash since I couldn't refer the system logs. For this purpose, I would establish a simple TCP connection between my guest VM (Fedora) and host (Ubuntu) using the netcat program to send the output of journalctl to host so that I can read what’s going on even if the screen freezes. The commands I used:
#In host PC
$ nc -l 6767 #host listens in port 6767
#In guest vm, from a terminal tab, before I proceed with deleting anything:
$ watch -n 1 journalctl -r | nc <host pc IP> 6767



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Atul Gopinathan

Atul Gopinathan

A CS undergraduate with keen interest in Linux and new technology.