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

[Pascal Hambourg]

On 29/05/2026 at 14:09, Bastian Venthur wrote:
> 
> 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.

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).

> Steps to reproduce:
> 
> 1. Install Debian on a BIOS/MBR system (in my case via Hetzner installimage,
> which runs grub-install once at provisioning).

What is Hetzner installimage ? What is 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.

grub-install runs on grub-pc upgrade.

> 3. Reboot. GRUB picks an older kernel than the one listed as default in
> /boot/grub/grub.cfg.

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) ?

> 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.

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.

> *********************** BEGIN /dev/disk/by-id
(...)
> lrwxrwxrwx 1 root root  9 May 29 12:52 scsi-0QEMU_QEMU_HARDDISK_38212 -> ../../sda
> lrwxrwxrwx 1 root root 10 May 29 12:52 scsi-0QEMU_QEMU_HARDDISK_38212-part1 -> ../../sda1
(...)
> *********************** END /dev/disk/by-id

> -- debconf information:
(...)
> * grub-pc/install_devices: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_38212-part1

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.