Installation of new kernel on F44 RC isn't updating default kernel

Ask Fedora
, ,
1

I’m running a F44 RC 1.7 aarch64 as a VM under VMware Fusion on an Apple Silicon Mac. My system disk is not encrypted.

After installing the F44 RC from the Live ISO and booting from the hard drive, I find that the kernel is the 6.19.10 release. I then installed available updates which included the 6.19.13 kernel. A subesequent reboot after that installation is showing that the 6.19.10 kernel is still booting by default and not the newer 6.10.13. This behavior is different from what I’ve seen in F43 and earlier.

After some investigations, I find that grubby is indeed showing the default kernel index as 1 - explaining why the old kernel continues to boot as default.

I can boot the updated kernel by forcing the grub bootloader menu at power up and selecting the latest kernel. So the kernel is getting installed properly (also I can find it in /boot). However, manually selecting it doesn’t change the default kernel. A subsequent boot will go right back to booting the old kernel unless I manually override it again.

I can also tell grubby to select set the default index to 0 which will boot the latest kernel as default. That persists across boot, but I suspect that the next kernel update will not change the default kernel.

Any thoughts on what might be going on here and why the behavior has changed? I haven’t been able to pin point whether this something either VMware, generic virtualization, or aarch64 related?

Might have to open a bugzilla report on this, and if so would appreciate guidance on the component to open the report against…

3

It seams from F44 we changed something:

Please also take time to go thru the rest of the changes we made for F44:

@mlewando might have an idea what could have gone wrong. The Names are listed as:
Owners in the change documentation beside @siosm & @walters

4

If you want the manual selection you make in the GRUB menu to “stick” for the next boot, then you can add this line to /etc/default/grub:

GRUB_SAVEDEFAULT=true

and check that this line is present (add or update it if it’s not):

GRUB_DEFAULT=saved

Then rebuild the GRUB config:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
5

I’d come across this when researching the issue and was thinking it might be a potential work-around. Thanks for confirming my thoughts. I’ll give it a try. At least I would only have to drop into the GRUB menu once after updating the kernel to get the selection to “stick” (and to avoid grubby manipulation of the default kernel name/index each time).

I do suspect that the changes for DTB selection on WoA devices might be behind what I’m seeing.

6

this is on x86_64 but I’d assume aarch64 have this as well:

$ cat /etc/sysconfig/kernel
# UPDATEDEFAULT specifies if kernel-install should make
# new kernels the default
UPDATEDEFAULT=yes

# DEFAULTKERNEL specifies the default kernel package type
DEFAULTKERNEL=kernel-core

This file should have been created by the installer.

7

/etc/sysconfig/kernel appears to be different on aarch64:

$ cat /etc/sysconfig/kernel
# UPDATEDEFAULT specifies if kernel-install should make
# new kernels the default
UPDATEDEFAULT=yes

# DEFAULTKERNEL specifies the default kernel package type
DEFAULTKERNEL=kernel-uki-dtbloader

This is different than on F43 aarch64. The file there is the same as you have posted.

8

I guess this change affects the booting and kernel setup quite a bit:

9

I can confirm that setting

DEFAULTKERNEL=kernel-core

in /etc/sysconfig/kernel fixes this issue. New kernels that are installed get set to default, as expected.

I don’t know why this was changed in f44, though.

10

The more I look into this, the more it looks like the automatic DTB selection for aarch64 change is the culprit. The change seems to be resulting in the kernel-uki-dtbloader packages being installed instead of the kernel-core packages. My suspicion is that whatever the postinstall scripts for the kernel-uki-dtbloader packages are doing is not setting the saved_entry variable in the GRUB environment block to the newly installed kernel like it does for the kernel-core packages. The workaround I’m now using is to use grub2-set-default to manually change the saved_entry variable after the update is installed.

Looks like it’s Bugzilla time. What would be the best component to report this under?

11

Looks like fedora-kiwi-descriptions is where this change was made: Making sure you're not a bot!

12

Bug reported: 2463620 – GRUB environment variable saved_entry not updated when installing UKI kernel on F44 aarch64