203

I've often wondered how far the system will actually get if you run rm -rf /. I doubt the OS would be able to erase itself (?)

Bonus Question: After the command has been executed, will rm have removed itself?

Update: I've tested this in a couple of the main unix distributions using VirtualBox and the answers describe exactly what happens. If given the correct parameters, rm will remove every physical bit of data on the disc. However, I ran into some issues when using a version of rm other than the GNU one. For example, I believe BusyBox has their own version and it doesn't let you remove as much as you potentially could.

This question was a Super User Question of the Week.
Read the July 7th, 2011 blog entry for more details or submit your own Question of the Week.

djsmiley2kStaysInside
  • 6,943
  • 2
  • 36
  • 48
nopcorn
  • 16,982

9 Answers9

189

If you have rm from GNU coreutils (most probably if it's a regular Linux distro), rm -rf / will be refused by the built-in protection (according to manpage and Wikipedia, haven't tried that).

You can override this protection with --no-preserve-root. rm will then remove everything it possibly can, without stopping after having attempted to remove every single file. Of course it won't remove virtual filesystems like /proc and /sys, but that's irrelevant – it will remove everything on your disk.

After the command finishes, you disk will be wiped empty, including the OS. The kernel and current processes will continue to run from memory, but many processes will die because they will fail to access some file. The OS will fail to boot next time.

slhck
  • 235,242
Ambroz Bizjak
  • 5,035
42

For those who like to do stuff like this visually while listening to techno music.

Running rm- rf on Linux (video)

Bonus points if you can name the processes as they start dying.

Xeoncross
  • 4,842
22

Set up a VM and try for fun?

It'll go quite far... if you're using a gui you might have fun noticing things degrade more visibly. (icons on menus stop loading etc.)

If you let it go, the OS will pretty much be beyond recovery though you may be able to get some data back easily.

Either way, you'll be wanting to do a reinstall of the OS.

Pricey
  • 4,710
12

Well, trying it on http://bellard.org/jslinux/ produces:

rm: can't remove '/dev/pts': Device or resource busy
rm: can't remove '/dev': Directory not empty
rm: can't remove '/proc/swaps': Operation not permitted
rm: can't remove '/proc/kallsyms': Operation not permitted
rm: can't remove '/proc/dma': Operation not permitted

SNIP 881 entries

rm: can't remove '/proc/149/oom_adj': Permission denied
rm: can't remove '/proc/149': Operation not permitted
rm: can't remove '/proc': Device or resource busy
rm: can't remove '/tmp': Device or resource busy
rm: can't remove '/': Device or resource busy

Community
  • 1
Hello71
  • 8,673
  • 5
  • 42
  • 45
7

I recall this being chewed over on alt.sysadmin.recovery back in days of yore, when there was no such thing as /proc, and /dev was just a regular directory containing entries for a bunch of unusual inodes...

... but, on some variants of Unix (my recollection is HP-UX, but that could be totally wrong), you could not remove the last directory entry for a program that was running. (Shared libraries? What are those?)

On such systems, if you started one up in maintenance mode (so nothing was running but your shell, not even init, and no secondary file systems were mounted) and did exec /bin/rm -rf /, you would be left with a completely empty root file system except that /bin and /bin/rm would survive.

The denizens of the scary devil monastery considered this to be fitting and proper.

zwol
  • 1,268
4

rm -rf / shouldn't be allowed on recent implementations as it has been suggested it violates the POSIX standard:

"rm -rf /" protection on Oracle blog

Anyway, in the end, we got the spec modified, and Solaris 10 has (since build 36) a version of /usr/bin/rm (/bin is a sym-link to /usr/bin on Solaris) and /usr/xpg4/bin/rm which behaves thus:

[28] /bin/rm -rf /
rm of / is not allowed
[29]
Community
  • 1
jlliagre
  • 14,369
3

One point I didn't see made by anyone else: files that are currently open (e.g. rm itself), even if deleted, won't actually disappear fom the drive until closed.

CarlF
  • 8,872
1

For having tried it once (on a server that what pissing me off), logged as root, in terminal, you'll lose almost everything. The only thing that'll not be erased will be only the process that was essential for the OS.

Anarko_Bizounours
  • 280
1

How far you can get, it's basically depend on the specific Unix/Linux distributions.

But to answer your base question, yes - rm command would be removed with it as well as any other standard command in /bin and other folders.

Here is the simple test which I've performed in Linux Ubuntu 15.04 using VM.

  1. Initialize virtual machine via vagrant:

    vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh

  2. Then when you're trying to remove all the files in the standard way, it doesn't let you:

    vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -fr /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

  3. So lets try --no-preserve-root. Always double check you're logged in virtual machine (so you're having vagrant@vagrant-ubuntu-vivid-64:~$), then run (don't try that at home):

    vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -vfr --no-preserve-root /
removed directory: '/lost+found'
removed directory: '/opt'
removed '/bin/nc'
removed '/bin/less'
removed '/bin/wdctl'
removed '/bin/nano'
...
removed '/bin/rmdir'
removed '/bin/sh'
removed '/bin/rm'
...
removed directory: '/bin'
removed directory: '/usr/games'
removed '/usr/bin/byobu-launcher-install'
removed '/usr/bin/ipcmk'
removed '/usr/bin/sum'
removed directory: '/usr/bin'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9.2'
removed '/usr/lib/gcc/x86_64-linux-gnu/5.0.1'
removed directory: '/usr/lib/gcc/x86_64-linux-gnu/5'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libquadmath.so'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libgomp.so'
...
removed directory: '/run/initramfs'
removed directory: '/media'
rm: cannot remove '/proc/fb': Operation not permitted
rm: cannot remove '/proc/fs/ext4/sda1/options': Operation not permitted
...
removed '/vmlinuz'
removed '/boot/config-3.19.0-23-generic'
removed '/boot/grub/grubenv'
...
removed directory: '/boot'
removed '/lib64/ld-linux-x86-64.so.2'
rm: cannot remove '/dev/hugepages': Device or resource busy
rm: cannot remove '/dev/mqueue': Device or resource busy
rm: cannot remove '/dev/shm': Device or resource busy
removed '/dev/vcsa7'
...
removed '/dev/mem'
removed '/dev/rfkill'
removed '/dev/vga_arbiter'
...
rm: cannot remove '/sys/fs/ecryptfs/version': Operation not permitted
removed directory: '/etc'
removed directory: '/mnt'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_provision'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_set_name'
removed '/vagrant/.vagrant/machines/default/virtualbox/creator_uid'
removed '/vagrant/.vagrant/machines/default/virtualbox/id'
removed '/vagrant/.vagrant/machines/default/virtualbox/index_uuid'
removed '/vagrant/.vagrant/machines/default/virtualbox/private_key'
removed '/vagrant/.vagrant/machines/default/virtualbox/synced_folders'
removed directory: '/vagrant/.vagrant/machines/default/virtualbox'
removed directory: '/vagrant/.vagrant/machines/default'
removed directory: '/vagrant/.vagrant/machines'
removed directory: '/vagrant/.vagrant'
removed '/vagrant/Vagrantfile'
rm: cannot remove '/vagrant': Device or resource busy

    After that it gets back to the shell prompt like nothing just happened, but you can't execute any commands anymore apart of few built in and kill, so you can finish your job and kill your session:)

    For example:

    $ rm
rm: command not found
$ kill
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
$ which kill
-bash: /usr/bin/which: No such file or directory
$ kill -9 $$
Connection to 127.0.0.1 closed.

So it pretty removed everything, including rm, ls and all other commands, but still you're logged-in. There are some special folders which weren't removed such as some devices from /dev, /proc or /sys which are aren't regular directories/files, but it's pseudo-filesystem providing interfaces to process and kernel data.

If you don't have Vagrant or Linux, you can play with some JavaScript Linux x86 emulators.

If you're interested in possibilities of recovering from such disaster, check:

Community
  • 1
kenorb
  • 26,615