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: 2) by rleigh on Wednesday February 10 2016, @04:01PM
What's the purpose in such a pointlessly sarcastic comment?
Regarding the example, there's little I could have practically done in the fact of irretrievable data loss. If it's gone, it's gone. Nothing can bring it back. Knowing they had a backup was good for my peace of mind that I wasn't responsible for ruining someone's system. The point is more about what you do to /in response/ to the situation as the developer. In this case, it was fixed quickly and professionally, and the user was in fact pleased that I'd been attentive, responsive and sympathetic to their problem, and happy that it was resolved. They continued to use the tool and also contribute to its development by way of feature requests, testing and patches. I /could/ have been a horrible person, told them it was their own fault, not my responsibility, and closed it as not a bug. And it would have been "technically correct", just like the systemd case here. But it would have been the wrong thing to do. And I'd have most likely lost a user who was quite valuable to the project, as well as making them angry for no reason. Acting like that as a dismissive, disrespectful, arrogant douchbag is no way to run a project and have a good relationship with your users and the wider community. Only people with zero care about the quality of their software and zero empathy would do that, and I would question what they are getting out of developing and maintaining the software it they don't give a damn about the impact of bugs and unexpected behaviour on the people using it. If you were to find a serious problem and report it, I'm sure you'd want the pleasant and productive response, rather than the unnecessarily unpleasant and totally unproductive one.
When I was the Debian sysvinit/initscripts maintainer, if I had ever received a bug report as serious as this one, I certainly would have treated it with the seriousness it deserves: i.e. the greatest. Assuming that we had mounted it r/w in mountkernfs, the default would have been switched and the fixed version would already be uploaded. No arguments about where the responsibility lies and fobbing off our responsibility; if it stops another system from being irreversibly damaged, then you make the change; I'd likely have even written the patches to make the other tools mount and/or remount the filesystem since it's such a severe problem. Sadly, I'm no longer involved in this stuff, as a result of the individuals responsible for the bug in this very article.
What's bizarre is that these people are paid "professionals" working for a major company, and they give worse service than I did as an unpaid but hardworking volunteer! If I gave their treatment to my users in my day job, I'd be disciplined and then fired. It makes me wonder if the management at RedHat actually has any control over what their staff do, especially after previous incidents e.g. the RPM db locking/trashing bug and the maintainer who refused to consider it a bug and fix it, even for paying customers!