[email protected] wrote: > >I recently updated my Debian desktop to Trixie. It went fine but Grub >broke. It got as far as "Welcome to GRUB" then black screen and reboot. > >I fixed that by doing grub-install and update-grub in a chroot but what >went wrong and can I avoid this annoyance in the future? Is this a known >problem? I remember seeing an off hand mention that this "often" happens >on Debian and derivatives but didn't pursue it then and don't have a >reference. And it's never happened to me before.
Running grub-install by hand is only ever a *temporary* fix here. You don't say if you're using BIOS boot or UEFI boot. There's a couple of likely possibilities for the cause of your problem. Problem 1: inconsistent grub-core and grub modules ================================================== BIOS boot is more likely to see this problem here, but it's also possible on UEFI systems. On a BIOS-booting system, the first-stage GRUB loader (grub core) is the bit that gets installed by "grub-install". This fits in the first megabyte of your hard disk. Unfortunately, there's a lot more to GRUB such that it won't all fit there and the rest of it lives in /boot/grub on your installed system. The problem that comes out of this is that the versions of the grub core code and the modules need to be compatible. The API between those pieces is *not* fixed, and so if you don't ensure that they are upgraded in sync you can get all kinds of weird booting problems. The worst part of those problems is that they'll often only show up a long time *after* you maybe broke things by doing a manual "grub-install" - typically after a major version change in GRUB during an upgrade between versions of Debian. On a UEFI-booting system that needs to boot using the removable media path (often because of firmware bugs) can also fall into this trap. If you've installed to the removable media path *by hand* using "grub-install" then you can end up with an old grub-core EFI binary there which is never upgraded. All works great, until one day it doesn't. :-( GRUB itself can't know exactly which disk(s) you installed it onto, so the package maintainer scripts add extra logic to track this. The *correct* way to fix things on a Debian system is to run: # dpkg-reconfigure grub-pc (for BIOS) or # dpkg-reconfigure grub-efi-amd64 (for UEFI on and amd64 machine) and answer the questions, ioncluding (for BIOS) which disks to install to and (for UEFI) whether you need to install to the removable media path. This will solve the problem of broken boot for you *persistently* and should survive future upgrades. Problem 2: Secure Boot issues on UEFI ===================================== Again, this can be caused by running "grub-install" and not using the maintainer scripts. As things move on, it's possible that your system can have old *security-blocked* versions of GRUB or shim in the boot path. If GRUB doesn't know where to install things on package upgrades, they never get updated to the newer, working versions. The fix (again) is to run dpkg-reconfigure once you have your system booting. Finally... If you end up swapping the disks in your computer (e.g. to replace failed disks), make sure you re-run dpkg-reconfigure afterwards to make sure the system is fully configured - *don't* be tempted to just run grub-install... Hope this helps! Steve (one of the Debian GRUB maintainers) -- Steve McIntyre, Cambridge, UK. [email protected] Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
