-
Bug
-
Resolution: Won't Do
-
Undefined
-
None
-
rhel-7.9.z
-
None
-
None
-
Important
-
rhel-upgrades
-
None
-
False
-
False
-
-
None
-
None
-
None
-
None
-
-
All
-
None
What were you trying to do that didn't work?
After the Leapp upgrade, the system reboots on the old RHEL 7 kernel. The userspace is fully upgraded to RHEL 8, the kernel 4.18 is installed too with the proper BLS entry, grubenv also points to the correct el8 entry.
Possible other side effects: grubby silently fails, hence net.ifnames=0 was not appended in my test, hence the NIC is renamed (so no network access) and the subscription-manager logically fails to set the release version.
(Note: problem seen multiple times)
Please provide the package NVR for which bug is seen:
leapp-upgrade-el7toel8-0.19.0-1.el7_9
How reproducible:
Always
Steps to reproduce
- Install a fresh RHEL 7.9, fully updated
- echo GRUB_ENABLE_BLSCFG=true >> /etc/default/grub
- leapp upgrade
Expected results
Reboot on the RHEL 8 kernel 4.18.x or an inhibitor to prevent the issue.
Actual results
Reboot on the RHEL 7 kernel with the RHEL 8 userspace. Possibly other side effects like the network down.
# uname -a Linux localhost.localdomain 3.10.0-1160.105.1.el7.x86_64 #1 SMP Mon Nov 6 06:58:51 EST 2023 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release Red Hat Enterprise Linux release 8.9 (Ootpa) # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.10.0-1160.105.1.el7.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto spectre_v2=retpoline rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet LANG=en_US.UTF-8 # grep ^menuentry /boot/grub2/grub.cfg menuentry 'Red Hat Enterprise Linux Server (3.10.0-1160.105.1.el7.x86_64) 7.9 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1160.90.1.el7.x86_64-advanced-ed50d451-84e0-4fce-8d8e-31da3435c737' { menuentry 'Red Hat Enterprise Linux Server (3.10.0-1160.90.1.el7.x86_64) 7.9 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1160.90.1.el7.x86_64-advanced-ed50d451-84e0-4fce-8d8e-31da3435c737' {
Workaround
# sed -i 's/^GRUB_ENABLE_BLSCFG=.*//g' /etc/default/grub # grub2-switch-to-blscfg # reboot ### If required (if grubby failed during the IPU) # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args net.ifnames=0 # reboot
Analysis
grub2-tools is upgraded
upgrade[1912]: Upgrading : grub2-tools-1:2.02-148.el8.x86_64 399/2351 upgrade[1912]: Running scriptlet: grub2-tools-1:2.02-148.el8.x86_64 399/2351
so its post-script executes `/sbin/grub2-switch-to-blscfg`:
if [ "$1" = 2 ]; then /sbin/grub2-switch-to-blscfg --backup-suffix=.rpmsave &>/dev/null || : fi
When GRUB_ENABLE_BLSCFG=true is already present in /etc/default/grub, the grub2-switch-to-blscfg script does not call `grub2-mkconfig`, leading to a grub.cfg that is not updated for BLS configurations, containing only old-style RHEL 7 grub menuentries.
