SoylentNews is people
SoylentNews
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/
(Score: 4, Insightful) by rleigh on Tuesday February 09 2016, @08:48AM
So the EFI filesystem author says it's not systemd's fault. So what? As a software developer, I have to deal with buggy and broken behaviour in my dependencies, and work around stuff which "wasn't my fault" all the time. systemd doesn't get a free pass by being "technically correct" and yet totally failing to provide a safe and robust implementation. Yes, the EFI and the EFI filesystem are broken. But systemd should still be taking pains to mitigate the impact by working around this (mounting it r/o by default, not mounting it by default, whatever). Just brushing it under the rug and pretending that a really serious problem is a "not my responsibility" is a perfect demonstration of the wrongheaded attitude of the systemd developers, and why many of us do not trust these imbeciles to have complete control over the whole Linux system. Their goal does not appear to be maintaining a safe, secure and robust system; this isn't the first time they have fobbed off their responsibilities onto others.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @02:26PM
> 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
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.