Dear Maintainer,
After several grub-pc and kernel package upgrades on a Debian 13 (trixie)
system, the GRUB stages embedded on disk (MBR boot.img + core.img in the
post-MBR gap) drifted out of sync with the modules under /boot/grub/i386-pc/ and
the regenerated /boot/grub/grub.cfg. The visible symptom was that GRUB
consistently booted an older installed kernel (6.12.48) instead of the current
default (6.12.90), across multiple reboots, despite /boot/grub/grub.cfg
correctly listing 6.12.90 as the default entry.
A second tell-tale symptom: next_entry=0 in /boot/grub/grubenv was never cleared
on boot, even though grub.cfg contains the standard set default="${next_entry}";
set next_entry=; save_env next_entry block. This indicates the running GRUB was
not executing (or not successfully writing back) the current grub.cfg.
Steps to reproduce:
1. Install Debian on a BIOS/MBR system (in my case via Hetzner installimage,
which runs grub-install once at provisioning).
2. Over time, allow normal apt upgrade runs to upgrade grub-pc, grub-common,
grub-pc-bin, and install new kernels. update-grub runs as part of these
upgrades; grub-install does not.
3. Reboot. GRUB picks an older kernel than the one listed as default in
/boot/grub/grub.cfg.
Workaround:
Re-running grub-install /dev/sda followed by update-grub resyncs the on-disk
core.img with the current modules and config. After this, reboots correctly
select the newest kernel and grubenv writes work again.
Expected behavior:
Either (a) grub-pc package upgrades should re-run grub-install on the configured
target device(s) when the on-disk core.img would otherwise become incompatible
with the upgraded modules, or (b) the package should detect this drift and warn
the administrator that grub-install needs to be re-run manually. The current
silent-failure mode is hard to diagnose, especially on remote/headless systems
where the GRUB menu cannot be observed.