An Ubuntu command bricked my system?

I freshly installed Ubuntu on my computer a few days ago to run an exclusive program. I finished with it, and I was about to format the drive to reinstall Windows. However, my little brother wanted to run this command in the terminal on it which would destroy the OS, and I thought that it would not hurt since I would be formatting the drive anyway.

It was this:

sudo rm -rf --no-preserve-root /

Excuse my noobiness if this command is supposed to end the world or something. So it screwed up the OS and I rebooted the PC with the Windows setup USB, planning to format the drive in Windows Setup.

However, upon restart, the monitor was not receiving any input at all. Also, the HDD indicator (or whatever the red light was) wasn't doing one thing. (It was off, in fact.) The fans were working and the DVD drive was, though. (I don't think that there is a PC speaker in there, so if you need some beep error codes, sorry.)

I tried switching the VGA cable from the graphics card to the motherboard, but I still got no input. I tried inserting this old Windows XP disk into the disk drive, but nothing showed up. Mashed the Delete, F12, etc. buttons, but nothing happened. I then looked online and tried a suggestion to reseat the RAM, but nothing changed. I'm thinking of resetting the CMOS manually but haven't gotten to it yet. (Please tell me if you were going to recommend doing so, because I don't want to screw up the PC if I don't have to.)

I have UEFI so I may be able to use a backup chip in case the BIOS is corrupted.

Solution 1:

This is possible on a UEFI system running systemd.

• Phoronix: In A UEFI World, "rm -rf /" Can Brick Your System
• Systemd bug report, source of that article

To summarize, quoting a comment from that bug report:

Point 1:
Deleting /sys/firmware/efi/efivars/ should thrash your EFI configuration, but in a properly implemented EFI this should be recoverable.

Point 2:
There is some pieces hardware out there with broken/poorly implemented EFI, which will can be permanently bricked by doing standard conform stuff to them. See for example the case where Ubuntu bricked some Samsung laptops by storing additional data in some EFI memory. This behaviour was fine by standard but broke this particular implementation.

Point 3:
Running anything as root that writes to /dev/sda will destroy your partition table and/or filesystems. That's bad especially if you have no backup, but after partitioning, creating new filesystems and reinstalling your OS your machine will work again. So you can recover from it by booting some other media and redo your installation.

Point 4:
Thrashing your EFI is a whole different kind of problem. In the worst case you won't be able to do anything with the machine as it will not get to POST. No booting from an other media, no entering some EFI utility to fix missing stuff. A that point your computer is a really expensive paperweight.

The problem occurs in distributions that run systemd and mount efivarfs writeable (at /sys/firmware/efi/efivars). Systemd needs to write there, so distributions using systemd are affected. However, there seems to be no indication that Upstart systems are affected.

Solution 2:

Running the command rm -rf / can brick any UEFI device (including the one I am typing from). Doing this deletes all the files which includes mounted drives and EFI firmware variables (this is what bricks). Linux mounts the EFI variables in /sys/firmware/efi/efivars/, and rm -rf / will delete all the files (EFI variables) in that folder. Your computer is most likely a brick and cannot be fixed (EFI uses NVRAM).

Old BIOS computers do not brick for rm -rf /, because they do not have EFI firmware variables which could be deleted. Also, it is possible to do the same thing (delete all EFI variables) on Windows with a few lines of code.

Solution 3:

There is no way that deleting files would destroy the drive, normally (see my edit at end - apparently, there is a way). The command is the same as entering del -s c:*.* in Windows command line (if my DOS syntax memory is correct). Of course deleting the OS will cause the OS to fail, but nothing more.

If you delete the boot directory along with anything else, even the entire partition, you should still actually get a GRUB prompt. The GRUB bootloader would not get erased because it's not a part of the directory structure, but its menu is, so it should still try to load and give an error.

You have some other problem, and it has nothing to do with Ubuntu. Even if the disk failed, that wouldn't affect the USB or DVD boot process.

EDIT: OK, I think my answer is outdated due to UEFI BIOS, which is something i know little about. Apparently, it is possible to delete critical UEFI configuration information. I believe what happens is that this gets mounted onto the filesystem, and if done incorrectly, will not be read only, and can be erased, thereby erasing it from the BIOS.

Solution 4:

I've had the experience that a Windows Installer media may just hang if your HD is using a format Windows doesn't know about (like ext4).

In this case, you should run a Linux LiveCD with GParted (like this one), and format your hard drive to something like NTFS or FAT32 before trying to install Windows.