Bug#990966: grub-efi-arm64: breaks upgrades when the efivarfs is mounted read-only

Andres Salomon dilinger at queued.net
Mon Jul 12 01:30:36 BST 2021


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 <steve at 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 at wifi2:/usr/lib/systemd$ sudo umount /sys/firmware/efi/efivars
dilinger at wifi2:/usr/lib/systemd$ sudo mount -t  efivarfs none /sys/firmware/efi/efivars -o rw
dilinger at 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.



More information about the Pkg-grub-devel mailing list