In order to see approximate speeds for tarballing an entire system, and then restoring that system when if it was foobar'd, I partially cloned one of our primary systems onto a workstation that, while not integral to our company systems, would be nice to have functioning. I timed creating the tarball of the whole system, and inspected it to make sure it looked good.
I then ran rm -rf / --no-preserve-root. I've never had the opportunity to do that before, so it was a lot of fun. At first.
When I rebooted the box, nothing showed up. Not a "Dell" logo, not options for the BIOS, nothing.
I hooked up the drive to a different box, and found to my chagrin that it had a UEFI partition. I assume that my Command of Death effectively hosed that partition.
I hooked up a different, functioning drive to the now defunct workstation, but the workstation still does nothing.
Has anyone seen anything like this, or have suggestions as to what to look for? How did running that rm command manage to so royally mess up the entire box?
UPDATE: We returned the box to Dell. We weren't able to precisely diagnose if it was a coincidence or the situation as described by dronus. However, I will accept dronus' answer as it describes a possible reason why this would happen. Further, it will caution others against doing the same thing in the future. If anyone finds some record of Dell using buggy UEFI, that would be helpful.
One rare possibility could be you triggered some of the infamous UEFI bugs, that already killed some series of Samsung and Lenovo notebooks.
It works like this: UEFI specs propose a non volatile memory (nvram or eeprom) that can be accessed by the OS to store settings or debugging information. Linux actually uses this feature in case of a kernel panic: If the root filesystem is not trusted anymore (eg. after an exception in kernel code), it is switched to read-only. Now the UEFI feature can be used, and debugging information is written to the nonvolatile memory. So far, this sounds like an good idea: The data may be retrieved later and used to explore the crash reasons.
However, with some lines of buggy UEFI firwares, some management routines of the nonvolatile message memory are broken. Depending on the messages, these firmwares crash upon initialization of the message memory, usually quite early on bootup. They may not even reach VGA initialisation, in which case the machine seems totally bricked. In the cases mentioned above, there was no software solution and the mainboards had to be replaced.
Running
rm -rf / --no-preserve-rootmay trigger another kernel bug when traversing and deleting kernel filesystems like/sys,/devor/proc, that may finally lead to a kernel panic, finally triggering the nonvolatile message memory bug mentioned above.No, it is not possible to destroy the BIOS (legacy or UEFI) in this manner with that command.
Even if you somewhat managed to destroy the UEFI partition, core BIOS files will not be affected, as they reside in non-volatile memory (flash-based, mostly) socketed on your motherboard.
UEFI partition hosts additional software components (eg: debugger, driver, ecc), but the machine should boot to BIOS even without a valid UEFI partition.
While fun,
rm -rf /can only break a havoc inside its own little jail -- and that is the partition(s) it is given. It cannot mess up disk MBR, nor it cannot magically destroy your computer.Something else is wrong in your case.
The other answers seem to agree that wiping the BIOS is probably not your problem, so here's another thought:
My computer, when switched into UEFI mode, skips the BIOS screen completely. No manufacturer's logo, no nothing. It just tries to boot and tells me there's no bootable media (or boots).
If I remember the key to enter setup, I can whack it as the computer comes up, and I can still go into the BIOS settings.
If you know the BIOS setup key, you could try hitting it to enter setup, or trust that it is actually working and restore your tar to the disk, then try to boot. It may be faster to use some other some other piece of UEFI bootable media and try to boot that if it's a huge tar (Memtest86 is supposed to support UEFI boot).
/sys/firmware/efi/efivarsis a special file system containing all EFI variables. If the vendor didn't follow best practices, it's possible that yourrm -rfwiped important ones and thus confused the firmware.