#1138211 grub-pc: package upgrades leave on-disk core.img out of sync with /boot/grub/, causing stale kernel selection at boot

Package:
grub-pc
Source:
grub-pc
Description:
GRand Unified Bootloader, version 2 (PC/BIOS version)
Submitter:
Bastian Venthur
Date:
2026-05-29 18:43:01 UTC
Severity:
normal
#1138211#5
Date:
2026-05-29 12:09:13 UTC
From:
To:
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.

#1138211#10
Date:
2026-05-29 18:41:32 UTC
From:
To:
This cannot be caused by a module version mismatch. A module version
mismatch would cause GRUB to enter rescue mode (more exactly to remain
in rescue mode and not enter normal mode).

What is Hetzner installimage ? What is provisioning ?

grub-install runs on grub-pc upgrade.

Is it only the default kernel which is older or is the current kernel
missing from the "Advanced options" submenu (in other words, the menu is
outdated) ?

Running update-grub only generates a fresh /boot/grub/grub.cfg, has
nothing to do with the core image and should not be necessary here.
(...)
(...)
(...)

debconf tells grub-pc to run grub-install on /dev/sda1 on upgrade. If
running grub-install on /dev/sda fixes the issue, it means that grub-pc
was configured to install GRUB into the wrong location, so the location
from where GRUB boots is not updated.