Control: severity -1 important Hey Andres,
On Sun, Jul 11, 2021 at 04:19:19PM -0400, Andres Salomon wrote: >Package: grub-efi-arm64 >Version: 2.04-19 >Severity: serious > >I experienced the follow on multiple ARM64 systems (both a Rock64 >board and a Raspberry Pi 4b board) during an unattended-upgrades run: > >Unattended upgrade result: All upgrades installed > >Packages that attempted to upgrade: > shim-helpers-arm64-signed shim-signed shim-signed-common > shim-unsigned ... >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. >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. -- Steve McIntyre, Cambridge, UK. st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
