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.

Improve this question
10
  • 8
    It's funny that you asked this question. I was just answering another rm -f question on another forum and started remembering an article I read a while back. Luckily I saved it for times like this: THE classic Unix horror story Besides the fact that it's interesting to see how far it'll go... I think it's a very well written article and is a generally good read!
    – akseli
    Commented Jul 20, 2011 at 13:57
  • 3
    I've just tried sudo rm -rf / on tinycore/microcore linux and it seems that the OS protects several directories (/sys and others) from being deleted.
    – nopcorn
    Commented Jul 20, 2011 at 14:06
  • 48
    I tried rm -f /bin/rm once. Unfortunately, it worked, and I spent the next hour getting the right version of rm back from GNU coreutils.
    – squircle
    Commented Jul 20, 2011 at 17:21
  • 18
    Wait a sec, I will try...
    – Martijn Courteaux
    Commented Jul 20, 2011 at 18:16
  • 40
    I do this at the apple store all the time
    – eggie5
    Commented Jul 21, 2011 at 5:40

9 Answers 9

Reset to default
190

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.

Improve this answer
14
  • 69
    Exactly what I was looking for. Now to use this power TO TAKE OVER THE WORLD.
    – nopcorn
    Commented Jul 20, 2011 at 15:55
  • 36
    +1 especially for --no-preserve-root because that's usually not mentioned.
    – Matěj G.
    Commented Jul 20, 2011 at 18:29
  • 22
    @MaxMackie, it's worth noting that hackers very quickly found this to be the least useful thing they could do to a user. It destroys any data that could be used for cash gains, and prevents the hacker from further exploiting the machine. Like a cat with an insect, you don't want to kill it, you just want to play with it for a while because it's fun.
    – zzzzBov
    Commented Jul 20, 2011 at 21:55
  • 5
    To answer the OP's other question, yes rm will remove itself. It is entirely possible to modify or delete an executable even while there is an instance of it running. It will keep running, too, and will be unaffected by the change.
    – thomasrutter
    Commented Jul 21, 2011 at 4:44
  • 4
    I would like to mention "chmod -R user:user *" at /, because it is also a recursive and costly mistake. I did it once, and had got halfway through /home by the time I could abort. /bin /boot /etc /dev were owned. Fortunately the server kept running while I spent the next few hours manually and resetting ownerships from a reference system. However, noone else could use su or sudo afterwards. Eventually discovered that /bin/su no longer had its setuid bit set. Take note for future: chowning /bin/su resets its setuid bit!
    – Andy Lee Robinson
    Commented Jul 24, 2011 at 20:37
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.

Improve this answer
0
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.

Improve this answer
6
  • 7
    I didn't even think about trying it in a VM. Going to try now! ooo this is fun.
    – nopcorn
    Commented Jul 20, 2011 at 13:53
  • 42
    Mistakenly writes the command to the host system's Terminal
    – slhck
    Commented Jul 20, 2011 at 13:58
  • 1
    Check out the article I posted. "The Classic Unix Horror Story!"
    – akseli
    Commented Jul 20, 2011 at 14:00
  • 1
    I'm at work right now and don't have time to go through a full install of a popular distro (ubuntu/slack/suse/fedora). If anyone else can clone a VM disk file and try it for us, it would be awesome.
    – nopcorn
    Commented Jul 20, 2011 at 14:08
  • 2
    With Amazon EC2 it should be quick to fire up one of their AMI's that already have linux installed and fire away...
    – David d C e Freitas
    Commented Jul 22, 2011 at 19:35
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

Improve this answer
3
  • 1
    Yeah I get those errors/warnings too. Is this standard you think?
    – nopcorn
    Commented Jul 20, 2011 at 14:28
  • 6
    /proc, /sys, sometimes /dev, and any mountpoints are properties of the operating system and can't be deleted.
    – pjc50
    Commented Jul 20, 2011 at 15:35
  • 1
    Concurring with @pcj50, those are not literally files on the hard disk, so "deleting" them is not meaningful.
    – CarlF
    Commented Jul 20, 2011 at 17:11
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.

Improve this answer
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]
Improve this answer
5
  • 2
    "pointing out that if one attempts to remove "/" recursively, one will ultimately attempt to remove ".." and ".", and that all we are doing is allowing rm to pre-determine this heuristically. Amazingly, they bought that! " - er, wouldn't that disallow removing any directory? The actual spec only disallows .. and . in the actual command-line arguments, it doesn't say anything about what you "ultimately attempt to remove"
    – Random832
    Commented Jul 20, 2011 at 16:22
  • 1
    Why would it disallow removing any directory ? The root directory is the only concerned here and removing it obviously imply removing "." and "..", whatever the current directory is. Common sense isn't forbidden in standard interpretation.
    – jlliagre
    Commented Jul 20, 2011 at 20:57
  • 1
    That line of argumentation is pure genius.
    – Nate C-K
    Commented Jul 20, 2011 at 22:09
  • The standard specifies that rm is not allowed to continue if an argument has the string "." or ".." as the basename component. You cannot remove /foo/.. even if you're not in /foo. It does not specify that you're not allowed to remove the current directory (e.g. rm -r `pwd`) or the parent of the current directory.
    – Random832
    Commented Jul 20, 2011 at 22:30
  • 2
    Indeed, I misunderstood the statement and you are correct. Hopefully, the standard guys accepted the smarter behavior as being standard compliant. Removing large parts if not all of the file system would quickly make the OS non standard compliant anyway.
    – jlliagre
    Commented Jul 20, 2011 at 22:44
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.

Improve this answer
11
  • That's right, because they're loaded in memory right?
    – nopcorn
    Commented Jul 20, 2011 at 17:15
  • I'm not sure if that is safe to assume; the kernel could very well just load the removed file into memory and remove it on the disk immediately, and keep this in-memory copy until the file is open (e.g. until rm is running).
    – Ambroz Bizjak
    Commented Jul 20, 2011 at 17:25
  • I'm not speculating. If a program is running, deleting it does not remove it on my Linux boxes, at least. (Mind you I haven't tested this in, oh, a couple of years.)
    – CarlF
    Commented Jul 20, 2011 at 19:25
  • 5
    rm will remove itself from the fs - the program is completely loaded in memory, not the file
    – warren
    Commented Jul 20, 2011 at 19:25
  • 5
    @MaxMackie: not because they're loaded in memory, but because an open file reference have the same power as a hard-link (i.e. if a file has at least one hard link, it won't be deleted from the disk).
    – Lie Ryan
    Commented Jul 20, 2011 at 19:49
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.

Improve this answer
6
  • 12
    "[not erased] only the process that was essential for the OS" - oh, don't worry. Unlike Windows, Linux will happily erase anything, even if the file is OS-critical and in use. /boot, /sbin, /etc, /bin, /vmlinuz? Bam, gone. Good luck booting without those - in fact, good luck doing anything at all once the delete is finished.
    – Piskvor left the building
    Commented Jul 20, 2011 at 16:26
  • If I recall there was some file that wasn't deleted, and I let my linux run for more than 4 hours. But still, it's good to know what happen, like doing a chmod 777 /* -fR ;)
    – Anarko_Bizounours
    Commented Jul 21, 2011 at 7:25
  • 4
    "chmod 777 /* -fR" - That should just make the system very insecure, though very user-friendly.
    – Bart van Heukelom
    Commented Jul 26, 2011 at 18:41
  • 1
    @BartvanHeukelom, some tools will perform a quick self-test, or be tested by the system for proper ownership and permissions and refuse to act if malconfigured.
    – killermist
    Commented Jul 27, 2012 at 12:40
  • 2
    chmod -fR 777 / is harmful because it turns off the setuid and setgid bits.
    – G-Man Says 'Reinstate Monica'
    Commented Jun 17, 2015 at 20:47
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:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .