Bug#1117088: upgrade-reports: upgrade with luks root+boot fails to properly install grub; leaves system unbootable
Package: upgrade-reports
Severity: important
X-Debbugs-Cc: forestix@gaga.casa
My previous release is: Bookworm
I am upgrading to: Trixie
Archive date: (today) Thu Oct 2 20:21:22 UTC 2025
Upgrade date: 2025-09-04
uname -a before upgrade: (not recorded)
uname -a after upgrade: (not immediately recorded)
uname -a today: Linux ink 6.12.48+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48-1 (2025-09-20) x86_64 GNU/Linux
Method: apt upgrade --without-new-pkgs; apt full-upgrade
Contents of /etc/apt/sources.list.d/debian.sources:
Types: deb deb-src
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Types: deb deb-src
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
- Were there any non-Debian packages installed before the upgrade? If
so, what were they?
Yes:
- Various application & desktop packages with backported bug fixes,
none of which would be expected to cause the problems reported here.
- linux-image-amd64 6.12.38-1~bpo12+1
- Was the system pre-update a 'pure' system only containing packages
from the previous release? If not, which packages were not from that
release?
Close enough to pure that I would not expect any Debian upgrade problems.
(See previous question.)
- Did any packages fail to upgrade?
No.
- Were there any problems with the system after upgrading?
Yes: The upgrade rendered the system unbootable.
Further Comments/Problems:
The upgrade process completed without a hitch, until rebooting.
On first reboot, the familiar GRUB prompt asking for my LUKS passphrase
appeared. Upon entering the passphrase, the system rebooted into the
UEFI setup screen instead of bringing up the Debian GRUB menu with blue
background.
Investigation revealed the following:
- During the upgrade process, the installer asked whether to keep the
existing /etc/default/grub or replace it with the maintainer's
version. I chose replace, knowing that my kernel command line tweaks
would be overwritten, but assuming it would be otherwise safe.
It was not safe.
- It turns out that the new /etc/default/grub did not include
GRUB_ENABLE_CRYPTODISK=y, which I believe GRUB requires in order to
boot when the /boot directory lives within the encrypted / filesystem
(not a separate unencrypted partition) as it does on this system.
- The Debian upgrade process did not notice that this was the case, and
did not restore the critically important GRUB_ENABLE_CRYPTODISK=y
line that was in /etc/default/grub before the upgrade.
- I suspect this omission led to grub-install silently failing during
the upgrade process.
Evidence:
- While fixing this mess, my first attempt to run grub-install
failed, with an error message complaining about the missing
GRUB_ENABLE_CRYPTODISK=y. I did not see this message during the
upgrade process. This suggests to me that the upgrader swallowed
it, and assumed that grub-install had succeeded when it had not.
- After dealing with that and getting a successful grub-install,
I noticed that GRUB's passphrase prompt slightly changed:
The prompt text is now bright white instead of its former
dim/grayish. I imagine that the dim text probably came from the old
GRUB version still being installed on the boot device, but unable
to boot the system once the new GRUB config was applied.
Once the new version of grub-install had successfully run, the text
was bright white (presumably a change introduced by the new version)
and the system booted.
Based on what I've observed, It seems to me that the upgrade process
should have:
1. Noticed that GRUB_ENABLE_CRYPTODISK=y was present in the original
/etc/default/grub, and taken steps to preserve this critically
important setting.
2. Noticed that this sytem's /boot lives within the encrypted root
filesystem, therefore requiring GRUB_ENABLE_CRYPTODISK=y,
and taken steps to add it (or at least prompt the user about it)
if it was not present in /etc/default/grub.
3. Detected any failure or warning/error message from grub-install,
shown it to the user, and clearly stated that the system was not
likely to be bootable until this was dealt with.
Since the upgrader failed on all three of those points, my system was
left in a completely broken state that required considerable time,
knowledge, and patience to diagnose and recover from. The vast majority
of users would never be able to do that, and would probably consider
this a catastrophic failure. It could have been avoided.
Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...",
depending on your shell) from before and after the upgrade so that we
know what packages were installed on your system.
For privacy reasons, I prefer not to reveal a list of all my installed
packages. If there are specific ones that would help the maintainers
address this problem, please just name them; I'll be happy to help.
Here are the grub-related ones:
$ grep grub apt-list-installed.before-upgrade
grub-common/oldstable,oldstable-security,now 2.06-13+deb12u1 amd64 [installed,automatic]
grub-efi-amd64-bin/oldstable,oldstable-security,now 2.06-13+deb12u1 amd64 [installed,automatic]
grub-efi-amd64-signed/oldstable,oldstable-security,now 1+2.06+13+deb12u1 amd64 [installed,automatic]
grub-efi-amd64/oldstable,oldstable-security,now 2.06-13+deb12u1 amd64 [installed]
grub2-common/oldstable,oldstable-security,now 2.06-13+deb12u1 amd64 [installed,automatic]
$ grep grub apt-list-installed.today
grub-common/stable,now 2.12-9 amd64 [installed,automatic]
grub-efi-amd64-bin/stable,now 2.12-9 amd64 [installed,automatic]
grub-efi-amd64-signed/stable,now 1+2.12+9 amd64 [installed,automatic]
grub-efi-amd64-unsigned/stable,now 2.12-9 amd64 [installed,automatic]
grub-efi-amd64/stable,now 2.12-9 amd64 [installed]
grub2-common/stable,now 2.12-9 amd64 [installed,automatic]
Reply to: