Bug#990867: shim-helpers-arm64-signed: post-install script fails with 'error exit status 1'
Steve McIntyre
steve at einval.com
Sun Jul 11 16:42:27 BST 2021
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. steve at 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
More information about the Pkg-grub-devel
mailing list