Package: systemd
Version: 260.1-1
Severity: normal
Tags: upstream
Hi,
I have hit a reproducible cohort split in /boot/efi/loader/entries/
after a routine dist-upgrade on Debian forky/sid. The systemd-shipped
/usr/lib/kernel/install.d/90-loaderentry.install plugin appears to
write some entries with `sort-key debian` and some without, even
though the script's SORT_KEY derivation (lines 80-81 of the current
260.1-1 plugin) should always emit a non-empty SORT_KEY when
ID=debian is present in /etc/os-release.
Concrete observation:
After ~1000 packages upgraded on this system,
/boot/efi/loader/entries/ contains four BLS entries that split
cleanly into two cohorts:
Cohort A. Entries with `sort-key debian` and
`linux /boot/vmlinuz-X`:
debian-6.19.10+deb14-amd64.conf (installed 2026-04-04)
debian-6.19.11+deb14-amd64.conf (installed 2026-04-21)
Cohort B. Entries WITHOUT `sort-key` and with `linux /vmlinuz-X`
(no /boot/ prefix):
debian-6.19.13+deb14-amd64.conf (installed 2026-04-25)
debian-7.0.7+deb14-amd64.conf (installed 2026-05-25)
Two changes flipped together between Cohort A and Cohort B: sort-key
emission stopped, and the `linux` field's path prefix dropped
/boot/.
I expected the script to behave consistently between kernel installs
as long as /etc/os-release contains ID=debian (which it does today
and which the dpkg log shows base-files has been installed
continuously since 2025-12-09).
`90-loaderentry.install` lines 80-81 derive SORT_KEY as:
SORT_KEY="$IMAGE_ID"
[ -z "$SORT_KEY" ] && SORT_KEY="$ID"
And line 213 emits only when SORT_KEY is non-empty:
[ -n "$SORT_KEY" ] && echo "sort-key $SORT_KEY"
For Cohort B to be missing the sort-key line, both IMAGE_ID and ID
must have been empty/unset at the time the script ran. Yet Cohort A
and B were both written on the same system with the same systemd
package version (260.1-1, installed 2026-03-27) and the same
base-files (14, installed 2025-12-09; upgraded to 14.0 on
2026-05-25 04:25:23, but 6.19.13 was written 2026-04-25, a full
month before the base-files upgrade).
Hypotheses for what could empty SORT_KEY mid-transaction:
1. A transient os-release rewrite during the dpkg transaction
(some package reinstalled /usr/lib/os-release without ID
briefly).
2. `kernel-install` was invoked with environment variables that
overrode or unset ID (KERNEL_INSTALL_*).
3. A third-party kernel-install plugin earlier in the install.d/
chain modified the environment seen by 90-loaderentry.install.
The plugins active on this system are:
50-depmod.install
55-initrd.install
90-lamboot.install (third-party, LamBoot bootloader)
90-loaderentry.install
90-uki-copy.install
4. A bug in `kernel-install` (or in 90-loaderentry.install
itself) that loses ID under some specific dist-upgrade timing.
I am happy to provide further evidence (full /var/log/dpkg.log
timeline, the four BLS .conf files, /etc/os-release current
contents) on request.
The downstream user impact is: any bootloader that follows BLS spec
section 3.1 sorting (sd-boot, LamBoot, others) puts all
sort-key-having entries before all sort-key-less entries in the
menu. The newest kernel (7.0.7) sits below older kernels (6.19.11)
in the menu and becomes non-default. This looks like a bootloader
bug from the operator's perspective but the source-of-truth is the
inconsistent BLS entries kernel-install wrote.
Suggested investigation: trace where SORT_KEY can become empty
during a multi-package dpkg transaction, or document the expected
behavior more explicitly so bootloaders can defend against the
inconsistency.
System details:
- Debian forky/sid (Debian GNU/Linux forky/sid)
- systemd 260.1-1
- linux-base 4.15
- base-files 14.0 (was 14 at the time the bug-triggering kernels
were installed)
- /etc/os-release -> /usr/lib/os-release (symlink owned by
base-files)
- /etc/os-release content (current):
PRETTY_NAME="Debian GNU/Linux forky/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=forky
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";
Thank you for looking into this.
-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)
Kernel: Linux 6.19.11+deb14-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- Greg
