Ubuntu – An Ubuntu command bricked the system

command lineuefi

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.

Best Answer

This is possible on a UEFI system running systemd.

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.

Related Question