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 q.kontinuum on Tuesday February 09 2016, @10:44AM
That is a wrong assumption, I think. (Or maybe I'm just not right in my head and project to much :-))
First of all, every newbie screws up his system once in a while, and when I need to re-install anyway I would have considered rm -rf a safe way to let out my frustration. Also I might have tried to see how far it gets before it starts missing the underlying system. I usually would actively encourage my son to try any kind of commands on a system, provided the system is not important and can be wiped/reinstalled without substantial losses.
Second, a script might rely on environment variables to delete subfolders (rm -rf $WORKSPACE/$CCACHE). Such a script without any safeguards (if [ -z $WORKSPACE ]) would be enormously stupid, and anyway disastrous, but should at least not brick the hardware.
Registered IRC nick on chat.soylentnews.org: qkontinuum