4 ms·

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 me

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.

milkey_mouse 11y ago
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 /.
- andmarios 11y ago
  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.

milkey_mouse 11y ago

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 /.

andmarios 11y ago
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.