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:
Few takeaways from the above video:
- There is no KA-BOOOM.
- In fact, the system has a really graceful shutdown. Things stop working in the OS one by one — first, the
dfcommand 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
rmcommand can complete it’s execution before the OS stops working entirely. This makes sense because the binary of the
rmprogram (and also
watchfrom the other terminal) is already loaded into memory and deleting
/usr/bin/rmdoes not stop its execution.
rmcommand has a special check to see if the user is performing a recursive operation (
/. If yes, then
rmdisplays a warning and stops the execution. To bypass this, you have to provide the
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
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 ./total_files.sh 2>/dev/null returned:
I won’t be covering
sbin as they are symlinks to same folder names inside the
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/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
So what happens when you delete the
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
ptsfile of your current terminal by entering the command
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/ptmxdevice file to create more
ptsslaves. And since we had just deleted this file (
/dev/ptmx), it fails to open new tabs:
- Other effects of deleting
/devinclude 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 -rto check. Also, you can’t play any audio files. You will be greeted with this message when reading your
Jan 14 16:58:18 localhost.localdomain pulseaudio: 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,
partedfail to find any disks/partitions after deleting the
devdirectory probably because they depended on the hard disk device files (
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.
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.
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.
- 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
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
reboot, etc (*etcetera :D ).
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
gnome-softwaredisplays a blank screen every time I open it because it was unable to create certain cache files that it usually stores in
- Bash’s prompt falls back to:
bash-5.0$(since there is no
.bashrcfile where I define my PS1 value).
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
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
/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
mnt, my OS mounted it inside folder
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.
/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: (CRON) ERROR chdir failed (/root): No such file or direct
Jan 14 18:01:01 localhost.localdomain CROND: (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
/var together because
/var has a folder named
/var/run which is a symbolic link to
/var/run used to be the original directory for storing run-time information of various processes and services. This shift from
/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.
/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:
/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:
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.
run directory contains important run time files needed by a lot of system services. For example, you can find socket files of services like
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:
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
# 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.
/usr/sbincontains all the program binaries that we use. (the difference between
sbincontains binaries that usually require root privileges to run or to perform certain tasks, examples being
mkfs, etc ).
/usr/shareis 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
manpages (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/perl) and other program-specific data.
- Ever played with
cowsay? Its binary is stored in
< moooooo >
/usr/lib64directories 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/includeis 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/includedirectory by default (you can pass the
gccto make it search in other directories too).
/usr/libexecis 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/localhas 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.
/usr/srcis 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
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
netcatprogram to send the output of
journalctlto 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