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

[Steve McIntyre]

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 <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

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