Dear All, Suppose I executed the command rm -rf / on my CentOS 7 box. After it did what it could, how much damage will be done to what I have (or _had_ rather ;-) on my hard drive? I'm going to describe simple experiment which was prompted in another thread. I need to say a few words before I do it, however. First of all, that other thread was about doing the same thing on UEFI machine. This experiment has nothing to do with UEFI, it was done not with the goal to answer that question for UEFI machine. What I did is this: I took two used drives (same manufacturer, same model, same size). Then on some (pre-UEFI) hardware I kick-start installed Development workstation (whith a bunch of scientific software I install for people in our department). I did this install twice, once of each of drives. Then I booted freshly installed system, went to virtual console, logged in as root, and did: cd / rm -rfv / (yes, I decided to add verbose flag to see things flying away). Guess what? My clever CentOS 7 box told me that I am trying to remove everything from root filesystem, and failed (I know, rm is aliased to "rm -i", that still was not why this happened. Clever!). So, being determined to still attempt to remove everything, I executed the command with an extra option: rm -rfv --no-preserve-root / and finally things started flying away, then the box locked with a bunch of rm: cannot remove "/proc/sys/fs...": permission denied OK, looks like I achieved the goal. I let this "obliterated" box sit for another couple of hours like that. Then I did the only thing you can do in this situation: pulled the power cord. After that was done, I had two drives: one subjected to "rm -rf /" and another not. This is not quite clean experiment as one drive was not a clone of another; kickstart strictly speaking does not guarantee the drives are identical. Also, as experiment is not clean, I decided I will not boot system with second drive at all. Before I go to comparison of two drives I need to tell you that I still partition the drives when I install system, and here how the drive is partitioned (as configured in kickstart file): partition number filesystem 1 /boot 2 /usr 3 / 5 /home 6 swap 7 /var 8 /tmp 9 /data Now, I mounted each of the drives on different machine, and compared them to see what I still have on the drive I tried to obliterate wit "rm -rf /". Here is what I see: / contains on its top level all what it did (plus one more file: core dump!) My /etc lives on root filesystem, so I looked how damaged that is. On "obliterated" drive: find /media/80caeb82-571a-4afe-b3bf-9bce1a35f49a/etc -type f | wc -l 2280 On intact comparison drive: find /media/e2132f68-01a0-4815-aa38-1180ebcd41dc/etc -type f | wc -l 2272 (a few things did not create on comparison drive which I never booted). In general, all seems intact! I have /usr on separate partition, let's see what happened to /usr: On "obliterated" drive: find /media/39766043-9733-4f76-800f-696e604845ff -type f | wc -l 289498 du -s /media/39766043-9733-4f76-800f-696e604845ff 7438636 /media/39766043-9733-4f76-800f-696e604845ff On intact comparison drive: find /media/a3912c30-bf5f-4788-83f7-70756ef4b4ac -type f | wc -l 289498 du -s /media/a3912c30-bf5f-4788-83f7-70756ef4b4ac 7438640 /media/a3912c30-bf5f-4788-83f7-70756ef4b4ac Well, all seems intact again. OK, now: how about stuff that in / comes alphabetically before /dev? First, symlink /bin (pointing to /usr/bin) stayed intact! This is not what I expected, but I'm sure some clever person will explain that. Second, I have two different partitions mounted as /boot and /data. Both of them are gone (though their mount points stayed intact). By no means I am considering myself an expert, but what I see is pretty much what I expected. Namely, the kernel talks to hard drive via block device (or raw device whenever applicable). Therefore, once resembling device is deleted from /dev, there will be no more changes to the content on hard drive platters. So, all in all "rm -rf /" is much less disatrous than it sounds. It only obliterates stuff that every sysadmin can re-create (like /boot or /bin bacl then when it was not symlink to /usr/bin). So, happy "rm -rf /"-ing everybody! I know there are many experts on this list (from whom I constantly learn something!). They probably give much better explanation of what I observed in the experiment I described. Cheers, Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 02/02/2016 04:57 PM, Valeri Galtsev wrote:> Suppose I executed the command > rm -rf / > on my CentOS 7 box. After it did what it could, how much damage will be > done to what I have (or _had_ rather ;-) on my hard drive?In your experiment, rm processed /boot and /data first, and then /proc, where it hung removing one file. There are two important details to consider. First, that behavior doesn't appear to be standard. If I run "rm -rf /proc" on other kernels, rm doesn't hang. On systems running those kernels, rm will remove all of the files in the filesystem hierarchy. Second, on systems running that kernel, no more data was removed because readdir('/') returned /proc before the directories that rm didn't process.> and finally things started flying away, then the box locked with a bunch of > rm: cannot remove "/proc/sys/fs...": permission deniedThe box did not "lock". Press Ctrl+c on the terminal, and rm will exit. What happened is simply that rm tried to unlink a file in /proc, and the syscall didn't return. I'm not sure why that happens, but it doesn't appear to be a feature.> OK, now: how about stuff that in / comes alphabetically before /dev?As I told you before, rm doesn't process directory trees in alphabetical order.> First, symlink /bin (pointing to /usr/bin) stayed intact! This is not what > I expected, but I'm sure some clever person will explain that.I did, in the previous thread.> Second, I > have two different partitions mounted as /boot and /data. Both of them are > gone (though their mount points stayed intact).Directory entry order is in unpredictable. It's not possible to unlink a directory where a filesystem is mounted, which is why the mount point is intact, but its content is gone.> By no means I am considering myself an expert, but what I see is pretty > much what I expected. Namely, the kernel talks to hard drive via block > device (or raw device whenever applicable).That is incorrect, and a much simpler test can verify that. First, rm -rf /dev/*, then remove any file, or write any file. Reboot. Your changes will have been saved, demonstrating that /dev is not required after a filesystem is mounted. Once you've completed that experiment, you can simulate the effect of rm -rf on different kernels by unmounting /proc and then issuing "rm -rfv --no-preserve-root /". When it completes, your filesystem will be empty except for the handful of directories that are used for mount points.> Therefore, once resembling > device is deleted from /dev, there will be no more changes to the content > on hard drive platters. So, all in all "rm -rf /" is much less disatrous > than it sounds. It only obliterates stuff that every sysadmin can > re-create (like /boot or /bin bacl then when it was not symlink to > /usr/bin). So, happy "rm -rf /"-ing everybody!No.
> On Feb 2, 2016, at 17:57, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote: > > Dear All, > > Suppose I executed the command > > rm -rf /There was also this article recently that pointed out that if the box boots via UEFI, you may brick the machine, depending on setup. http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory ? Nate
On Fri, February 5, 2016 1:55 pm, Nathan Duehr wrote:> >> On Feb 2, 2016, at 17:57, Valeri Galtsev <galtsev at kicp.uchicago.edu> >> wrote: >> >> Dear All, >> >> Suppose I executed the command >> >> rm -rf / > > There was also this article recently that pointed out that if the box > boots via UEFI, you may brick the machine, depending on setup. > > http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory >I know, there is separate thread about You trimmed away what I said I purposefully did experiment on NON - UEFI hardware... So, your comment belonges to that other thread, you may want to re-post it as reply to one of the messages of _that_ thread. This thread had actually been closed by one of the experts who dismantled every one of my no-expert statements. However, as far as my experiment is concerned, the fact stayed for me as a fact, namely: we all are scared that that command will leave us loosing everything we have on the hard drive. In my experiment I lost only /boot. Whoever is interested, should be able to find original description of my experiment in list archives. And don't miss the post of an expert! I'm sure both on them will encourage your brain to to do some exercises which always is educational. Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 02/05/16 14:55, Nathan Duehr wrote:> >> On Feb 2, 2016, at 17:57, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote: >> >> Dear All, >> >> Suppose I executed the command >> >> rm -rf / > > There was also this article recently that pointed out that if the box boots via UEFI, you may brick the machine, depending on setup. > > http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory > > ? > NateSo let me get this straight. You are saying that you can make changes to the MB ROM/EPROM/whatever hardware the vendor uses, by issuing an erase command on a hard drive? I'm having a bit of trouble believing that. You might be able to trash the system on the HD to a point that it is unrecoverable. I will believe that. When you're done trashing the system you just have to reinstall the system just like you would with a clean new HD. All that UEFI crap is built into the MB in Read Only hardware. A new HD does not come with any of the UEFI files or directories already on the disk. All that is created at the initial install. Blowing them away with a remove command does nothing to the MB hardware because it's Read Only hardware. -- _ ?v? /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ ****