Note: I misspoke in my original report; both boards are rock64 boards, there's no pi4 board involved here (it doesn't use EFI).
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 > >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.
