Stories
Slash Boxes
Comments

SoylentNews is people

SystemD Mounts EFI pseudo-fs RW, Facilitates Permanently Bricking Laptops, Closes Bug Invalid

posted by CoolHand on Tuesday February 09 2016, @02:27AM   Printer-friendly
from the why-oh-why dept.

linuxrocks123 writes:

A number of users have reported that running "rm --no-preserve-root -rf /" not only deletes all their files (as expected), but also permanently bricks their computers (which is not). Tracing the issue revealed that the ultimate cause was that SystemD mounted the EFI pseudo-fs as read-write even when this FS was not listed in fstab, and deleting certain files in this pseudo-fs causes certain buggy, but very common, firmware not to POST anymore. A user reported this bug on SystemD's GitHub issue tracker, asking that the FS be mounted read-only instead of read-write, and said bug was immediately closed as invalid. The comment thread for the bug was locked shortly after. Discuss.

Links:
https://github.com/systemd/systemd/issues/2402
http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/

Original Submission

 
This discussion has been archived. No new comments can be posted.
SystemD Mounts EFI pseudo-fs RW, Facilitates Permanently Bricking Laptops, Closes Bug Invalid | Log In/Create an Account | Top | 145 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 0) by Anonymous Coward on Tuesday February 09 2016, @02:26PM

    by Anonymous Coward on Tuesday February 09 2016, @02:26PM (#301419)

    > So the EFI filesystem author says it's not systemd's fault. So what?

    Read the link. Not only does he say it isn't systemd's fault he says it is HIS fault.

  • (Score: 2) by rleigh on Tuesday February 09 2016, @03:59PM

    by rleigh (4887) on Tuesday February 09 2016, @03:59PM (#301474) Homepage

    I know. I think you missed my point. The systemd people should be mitigating the effects of the bug *even though the technical issue is in a separate component*. That's what competent and considerate maintainers do. Their number one priority should be protecting the users of their software from irreversible hardware damage. How disconnected from reality do you have to be to consider passing the buck acceptable? You need to view the problem as systemd's failure to behave well as an integrated part of a wider system, rather than being perfect in isolation. Mitigating the problem irrespective of where the bug lies is their responsibility; they are part of the problem as the party responsible for mounting the filesystem, and they should be part of the solution as well. Not doing so is selfish and inconsiderate, and makes me wonder about their goals and motivations; are they writing this purely for their own gratification, or to serve the needs of their users? Because this is one case where not doing anything makes it clear they don't care about doing the right thing for their users.