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

[Steve McIntyre]

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.                                steve at 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