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