36

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.

Improve this question
9
  • 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, 2015 at 17:14
  • @Hennes Yeah, I am pretty sure it was mounted.
    – MirroredFate
    May 19, 2015 at 21:53
  • What model Dell?
    – Mark Plotnick
    May 20, 2015 at 0:27
  • @MarkPlotnick XPS8700
    – MirroredFate
    May 20, 2015 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 downloads.dell.com/Manuals/all-products/esuprt_desktop/…. 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, 2015 at 21:19

5 Answers 5

Reset to default
48

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.

Improve this answer
5
  • 5
    Well, that's depressing. But it's a working explanation, at least.
    – MirroredFate
    May 19, 2015 at 21:57
  • 4
    For a little more about this, see for example Dealing with UEFI non-volatile memory quirks and the earlier Samsung laptop bug is not Linux specific, both by Matthew Garrett.
    – user
    May 20, 2015 at 9:38
  • @MichaelKjörling Wow. That goes against everything I would have suspected.
    – MirroredFate
    May 21, 2015 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, 2015 at 1:22
  • 1
    Replaced. For most people, something that almost still looks like BIOS and feels like BIOS will be BIOS forever...
    – dronus
    May 23, 2015 at 7: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.

Improve this answer
4
  • This has been my understanding. Do you know of any reason to see the behavior I have described?
    – MirroredFate
    May 19, 2015 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, 2015 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, 2015 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, 2015 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.

Improve this answer
4
  • 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, 2015 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, 2015 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, 2015 at 2:06
  • Yes I know, but at some point it will barf. :-)
    – aseq
    May 21, 2015 at 5: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).

Improve this answer
1
  • 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, 2015 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.