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