35

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.

Community
  • 1
MirroredFate
  • 467
  • 5
  • 8
  • 10
    Was the UEFI system partition mounted at the time that you ran that command? If it was not then it should not be affected. It is was then you should still be able to boot to the firmware. best GUESS is that it was mounted, that you deleted some bootloader and that the firmware is still set to load only from that. Still, you should be able to enter the firmware. – Hennes May 19 '15 at 17:14
  • @Hennes Yeah, I am pretty sure it was mounted. – MirroredFate May 19 '15 at 21:53
  • What model Dell? – Mark Plotnick May 20 '15 at 00:27
  • @MarkPlotnick XPS8700 – MirroredFate May 20 '15 at 20:46
  • Try resetting the CMOS settings. It's done by moving a jumper; you don't need to remove a battery. Page 84 in http://downloads.dell.com/Manuals/all-products/esuprt_desktop/esuprt_xps_desktop/xps-8700_Owner%27s%20Manual_en-us.pdf. Also can try hitting F2 as soon as it looks like it's finished POST to try to get to a setup screen. – Mark Plotnick May 20 '15 at 21:19
  • @MarkPlotnick Yeah, we've tried that half a dozen times now (the jumper method, that is). Still nothin'. Even stranger, when we boot it without any RAM, the box just spins up as normal. No beeping or blinking. – MirroredFate May 20 '15 at 23:15
  • Interesting question. Though I hope your backup/restore/re-install "workflow" uses something more useful than tarballs. Restoring a system messed up like that should be a matter of re-installing the OS and then restoring the user's home directory and any other data that was backed up. Backups preferably using rsync to a server running zfs or something, making sure you have snapshots as well as a secondary backup. – aseq May 21 '15 at 00:04
  • UEFI is not BIOS, it's a replacement for it. An alternate firmware implementation to handle machine boot-up and early functions. Quite confusing that both the question and the answers seem to use this as alternatives, when the root of the issue actually comes from differences between those two systems. – skolima May 22 '15 at 08:11
  • All the UEFI variables have been deleted and bricked your motherboard – Suici Doga Mar 20 '16 at 11:01

5 Answers5

47

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-root may trigger another kernel bug when traversing and deleting kernel filesystems like /sys, /dev or /proc, that may finally lead to a kernel panic, finally triggering the nonvolatile message memory bug mentioned above.

dronus
  • 1,128
  • 1
  • 13
  • 15
  • 5
    Well, that's depressing. But it's a working explanation, at least. – MirroredFate May 19 '15 at 21:57
  • 4
    For a little more about this, see for example [Dealing with UEFI non-volatile memory quirks](https://mjg59.dreamwidth.org/25091.html) and the earlier [Samsung laptop bug is not Linux specific](https://mjg59.dreamwidth.org/22855.html), both by Matthew Garrett. – user May 20 '15 at 09:38
  • @MichaelKjörling Wow. That goes against everything I would have suspected. – MirroredFate May 21 '15 at 15:58
  • 3
    Can you replace the word "BIOS" with an appropriate word like "firmware" unless you really mean the IBM PC BIOS? This isn't something I'm normally picky about, but in this case you really need to make it clear because you use the words UEFI and BIOS in the same sentence (even next to each other) which is kind of confusing. – user541686 May 22 '15 at 01:22
  • 1
    Replaced. For most people, something that almost still looks like BIOS and feels like BIOS will be BIOS forever... – dronus May 23 '15 at 07:09
27

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.

shodanshok
  • 44,038
  • 6
  • 98
  • 162
  • This has been my understanding. Do you know of any reason to see the behavior I have described? – MirroredFate May 19 '15 at 16:31
  • 1
    I can only imagine that the workstation had flawed hardware and that the (relatively) high load imposed by your untar/delete bring it down. Have to tried to re-seat CPU and memory? Did you try to clear the CMOS? – shodanshok May 19 '15 at 16:37
  • 1
    The memory, yes. Which was weird, because taking out the memory didn't even result in the computer indicating that anything was wrong. Haven't tried re-seating the CPI. Tried clearing the CMOS, but probably should leave the battery out longer. – MirroredFate May 19 '15 at 16:44
  • While true, it is exceedingly rare to really destroy hardware via software alone. A notable exception was in the age of CRTs, where badly programmed timings could destroy CRT's electronics. However, it is not the case here: the very worst thing would be a BIOS / UEFI corruption, which is _not_ hardware destruction in true sense. Moreover, the OP tried another identical disk (with the UEFI partition in place) and it changed nothing. Probably the WS hardware was **already faulty**, and the load imposed by the issued command spelled end for it. – shodanshok May 23 '15 at 10:34
10

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.

Janne Pikkarainen
  • 31,454
  • 4
  • 56
  • 78
  • True. Probably disk GPT for UEFI systems though (no MBR, but GPT partion. And a UEFI system partition which is usually FAT32). – Hennes May 19 '15 at 17:15
  • 1
    I would say running "rm -rf / --no-preserve-root" is only fun in theory. In practice it quits soon enough once some vital library has been removed. – aseq May 20 '15 at 23:59
  • 1
    @aseq Actually in most cases the program and libraries get cached in memory, notice that with linux you can delete a program binary while it is running and it will continue running to completion. This can actually get really quite far. – Vality May 21 '15 at 02:06
  • Yes I know, but at some point it will barf. :-) – aseq May 21 '15 at 05:35
8

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).

Sompom
  • 181
  • 7
  • Although, since you're presumably not getting a "no bootable media" error, dronus's answer may be your solution in this case. I hope not! – Sompom May 19 '15 at 21:13
2

/sys/firmware/efi/efivars is a special file system containing all EFI variables. If the vendor didn't follow best practices, it's possible that your rm -rf wiped important ones and thus confused the firmware.

Waldteufel
  • 21
  • 3