On Sun, Jul 11, 2021 at 08:30:36PM -0400, Andres Salomon wrote: >Note: I misspoke in my original report; both boards are rock64 boards,
ACK, thanks for confirming. >there's no pi4 board involved here (it doesn't use EFI). OK. There are options for using EFI on the pi4 too, using a build of edk2 (in case you don't know!). >On Sun, 11 Jul 2021 23:21:56 +0100 >Steve McIntyre <st...@einval.com> wrote: >> >> >Here's the relevant field in /proc/mounts: >> >efivarfs /sys/firmware/efi/efivars efivarfs >> >ro,nosuid,nodev,noexec,relatime 0 0 >> > >> >I expect that the reason /sys/firmware/efi/efivars is mounted >> >read-only is due to bug reports such as the following: >> >https://github.com/systemd/systemd/issues/2402 >> >> But that was never agreed. I'm genuinely curious why you have efivarfs >> mounted read-only, and I don't think it's a supported/supportable >> option here. > >I did not manually set it this way; the boards were installed via >debootstrap/vmdb2 methods with stock bullseye. I had assumed that this >was the default in debian, but it would appear that the kernel itself >doesn't allow mounting it rw: > >dilinger@wifi2:/usr/lib/systemd$ sudo umount /sys/firmware/efi/efivars >dilinger@wifi2:/usr/lib/systemd$ sudo mount -t efivarfs none >/sys/firmware/efi/efivars -o rw >dilinger@wifi2:/usr/lib/systemd$ grep efivar /proc/mounts >none /sys/firmware/efi/efivars efivarfs ro,relatime 0 0 Argh, OK. I'm *guessing* that the driver for it recognises the lack of support for variable writing then. Checking, yes: commit f88814cc2578c121e6edef686365036db72af0ed in the kernel added that last July. >> >It would be preferable for grub to either >> >a) continue the package postinstall despite efivars being read-only, >> >or b) remount efivars read-write, update efivars, and then remount >> >ro. >> > >> >grub-install is being called from shim-helpers-arm64-signed's >> >postinst. You could argue that shim-helpers-arm64-signed could >> >remount efivars read-write, but since I can actually trigger the >> >same error in grub-efi-arm64's postinst, it seems like this should be >> >fixed in grub: >> >> The "issue" is definitely coming from grub-efi-$ARCH, but it's >> behaving as designed here. Continuing despite failing to update the >> EFI boot vars here will potentially leave you with an unbootable >> system. >> > >So yeah, basically given the above info; remounting is unnecessary. Instead, >there needs to be a graceful way for grub-install or the shim packages >to deal with an unwriteable efivarfs. I don't recall grub packages >actually failing (just error messages to console), so we might just >need the shim packages to gracefully fail. Ugh. Checking the grub2 postinst, it uses: run_grub_install() { if ! grub-install $@ ; then echo "Failed: grub-install $@" >&2 echo "WARNING: Bootloader is not properly installed, system may not be bootable" >&2 fi } I guess I'll have to do similar. The problem with that is that people will most likely never notice the error message in the output from apt upgrade. :-( -- Steve McIntyre, Cambridge, UK. st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
