Hacker News Reader

Comment by andmarios | Hacker News Reader

One day I broke my laptop's boot list, so I went to add a new efi boot entry. I couldn't and thought it was due to my inability to find a proper usb bootable media with efi support since you can't access efi-vars if you boot from bios.

Turns out linux used to store crash-dumps inside efi-vars, so mine were full and new entries couldn't be written. Good thing /sys/firmware/efi/vars/ was mounted rw, thus a `rm -rf /sys/firmware/efi/vars/dump-*` fixed it.

Some kind of protection would be nice, but the ability to see and use efi-vars as a filesystem is useful too. If we listen to security researchers too much, our computers will be no fun.

View on HN

Breaking your laptop's boot list will happen more often with it mounted RW anyway. So it's good it fixed it for you, but I doubt the number of cases it's fixed something/been useful outnumbers the cases where someone bricks their system using what is probably the most repeated Linux command on the internet: rm -rf /.

The reason the efi's boot list was broken was because I wanted to replace a HDD. The laptop has 2 HDDs, I removed them and booted with the new, empty disk for an experiment before adding back my system disk. UEFI thought is was appropriate to remove the non-existing disks' entries from its list and thus I couldn't boot anymore.

Anyway, I don't think this is a systemd bug. The /sys interface comes from the kernel and whether you will access efi vars depends on your kernel configuration. There is the older module (I believe _efivars_ if it isn't compiled as built-in) and the newer (I believe _efivarsfs_).

I've done my fair share of systemd bashing but here we have:

  1. Broken and/or naive EFI implementations
  2. Linux kernel's default choices (expose efivars as rw)
  3. Distro's choices (compile kernel with said modules as built-in)

And we give the fault to systemd. Every other init system out there does the same.

Reply on news.ycombinator.com