On zondag 11 juli 2021 02:31:19 CEST Steve McIntyre wrote: > Hi Diederik,
Hi Steve, > On Sat, Jul 10, 2021 at 01:48:53AM +0200, Diederik de Haas wrote: > >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. > > 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? 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 :-) > 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. 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). 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. > 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. Cheers, Diederik
signature.asc
Description: This is a digitally signed message part.