`kernel-install remove` does not clean up obsolete saved_entry in /boot/grub2/grubenv #14

New issue

Open

opened 2024-09-30 17:46:18 +00:00 by humaton · 0 comments

humaton commented

2024-09-30 17:46:18 +00:00

Member

Description of problem: Using kernel-install add to install a new kernel automatically moves grub's saved_entry to the new kernel. But kernel-install remove does not undo that, so that the saved entry points into the void, and the machine fails to boot. Version-Release number of selected component (if applicable): systemd-udev-249.11-1.fc35.x86_64 How reproducible: Always Steps to Reproduce: 1. Check original saved entry: grep saved_entry /boot/grub2/grubenv # saved_entry=a7173868d29543b4bf15bf4227230490-5.16.20-200.fc35.x86_64 2. Create and add a (fake) new kernel: truncate -s 10M /boot/vmlinuz-42.0.0; mkdir -p /lib/modules/42.0.0/ kernel-install add 42.0.0 /boot/vmlinuz-42.0.0 3. Check updated saved entry: grep saved_entry /boot/grub2/grubenv # saved_entry=ae4358d9a14347c2a646a3fe777b8740-42.0.0 4. Remove fake kernel again: rm /boot/vmlinuz-42.0.0 kernel-install remove 42.0.0 /boot/vmlinuz-42.0.0 5. Check saved entry: grep saved_entry /boot/grub2/grubenv # saved_entry=ae4358d9a14347c2a646a3fe777b8740-42.0.0 Actual results: saved entry is still the fake 42 kernel. Rebooting the VM (sometimes) fails; our previous F35 image builds curiously succeeded until now (this is part of cockpit's test suite), but the recent one in https://github.com/cockpit-project/bots/pull/3293 now fails. Expected results: Removing the currently saved kernel updates the default to the most recent installed kernel.

Description of problem: Using `kernel-install add` to install a new kernel automatically moves grub's saved_entry to the new kernel. But `kernel-install remove` does not undo that, so that the saved entry points into the void, and the machine fails to boot. Version-Release number of selected component (if applicable): systemd-udev-249.11-1.fc35.x86_64 How reproducible: Always Steps to Reproduce: 1. Check original saved entry: grep saved_entry /boot/grub2/grubenv # saved_entry=a7173868d29543b4bf15bf4227230490-5.16.20-200.fc35.x86_64 2. Create and add a (fake) new kernel: truncate -s 10M /boot/vmlinuz-42.0.0; mkdir -p /lib/modules/42.0.0/ kernel-install add 42.0.0 /boot/vmlinuz-42.0.0 3. Check updated saved entry: grep saved_entry /boot/grub2/grubenv # saved_entry=ae4358d9a14347c2a646a3fe777b8740-42.0.0 4. Remove fake kernel again: rm /boot/vmlinuz-42.0.0 kernel-install remove 42.0.0 /boot/vmlinuz-42.0.0 5. Check saved entry: grep saved_entry /boot/grub2/grubenv # saved_entry=ae4358d9a14347c2a646a3fe777b8740-42.0.0 Actual results: saved entry is still the fake 42 kernel. Rebooting the VM (sometimes) fails; our previous F35 image builds curiously succeeded until now (this is part of cockpit's test suite), but the recent one in https://github.com/cockpit-project/bots/pull/3293 now fails. Expected results: Removing the currently saved kernel updates the default to the most recent installed kernel.