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.
Best Answer
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.