On 05/12/2022 18:33, Steve McIntyre wrote:
On Mon, Dec 05, 2022 at 06:19:53PM +0100, Eric Valette wrote:
On 05/12/2022 18:07, Steve McIntyre wrote:
You're using the Secure Boot path (shim -> grub-efi-amd64-signed), so
the version of grub that matters for you is the signed version:
1+2.06+5. That is (so far) still based on grub2 source version 2.06-5.
It takes a short while for the builds to propagate through the signing
machinery in Debian.
Please be patient, the fix is on the way to you. If you can check
again when 1+2.06+6 is available, that will be more helpful.
Fair enough but for me this should be handled as a dependency so that you
cannot upgrade only part of grub components. A meta package that makes sure
all the dependencies are ok before starting the upgrade.
There are no dependency issues to worry about here, I'm afraid you
simply misunderstood the grub packaging setup. That's reasonable -
it's not obvious! Just don't expect the bug to be fixed until the
changes have propagated...
I beg to disagree on this one. On my laptop, I updated
grub-efi-amd64-signed to the 1+2.06+6 version but, as installation does
not trigger grub reinstall, my laptop is still broken. If you do not
want to put dependency on component, each component that contains things
that should be moved to EFI directory should trigger a grub update.
And at first you should not update the EFI directory until all needed
binaries are updated.
( ls /var/lib/dpkg/info/grub-efi-amd64-signed.*
/var/lib/dpkg/info/grub-efi-amd64-signed.list
/var/lib/dpkg/info/grub-efi-amd64-signed.md5sums
)
The good point, is that, on my Desktop that was broken due to previous
install, and on which I downgraded and pinned, because I installed a
coherent set all at once, it worked.
But dependencies should enforce you always have a coherent set when
ruing grub update.
So I have to boot windows, suspend bit locker, trigger the reinstall of
grub, verify it works by rebooting and then again reenable bitlocker.
Groumph.
-- eric
