Fedora Account System
Red Hat Associate
Red Hat Customer
kernel-install fails to update the GRUB saved_entry environment variable when the DEFAULTKERNEL type in /etc/sysconfig/kernel is set to kernel-uki-dtbloader. As a result, when a new kernel update is installed, the system continues to boot by default with an old kernel version instead of the newly installed kernel update. This is a regression in behavior over Fedora versions prior to 44). Reproducible: Always Steps to Reproduce: 1. Install a new system using the F44 Workstation 1.7 Live ISO 2. Boot the newly installed system - the kernel version should be 6.19.10 3. Update the system - a new kernel will be installed (currently 6.19.14). 4. Reboot the system. Actual Results: Kernel version booted by default after updates are applied is still 6.19.10. Expected Results: Kernel 6.19.14 should be booted by default. Additional Information: Examining the saved_entry GRUB2 environnment variable (/boot/grub2/grubenv) shows that it continues to point to the old kernel even after installation of the new kernel. The new kernel can be booted by overriding the boot selection in the GRUB bootloader menu, or the default kernel can be reset using grub2-set-default. Examining the scripts used by kernel-install in /usr/lib/kernel/install.d, I may have found something interesting. The saved_entry variable is updated by 95-boot-entry.install and relies on earlier scripts inserting a tmp_saved_entry variable into the environment block. 20-grub.install appears to be the only script that sets this variable. But if the kernel type is determined to be UKI, 20-grub.install exits before setting tmp_saved_entry. Comments in 20-grub.install indicate that 90-uki-copy.install should handle the tasks found in 20-grub.install for UKI kernels, but 90-uki-copy.install does not insert the tmp_saved_entry variable needed for 95-boot-entry.install to update the saved_entry variable.
I have reproduced this issue on aarch64 virtual machines using both VMware Fusion
Sorry, hit save too soon... I wanted to say that I've reproduced this on virtual machines running F44 guests on both VMware Fusion and UTM on Apple Silicon (ARM).
I think I had the incorrect component for this issue. Given that the issue occurs when the kernel-uki-dtbloader package installed (based on DEFAULTKERNEL setting in /etc/sysconfig/system), I changed the component to kernel. Apologies for the mis-categorization.
1. I have the same issue 2. I think severity of this bug should be highest, as it has security implication. User may think they are safe after upgrading kernel, but in fact their system will keep running older kernel with vulnerabilities.
Duplicated Fedora 44 VM guests on Parallels and VirtualBuddy on Apple Silicon (ARM), both fresh 44 installs and upgraded 43 to 44 installs. After running sudo grubby --set-default-index=0 to temporarily fix (until the next kernel update), if execute >rpm -q kernel-core in attempt to view all available kernels, error 'package kernel-core not installed'. This appears to be due to version mismatch with UKI Kernel?? Even after upgrading to latest kernel 7.x and applying fix, the 'kernel-core' package version is still original 6.19.10 from initial fresh install. Apologize if this is unrelated and different bug, I'm not that technical.
I am disappointed this bug severity is listed as Medium. At minimum should be High, and probably Severe. Unnoticed, this bug will result in the kernel not being updated INDEFINITELY. In fact new fresh installs of F44 will remain on kernel 6.19.10. There is no error message, nothing to indicate anything is wrong. Security vulnerabilities will go unpatched. For an admin or enterprise customer, this would be critical, especially if there are SLA (Service level agreements) and liabilities involved. I don't have an x86 machine to test this on, I would be curious if this bug exists on x86, if so, this would be marked Severe and given the attention it deserves. x86 vs ARM bias?
Thank you for reporting this! After reproducing and analyzing the problem my conclusion is that the problem is that grub2-get-kernel-settings sets GRUB_NON_STANDARD_KERNEL=true for kernel-uki-dtbloader, while kernel-uki-dtbloader is the default kernel on aarch64 live media now. GRUB_NON_STANDARD_KERNEL=true in turn leads to /lib/kernel/install.d/95-set-boot-entry.install not updating the default kernel in the grub environment. I'm currently testing a patch to fix this and I will submit a PR to the grub2 package at https://src.fedoraproject.org/rpms/grub2/ once the patch has been successfully tested. Changing component to grub2.
rhboot/grub2 Fedora grub2's downstream git repo PRs with the fix: fedora-44: https://github.com/rhboot/grub2/pull/214 fedora-45: https://github.com/rhboot/grub2/pull/213 https://src.fedoraproject.org/rpms/grub2/ PRs: fedora-44: https://src.fedoraproject.org/rpms/grub2/pull-request/226 rawhide: https://src.fedoraproject.org/rpms/grub2/pull-request/225 For people who want a fix now, here are scratch-builds of Fedora's grub2 with the patch added: fedora-44: https://koji.fedoraproject.org/koji/taskinfo?taskID=146052073 rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=146051707 Note since I'm not a Fedora grub maintainer these are not signed with Fedora's selinux key, so these will not work if you've secure-boot enabled.