Bug#990867: shim-helpers-arm64-signed: post-install script fails with 'error exit status 1'

[Diederik de Haas]

Package: shim-helpers-arm64-signed
Version: 1+15.4+6
Severity: important

Running 'aptitude safe-upgrade' on my Bullseye/Sid/Experimental system
fails:

Unpacking shim-unsigned (15.4-6) over (15.4-5) ...
Preparing to unpack .../3-shim-helpers-arm64-signed_1+15.4+6_arm64.deb ...
Unpacking shim-helpers-arm64-signed (1+15.4+6) over (1+15.4+5) ...
Preparing to unpack .../4-shim-signed-common_1.37+15.4-6_all.deb ...
Unpacking shim-signed-common (1.37+15.4-6) over (1.36+15.4-5) ...
Preparing to unpack .../5-shim-signed_1.37+15.4-6_arm64.deb ...
Unpacking shim-signed:arm64 (1.37+15.4-6) over (1.36+15.4-5) ...
Setting up libuv1:arm64 (1.40.0-2) ...
Setting up shim-signed-common (1.37+15.4-6) ...
No DKMS packages installed: not changing Secure Boot validation state.
Setting up udev (249-1) ...
Setting up python3-urllib3 (1.26.5-1~exp1) ...
Setting up shim-unsigned (15.4-6) ...
Setting up shim-helpers-arm64-signed (1+15.4+6) ...
Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.
grub-install: warning: efivarfs_set_variable: failed to open /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c for writing: Read-only file system.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Read-only file system.
grub-install: error: failed to register the EFI boot entry: Read-only file system.
dpkg: error processing package shim-helpers-arm64-signed (--configure):
installed shim-helpers-arm64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of shim-signed:arm64:
shim-signed:arm64 depends on shim-helpers-arm64-signed (>= 1+15.4+2); however:
Package shim-helpers-arm64-signed is not configured yet.

dpkg: error processing package shim-signed:arm64 (--configure):
dependency problems - leaving unconfigured
Setting up systemd (249-1) ...
Setting up systemd-timesyncd (249-1) ...
Setting up systemd-sysv (249-1) ...
Setting up libpam-systemd:arm64 (249-1) ...
Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.47-rock64-00005-g0df86ccf5feb
W: Possible missing firmware /lib/firmware/renesas_usb_fw.mem for built-in driver xhci_pci
W: Possible missing firmware /lib/firmware/r8a779x_usb3_v3.dlmem for built-in driver xhci_plat_hcd
W: Possible missing firmware /lib/firmware/r8a779x_usb3_v2.dlmem for built-in driver xhci_plat_hcd
W: Possible missing firmware /lib/firmware/r8a779x_usb3_v1.dlmem for built-in driver xhci_plat_hcd
W: Possible missing firmware /lib/firmware/nvidia/tegra194/xusb.bin for built-in driver xhci_tegra
W: Possible missing firmware /lib/firmware/nvidia/tegra186/xusb.bin for built-in driver xhci_tegra
W: Possible missing firmware /lib/firmware/nvidia/tegra210/xusb.bin for built-in driver xhci_tegra
W: Possible missing firmware /lib/firmware/nvidia/tegra124/xusb.bin for built-in driver xhci_tegra
I: The initramfs will attempt to resume from /dev/sda1
I: (UUID=d97f0a17-fc61-403c-92f3-af5e2a7b33f8)
I: Set the RESUME variable to override this.
Processing triggers for libc-bin (2.31-12) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for dbus (1.13.18-2) ...
Errors were encountered while processing:
shim-helpers-arm64-signed
shim-signed:arm64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up shim-helpers-arm64-signed (1+15.4+6) ...
Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.
grub-install: warning: efivarfs_set_variable: failed to open /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c for writing: Read-only file system.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Read-only file system.
grub-install: error: failed to register the EFI boot entry: Read-only file system.
dpkg: error processing package shim-helpers-arm64-signed (--configure):
installed shim-helpers-arm64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of shim-signed:arm64:
shim-signed:arm64 depends on shim-helpers-arm64-signed (>= 1+15.4+2); however:
Package shim-helpers-arm64-signed is not configured yet.

dpkg: error processing package shim-signed:arm64 (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
shim-helpers-arm64-signed
shim-signed:arm64

If the issue is in grub/grub-efi-arm64, feel free to reassign.

I've had this problem before and at some point found a fix/workaround,
but I wasn't smart enough to write that down.
I know that now every aptitude safe-upgrade will give me this error :-/

$ ls -l /sys/firmware/efi/efivars/
total 0
-rw-r--r-- 1 root root 5 1 jul 23:55 AuditMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 124 1 jul 23:55 Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 6 1 jul 23:55 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 6 1 jul 23:55 BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 5 1 jul 23:55 DeployedMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 12 1 jul 23:55 OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 10 1 jul 23:55 PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 10 1 jul 23:55 PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 5 1 jul 23:55 SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 5 1 jul 23:55 SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 5 1 jul 23:55 VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c

I have no idea what caused the 'Read-only file system' message.

While I'm now running an upstream kernel with a few patches for the
Rock64 device, I'm quite certain it happened previously with the Debian
kernel, so I'll assume that would happen now too.
If it's relevant at all.

Cheers,
Diederik

-- System Information:
Debian Release: 11.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'), (101, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.47-rock64-00005-g0df86ccf5feb (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages shim-helpers-arm64-signed depends on:
ii shim-unsigned 15.4-6

shim-helpers-arm64-signed recommends no packages.

shim-helpers-arm64-signed suggests no packages.

-- no debconf information

[Steve McIntyre]

Control: reassign -1 grub-efi-arm64

(ish)

Hi Diederik,

Right,

The maintainer scripts for the shim-signed packages now explicitly
calls grub-install to make sure that shim is added/removed from the
boot chain as appropriate. The errors you're seeing are from
grub-install, and that's where the problem is showing up.

AFAICS grub-install is failing to update due to the *real* underlying
problem, which is that your platform is running firmware which
implements UEFI but that UEFI support isn't working for writing UEFI
boot variables. You're using U-Boot, I assume?

So, here's a few thoughts:

1. To stop your machine failing here, do a "dpkg-reconfigure
grub-efi-arm64" and say "yes" to the removable media path question
and "no" to the "update boot variables" question. That should
solve the immediate problem for you - please shout if it doesn't!

Fixing this in the *general* case is hard. We could add code to
fall back to *not* updating UEFI boot variables if that fails, but
that's likely going to be error-prone and cause trouble on
machines where that *should* work but it fails on a temporary
basis. Instead, I suspect we may need to replicate similar
functionality to flash-kernel and have a list of "quirky" machines
where we *don't* expect UEFI boot variables to work. That's messy as
all hell, but I'm not sure of a better option. :-/

2. To the best of my knowledge, none of the current U-Boot releases
support Secure Boot so you may as well remove the shim-signed
package anyway. It's normally harmless to include it (so we pull
it in via recommends), but on your system it's not going to do
anything for you so you may as well remove it.

OK?

--
Steve McIntyre, Cambridge, UK. st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
Privacy is an inherent human right, and a requirement for maintaining
the human condition with dignity and respect."
-- Bruce Schneier

[Steve McIntyre]

On Sun, Jul 11, 2021 at 04:39:20PM +0200, Diederik de Haas wrote:

>On zondag 11 juli 2021 02:31:19 CEST Steve McIntyre wrote:
>>
>> AFAICS grub-install is failing to update due to the *real* underlying
>> problem, which is that your platform is running firmware which
>> implements UEFI but that UEFI support isn't working for writing UEFI
>> boot variables. You're using U-Boot, I assume?
>

>Yes, u-boot-rockchip to be exact. The base image for my rock64 is made using
>the .yaml file from https://salsa.debian.org/diederik/rock64

>
>> So, here's a few thoughts:
>>
>> 1. To stop your machine failing here, do a "dpkg-reconfigure
>> grub-efi-arm64" and say "yes" to the removable media path question
>> and "no" to the "update boot variables" question. That should
>> solve the immediate problem for you - please shout if it doesn't!
>

>Yeah! That fixed it, thanks :-)

\o/

>> Fixing this in the *general* case is hard. We could add code to
>> fall back to *not* updating UEFI boot variables if that fails, but
>> that's likely going to be error-prone and cause trouble on
>> machines where that *should* work but it fails on a temporary
>> basis. Instead, I suspect we may need to replicate similar
>> functionality to flash-kernel and have a list of "quirky" machines
>> where we *don't* expect UEFI boot variables to work. That's messy as
>> all hell, but I'm not sure of a better option. :-/
>

>There was recently a thread on debian-arm ML about questions to ask to ARM and
>the general trend was "can we please get some (more) uniformity?".
>So I can understand that fixing it in code could be (extremely) hard.

Yes, I saw and chipped in on the thread. :-)

>What can be improved is the error message.
>If I may say so myself, in running Sid for 10+ years I've gotten pretty decent
>at finding the cause of an issue and then finding a fix. But at this problem I
>was at a loss. Twice. (not knowing much about EFI probably doesn't
>help).

ACK.

>If an error is detected, a message like "Look at this wiki page <URL> for
>possible solutions", with the solution you just provided me (among others),
>would be really helpful.
>I've made/attached screenshots which could be used for that.

I'm adding an extra section to https://wiki.debian.org/UEFI right now,
at least.

>> 2. To the best of my knowledge, none of the current U-Boot releases
>> support Secure Boot so you may as well remove the shim-signed
>> package anyway. It's normally harmless to include it (so we pull
>> it in via recommends), but on your system it's not going to do
>> anything for you so you may as well remove it.
>

>It may have prevented me seeing this issue, but others would likely have
>encountered it anyway. One of the reasons I run Sid is encountering issues and
>finding a fix, so others won't have to. So I'm keeping it for now.

Fair enough. You *should* be getting the same error message without
shim being involved, though. Any update to the various grub-efi
packages will end up calling grub-install, with the same results. Have
you not been seeing that?

--
Steve McIntyre, Cambridge, UK. st...@einval.com

“Changing random stuff until your program works is bad coding
practice, but if you do it fast enough it’s Machine Learning.”
-- https://twitter.com/manisha72617183

[Diederik de Haas]

On zondag 11 juli 2021 17:42:27 CEST Steve McIntyre wrote:
> >If an error is detected, a message like "Look at this wiki page <URL> for
> >possible solutions", with the solution you just provided me (among others),
> >would be really helpful.
> >I've made/attached screenshots which could be used for that.
>
> I'm adding an extra section to https://wiki.debian.org/UEFI right now,
> at least.

Great :-)
But IMO it's also important to point to that when it fails.

"shim-helpers-arm64-signed package post-installation script subprocess

returned error exit status 1" is not a helpful error message for most people.
I was wondering whether the 'real' problem was in that package or in an efi
package or in grub(-*?) or in the kernel (evivars) or yet something else. Or a
combination of those.

> >> 2. To the best of my knowledge, none of the current U-Boot releases
> >> support Secure Boot so you may as well remove the shim-signed
> >> package anyway. It's normally harmless to include it (so we pull
> >> it in via recommends), but on your system it's not going to do
> >> anything for you so you may as well remove it.
> >
> >It may have prevented me seeing this issue, but others would likely have
> >encountered it anyway. One of the reasons I run Sid is encountering issues
> >and finding a fix, so others won't have to. So I'm keeping it for now.
> Fair enough. You *should* be getting the same error message without
> shim being involved, though. Any update to the various grub-efi
> packages will end up calling grub-install, with the same results.

ACK

> Have you not been seeing that?

Maybe I have, but I didn't realize it. I didn't know what caused the previous
time I got this error and it was a 'random' command (or a lucky sequence of
commands) that made the error go away. Assuming/Hoping it was a one time
thing, I didn't investigate further.
But when I encountered it a second time, I felt I needed to report it.

Not knowing what caused it and not (really) knowing what fixed it, makes it
hard to make connections. Now that I know it is/was caused by grub-install I
can/will look out for that and that'll make me recognize patterns.

Thanks,
Diederik

[Andres Salomon]

On Sun, 11 Jul 2021 01:31:19 +0100 Steve McIntyre <st...@einval.com>
wrote:

> On Sat, Jul 10, 2021 at 01:48:53AM +0200, Diederik de Haas wrote:

[...]

> 1. To stop your machine failing here, do a "dpkg-reconfigure
> grub-efi-arm64" and say "yes" to the removable media path question
> and "no" to the "update boot variables" question. That should
> solve the immediate problem for you - please shout if it doesn't!
>
> Fixing this in the *general* case is hard. We could add code to
> fall back to *not* updating UEFI boot variables if that fails, but
> that's likely going to be error-prone and cause trouble on
> machines where that *should* work but it fails on a temporary
> basis. Instead, I suspect we may need to replicate similar
> functionality to flash-kernel and have a list of "quirky" machines
> where we *don't* expect UEFI boot variables to work. That's messy
> as all hell, but I'm not sure of a better option. :-/

Should this just do a quick test in the postinst to test that efivarfs
is mounted r/w? Something quick like:

db_get grub2/update_nvram || RET=true
if [ "$RET" = false ]; then
OPTIONS="$OPTIONS --no-nvram"
elif [ ! -w /sys/firmware/efi/efivars/ ]; then
echo "WARNING: can't write to /sys/firmware/efi/efivars/, your system may not be bootable" >&2
OPTIONS="$OPTIONS --no-nvram"
fi

Perhaps a more informative error message, though...


Also, grub-efi-arm64's postinst runs grub-install the following way, and
I feel like the shim stuff could do the same?

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

}



>
> 2. To the best of my knowledge, none of the current U-Boot releases
> support Secure Boot so you may as well remove the shim-signed
> package anyway. It's normally harmless to include it (so we pull
> it in via recommends), but on your system it's not going to do
> anything for you so you may as well remove it.

Worth pointing out that it can't be removed unless one does the
dpkg-reconfigure trick above! :)

The following packages will be REMOVED:
mokutil* shim-helpers-arm64-signed* shim-signed* shim-signed-common*
shim-unsigned*
0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 3,674 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 23499 files and directories currently installed.)
Removing shim-signed:arm64 (1.37+15.4-6) ...

Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.

grub-install: warning: efivarfs_set_variable: failed to create

/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
for writing: Read-only file system.
grub-install: warning: _efi_set_variable_mode: ops->set_variable()
failed: Read-only file system.
grub-install: error: failed to register the EFI boot entry: Read-only
file system.

dpkg: error processing package shim-signed:arm64 (--remove):
installed shim-signed:arm64 package post-removal script subprocess

[Diederik de Haas]

On Sunday, 11 July 2021 17:42:27 CEST Steve McIntyre wrote:
> >If an error is detected, a message like "Look at this wiki page <URL> for
> >possible solutions", with the solution you just provided me (among others),
> >would be really helpful.
> >I've made/attached screenshots which could be used for that.
>
> I'm adding an extra section to https://wiki.debian.org/UEFI right now,
> at least.

I just ran into this issue again and your solution worked again :-)
But I ran a search in my mail folder(s) to find it again, so a pointer to
that wiki page would still be useful I'd guess.

I didn't get the error message I initially got (not a post-install script
failure), but I can understand if people get scared when seeing:

"system may not be bootable"

I've learned to ignore that warning, which may not be the response
we'd want to teach our users ;-)
I _think_ that even without the "dpkg-reconfigure" call the system would
still boot, but I didn't verify it (at least this time).

Here's the output I got this time, again on a Rock64 device, but another
one with a recent fresh system install:

root@cs21:~# aptitude safe-upgrade
Resolving dependencies...
The following NEW packages will be installed:
linux-image-5.18.0-3-arm64{a}
The following packages will be upgraded:
... shim-helpers-arm64-signed ...
Preparing to unpack .../22-shim-helpers-arm64-signed_1+15.6+1_arm64.deb ...
Unpacking shim-helpers-arm64-signed (1+15.6+1) over (1+15.4+7) ...
Setting up libdouble-conversion3:arm64 (3.2.0-1) ...
Setting up libapparmor1:arm64 (3.0.5-1) ...
Setting up libnewt0.52:arm64 (0.52.21-5+b2) ...
Setting up apt-utils (2.5.2) ...
Setting up shim-helpers-arm64-signed (1+15.6+1) ...

Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.

grub-install: warning: efivarfs_set_variable: failed to create /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c for writing: Read-only file system.

grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Read-only file system.
grub-install: error: failed to register the EFI boot entry: Read-only file system.

Failed: grub-install --target=arm64-efi

WARNING: Bootloader is not properly installed, system may not be bootable

...
Setting up linux-image-5.18.0-3-arm64 (5.18.14-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.18.0-2-arm64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.18.0-2-arm64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.18.0-3-arm64
I: /initrd.img is now a symlink to boot/initrd.img-5.18.0-3-arm64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.18.0-3-arm64
W: Possible missing firmware /lib/firmware/rockchip/dptx.bin for module rockchipdrm
I: The initramfs will attempt to resume from /dev/sda2
I: (UUID=f9b86b70-965a-4079-948c-02dd4d016680)

I: Set the RESUME variable to override this.

/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.18.0-3-arm64
Found initrd image: /boot/initrd.img-5.18.0-3-arm64
Found linux image: /boot/vmlinuz-5.18.0-2-arm64
Found initrd image: /boot/initrd.img-5.18.0-2-arm64
Found linux image: /boot/vmlinuz-5.18.0-1-arm64
Found initrd image: /boot/initrd.img-5.18.0-1-arm64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

root@cs21:~# dpkg-reconfigure grub-efi-arm64
Installing for arm64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.18.0-3-arm64
Found initrd image: /boot/initrd.img-5.18.0-3-arm64
Found linux image: /boot/vmlinuz-5.18.0-2-arm64
Found initrd image: /boot/initrd.img-5.18.0-2-arm64
Found linux image: /boot/vmlinuz-5.18.0-1-arm64
Found initrd image: /boot/initrd.img-5.18.0-1-arm64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

On Monday, 12 July 2021 04:32:41 CEST Andres Salomon wrote:
> Should this just do a quick test in the postinst to test that efivarfs
> is mounted r/w? Something quick like:
>
> db_get grub2/update_nvram || RET=true
> if [ "$RET" = false ]; then
> OPTIONS="$OPTIONS --no-nvram"
> elif [ ! -w /sys/firmware/efi/efivars/ ]; then

root@cs21:~# ls -lh /sys/firmware/efi/
total 0
drwxr-xr-x 2 root root 0 Jun 27 22:16 efivars
-r--r--r-- 1 root root 4.0K Jul 26 23:32 fw_platform_size
drwxr-xr-x 2 root root 0 Jul 26 23:32 mok-variables
-r-------- 1 root root 4.0K Jul 26 23:32 systab
root@cs21:~# ls -lh /sys/firmware/efi/efivars/
total 0
-rw-r--r-- 1 root root 5 Jun 27 22:16 AuditMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 5 Jun 27 22:16 DeployedMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 12 Jun 27 22:16 OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 10 Jun 27 22:16 PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 10 Jun 27 22:16 PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 5 Jun 27 22:16 SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 5 Jun 27 22:16 SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 5 Jun 27 22:16 VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c

root@cs21:~# if [ -w /sys/firmware/efi/efivars/ ]; then
echo "efivars is writable";
else
echo "efivars is NOT writable";
fi
efivars is NOT writable

This surprises me as the efivars dir seems writable by root?

In my initial report I had a "Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c"
file (and other BootXYZ-UUID files), which I don't have now.
Interesting that the UUID 'suffix' *is* the same as I had in my initial report.

[Steve McIntyre]

Hey Diederik!

On Wed, Jul 27, 2022 at 12:12:41AM +0200, Diederik de Haas wrote:
>On Sunday, 11 July 2021 17:42:27 CEST Steve McIntyre wrote:
>> >If an error is detected, a message like "Look at this wiki page <URL> for
>> >possible solutions", with the solution you just provided me (among others),
>> >would be really helpful.
>> >I've made/attached screenshots which could be used for that.
>>
>> I'm adding an extra section to https://wiki.debian.org/UEFI right now,
>> at least.
>
>I just ran into this issue again and your solution worked again :-)
>But I ran a search in my mail folder(s) to find it again, so a pointer to
>that wiki page would still be useful I'd guess.
>
>I didn't get the error message I initially got (not a post-install script
>failure), but I can understand if people get scared when seeing:
>"system may not be bootable"

Nod. :-( If you'd like to help, patches would be *very* welcome
here.

I'm swamped with other issues and I don't have the time or the
equipment any more to be able to do this alone.

ACK.

--
Steve McIntyre, Cambridge, UK. st...@einval.com

The two hard things in computing:
* naming things
* cache invalidation
* off-by-one errors -- Stig Sandbeck Mathisen