Description of problem: I decided to try UKI on bare metal following the instructions provided on the wiki: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2#Switch_an_existing_install_to_use_UKIs. After installing or updating the UKI kernel, firmware boots the UKI image via BootNext once, after which default boot option gets reset to grub. The entry created by dnf install remained, but the one created by dnf update disappeared after first boot. $ rpm -q kernel-uki-virt kernel-uki-virt-6.9.12-200.fc40.x86_64 kernel-uki-virt-6.10.3-200.fc40.x86_64 $ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # C O - 0002 - Fedora # O - 0000 - Windows Boot Manager # O - 0001 - Fedora Linux 40 (Workstation Edition) 6.9.12-200.fc40.x86_64 (UKI) $ sudo dnf history kernel-uki-virt Kennun | Befehlszeile | Datum und Zeit | Aktion(en) | Verände ------------------------------------------------------------------------------------------------------------------------------------------------ 1835 | --enablerepo=rpmfusion-free-updates-testing --enablerepo=rpmfusion-nonfree-updates-testin | 07-08-2024 14:26 | C, E, I, U | 17 1834 | install kernel-uki-virt | 05-08-2024 16:10 | Install | 1 $ sudo journalctl --no-hostname --unit=kernel-bootcfg-boot-successful.service [sudo] Passwort für julas: Aug 05 16:12:06 kernel-bootcfg[887]: INFO: No update needed, BootCurrent is already in BootOrder. Aug 05 16:12:06 kernel-bootcfg[887]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Aug 05 16:12:04 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Aug 05 16:12:05 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Aug 05 16:33:57 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Aug 05 16:33:57 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot ce369aece3a440c68ca6927b98d06051 -- Aug 05 16:35:11 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Aug 05 16:35:11 kernel-bootcfg[857]: INFO: No update needed, BootCurrent is already in BootOrder. Aug 05 16:35:11 kernel-bootcfg[857]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Aug 05 16:35:14 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Aug 07 14:29:31 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Aug 07 14:29:31 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot f3fb87f58900451f80bc3d13cada3db8 -- Aug 07 14:29:56 kernel-bootcfg[900]: INFO: No update needed, BootCurrent is already in BootOrder. Aug 07 14:29:56 kernel-bootcfg[900]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Aug 07 14:29:54 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Aug 07 14:29:55 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Aug 07 14:40:55 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Aug 07 14:40:55 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot 08840fc10e5b4bb58360b8cfeaaf6cc5 -- Aug 07 14:42:08 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Aug 07 14:42:09 kernel-bootcfg[911]: INFO: No update needed, BootCurrent is already in BootOrder. Aug 07 14:42:09 kernel-bootcfg[911]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Aug 07 14:42:09 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot Version-Release number of selected component (if applicable): uki-direct-24.7-1.fc40.noarch How reproducible: BootOrder not updated: 2 out of 2 times Boot entry disappearing: 1 out of 2 Steps to Reproduce: 1. Follow instructions from Phase 2 UKI feature wiki page 2. Install kernel-uki-virt 3. Reboot 4. Reboot again Actual results: UKI kernel boots once by default after the first reboot but the boot order is never updated, or the boot entry disappears altogether Expected results: Updated kernel is set as default after a successful boot. Additional info: The machine is an Asus Zenbook UM425IA with BIOS version 311. The machine is EOS by Asus, no further BIOS updates will be made available.
I tested again with 6.10.4 and got the same result: correct bootnext once, entry gone upon next reboot. -- Boot 18b9a39964684763a723faf47a353216 -- Aug 09 21:37:30 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Aug 09 21:37:31 kernel-bootcfg[913]: INFO: No update needed, BootCurrent is already in BootOrder. Aug 09 21:37:31 kernel-bootcfg[913]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Aug 09 21:37:31 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. --- here I ran dnf update --- Aug 13 12:27:25 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Aug 13 12:27:25 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot 0da5ab3c88ee4685ad199e050657bc41 -- (first reboot) Aug 13 12:27:55 kernel-bootcfg[879]: INFO: No update needed, BootCurrent is already in BootOrder. Aug 13 12:27:55 kernel-bootcfg[879]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Aug 13 12:27:54 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Aug 13 12:27:55 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Aug 13 12:29:27 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Aug 13 12:29:27 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot 5470ea28d80042458def1459dd013fd3 -- (second reboot) Aug 13 12:29:51 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Aug 13 12:29:52 kernel-bootcfg[918]: INFO: No update needed, BootCurrent is already in BootOrder. Aug 13 12:29:52 kernel-bootcfg[918]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Aug 13 12:29:52 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. This is what kernel-bootcfg shows after running dnf update: # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # N - 0003 - Fedora Linux 40 (Workstation Edition) 6.10.4-200.fc40.x86_64 (UKI) # C O - 0002 - Fedora # O - 0000 - Windows Boot Manager # O - 0001 - Fedora Linux 40 (Workstation Edition) 6.9.12-200.fc40.x86_64 (UKI) After the first reboot: # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # O - 0002 - Fedora # O - 0000 - Windows Boot Manager # O - 0001 - Fedora Linux 40 (Workstation Edition) 6.9.12-200.fc40.x86_64 (UKI) # C O - 0003 - Fedora Linux 40 (Workstation Edition) 6.10.4-200.fc40.x86_64 (UKI) After the second reboot: # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # C O - 0002 - Fedora # O - 0000 - Windows Boot Manager # O - 0001 - Fedora Linux 40 (Workstation Edition) 6.9.12-200.fc40.x86_64 (UKI)
(In reply to Julian Sikorski from comment #1) > I tested again with 6.10.4 and got the same result: correct bootnext once, > entry gone upon next reboot. Gerd is on vacation currently but to me this looks really weird. It seems that it all works as expected upon the first reboot: > # C O - 0003 - Fedora Linux 40 (Workstation Edition) 6.10.4-200.fc40.x86_64 (UKI) But then the entry is gone completely. I've only seen similar behavior when UEFI firmware was removing incorrect entries, i.e. entries which point to non-existing binaries. If you check, is the UKI still present in /boot/efi/EFI/Linux ?
The files seem to still all be there: $ sudo ls -lh /boot/efi/EFI/Linux/ insgesamt 161M -rwx------. 1 root root 54M 7. Aug 14:27 4335e4ece7054377bd1fe24ee0898ff3-6.10.3-200.fc40.x86_64.efi -rwx------. 1 root root 55M 13. Aug 08:59 4335e4ece7054377bd1fe24ee0898ff3-6.10.4-200.fc40.x86_64.efi -rwx------. 1 root root 53M 5. Aug 16:11 4335e4ece7054377bd1fe24ee0898ff3-6.9.12-200.fc40.x86_64.efi Having said that, there appears to be another EFI folder in /boot: $ sudo ls -lh /boot | grep -i efi drwx------. 6 root root 4,0K 1. Jan 1970 efi drwxr-xr-x. 3 root root 4,0K 5. Aug 16:11 EFI -rw-r--r--. 1 root root 150K 25. Jan 2024 memtest86+x64.efi Looking at the dates, it appears to bbave been created once I installed the first UKI. It contains a Linux folder, modified today (last UKI update), which is empty: $ sudo ls -lhR /boot/EFI /boot/EFI: insgesamt 4,0K drwxr-xr-x. 2 root root 4,0K 13. Aug 08:59 Linux /boot/EFI/Linux: insgesamt 0 This could be related.
Judging by the timestamps, /boot/EFI appears to have been created by kernel-uki-virt rather than virt-firmware or uki-direct: 1834 | install kernel-uki-virt | 05-08-2024 16:10 | Install | 1 1833 | install virt-firmware uki-direct | 05-08-2024 16:08 | Install | 4 EE drwxr-xr-x. 3 root root 4,0K 5. Aug 16:11 EFI -rwx------. 1 root root 53M 5. Aug 16:11 4335e4ece7054377bd1fe24ee0898ff3-6.9.12-200.fc40.x86_64.efi
(In reply to Julian Sikorski from comment #4) > Judging by the timestamps, /boot/EFI appears to have been created by > kernel-uki-virt rather than virt-firmware or uki-direct: > Correct, /boot/EFI is an unfortunate leftover. When kernel-uki-virt installs, /usr/lib/kernel/install.d/90-uki-copy.install script (from systemd) copies it to /boot/EFI because it expects ESP being mounted to either /boot or /efi but not /boot/efi. From https://uapi-group.org/specifications/specs/boot_loader_specification/ ``` Mounting the ESP to /boot/efi/, as was traditionally done, is not recommended. ``` and Fedora does precisely that. To workaround the problem, 99-uki-uefi-setup.install (from virt-firmware) _moves_ the UKI to /boot/efi/ but the empty directory remains. The long term solution is likely for Fedora to stop using /boot/efi altogether.
With 6.10.5 installed 6.9.12 got removed. I got this after 2 reboots: $ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # C O - 0002 - Fedora # O - 0000 - Windows Boot Manager # O - 0001 - Fedora Linux 40 (Workstation Edition) 6.10.5-200.fc40.x86_64 (UKI) Can it be that firmware somehow limits the number of entries to three? Would not be the first questionable decision made by Asus.
Smells like a firmware bug indeed. Might be the firmware considers the entry being a duplicate due to both pointing to shim.efi, even though the command line is different (use 'kernel-bootcfg --show --verbose' to see that).
Accidentally I happened to install two kernel updates without rebooting. After installing the 2nd one kernel-bootcfg output looked like this: # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # N - 0004 - Fedora Linux 40 (Workstation Edition) 6.10.7-200.fc40.x86_64 (UKI) # -> path: Partition(nr=1)/FilePath(\EFI\fedora\shimx64.efi) # -> opt/ucs16: \EFI\Linux\4335e4ece7054377bd1fe24ee0898ff3-6.10.7-200.fc40.x86_64.efi root=UUID=1b526e6f-bd6a-4355-9f2c-a10852969002 ro rootflags=subvol=root rhgb quiet # # C O - 0002 - Fedora # -> path: Partition(nr=1)/FilePath(\EFI\FEDORA\SHIM.EFI) # -> opt/hex: 0000424f # # O - 0000 - Windows Boot Manager # -> path: Partition(nr=1)/FilePath(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI) # -> opt/hex: 57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d000000ffff0100000010000000040000007fff0400 # # O - 0001 - Fedora Linux 40 (Workstation Edition) 6.10.5-200.fc40.x86_64 (UKI) # -> path: Partition(nr=1)/FilePath(\EFI\fedora\shimx64.efi) # -> opt/ucs16: \EFI\Linux\4335e4ece7054377bd1fe24ee0898ff3-6.10.5-200.fc40.x86_64.efi root=UUID=1b526e6f-bd6a-4355-9f2c-a10852969002 ro rootflags=subvol=root rhgb quiet # # - 0003 - Fedora Linux 40 (Workstation Edition) 6.10.6-200.fc40.x86_64 (UKI) # -> path: Partition(nr=1)/FilePath(\EFI\fedora\shimx64.efi) # -> opt/ucs16: \EFI\Linux\4335e4ece7054377bd1fe24ee0898ff3-6.10.6-200.fc40.x86_64.efi root=UUID=1b526e6f-bd6a-4355-9f2c-a10852969002 ro rootflags=subvol=root rhgb quiet # After the first reboot, it changed to the following: # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # O - 0002 - Fedora # -> path: Partition(nr=1)/FilePath(\EFI\FEDORA\SHIM.EFI) # -> opt/hex: 0000424f # # O - 0000 - Windows Boot Manager # -> path: Partition(nr=1)/FilePath(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI) # -> opt/hex: 57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d000000ffff0100000010000000040000007fff0400 # # O - 0001 - Fedora Linux 40 (Workstation Edition) 6.10.5-200.fc40.x86_64 (UKI) # -> path: Partition(nr=1)/FilePath(\EFI\fedora\shimx64.efi) # -> opt/ucs16: \EFI\Linux\4335e4ece7054377bd1fe24ee0898ff3-6.10.5-200.fc40.x86_64.efi root=UUID=1b526e6f-bd6a-4355-9f2c-a10852969002 ro rootflags=subvol=root rhgb quiet # # O - 0003 - Fedora Linux 40 (Workstation Edition) 6.10.6-200.fc40.x86_64 (UKI) # -> path: Partition(nr=1)/FilePath(\EFI\fedora\shimx64.efi) # -> opt/ucs16: \EFI\Linux\4335e4ece7054377bd1fe24ee0898ff3-6.10.6-200.fc40.x86_64.efi root=UUID=1b526e6f-bd6a-4355-9f2c-a10852969002 ro rootflags=subvol=root rhgb quiet # # C O - 0004 - Fedora Linux 40 (Workstation Edition) 6.10.7-200.fc40.x86_64 (UKI) # -> path: Partition(nr=1)/FilePath(\EFI\fedora\shimx64.efi) # -> opt/ucs16: \EFI\Linux\4335e4ece7054377bd1fe24ee0898ff3-6.10.7-200.fc40.x86_64.efi root=UUID=1b526e6f-bd6a-4355-9f2c-a10852969002 ro rootflags=subvol=root rhgb quiet # After the second reboot, only the 6.10.5 remained. In any case, UKI seems not to be functional on this laptop. I have removed the packages for now. If I ever figure out how to expand the ESP on my desktop, I will test and report back.
> In any case, UKI seems not to be functional on this laptop. Looks like that. If you are using secure boot I do not see an easy way out. When *not* using secure boot you might want try one of these options: (1) use systemd-boot. Latest virt-firmware will detect that the system has been booted with systemd-boot. In that case it will *not* update UEFI boot configuration, instead it will depend on systemd-boot picking the most recent UKI kernel. (2) remove shim. In that case latest virt-firmware will create UEFI boot entries pointing to the UKI directly, which might workaround the firmware bug because 'path' will be different for each entry then.
I use SecureBoot and am dual-booting Windows so turning it off is not really something I would like to do, as it requires me to re-enter the BitLocker key. Having said that, I managed to extend the ESP on my Desktop to 500 MB and installed UKI on it. I need to wait until 6.10.8 drops to see how the updates behave. So far I have discovered the following: - despite booting directly from UEFI (but via shim), MOKs are working. Both xone and nvidia modules can be loaded - while nvidia module can be loaded, there appears to be a conflict with nouveau, which does not happen when booting via grub: Sep 03 10:07:32 kernel: [drm] Initialized nouveau 1.4.0 20120801 for 0000:0a:00.0 on minor 0 Sep 03 10:07:32 kernel: fbcon: nouveaudrmfb (fb0) is primary device Sep 03 10:07:32 kernel: Console: switching to colour frame buffer device 430x90 Sep 03 10:07:32 kernel: nouveau 0000:0a:00.0: [drm] fb0: nouveaudrmfb frame buffer device Sep 03 10:07:33 kernel: nvidia: loading out-of-tree module taints kernel. Sep 03 10:07:33 kernel: nvidia: module license 'NVIDIA' taints kernel. Sep 03 10:07:33 kernel: Disabling lock debugging due to kernel taint Sep 03 10:07:33 kernel: nvidia: module license taints kernel. Sep 03 10:07:33 kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 510 Sep 03 10:07:33 kernel: NVRM: GPU 0000:0a:00.0 is already bound to nouveau. Sep 03 10:07:33 kernel: NVRM: The NVIDIA probe routine was not called for 1 device(s). Sep 03 10:07:33 kernel: NVRM: This can occur when another driver was loaded and NVRM: obtained ownership of the NVIDIA device(s). Sep 03 10:07:33 kernel: NVRM: Try unloading the conflicting kernel module (and/or NVRM: reconfigure your kernel without the conflicting NVRM: driver(s)), then try loading the NVIDIA kernel module NVRM: again. Sep 03 10:07:33 kernel: NVRM: No NVIDIA devices probed. Sep 03 10:07:33 kernel: nvidia-nvlink: Unregistered Nvlink Core, major device number 510 Might be something worth mentioning for phase 3.
echo "blacklist nouveau" | sudo tee /etc/modprobe.d/no-nouveau.conf I'd suggest to open a bug against the nvidia driver, the rpm should simply include that config file instead of adding 'modprobe.blacklist=nouveau' to the kernel command line. The 'rd.driver.blacklist=nouveau' also added is not needed with the UKI because that does not include drm drivers in the first place. And for the non-UKI case this should probably be replaced by a config file too (/etc/dracut.conf.d/...).
Thanks for the tip regarding nvidia, I will test it later and report it to RPM Fusion if it helps. In other news, UKI kernel has remained the default after the 2nd reboot on my desktop: # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # N - 0001 - Fedora Linux 40 (Workstation Edition) 6.10.7-200.fc40.x86_64 (UKI) # C O - 0004 - Fedora # O - 0000 - Windows Boot Manager # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # C O - 0001 - Fedora Linux 40 (Workstation Edition) 6.10.7-200.fc40.x86_64 (UKI) # O - 0004 - Fedora # O - 0000 - Windows Boot Manager I will check what happens after a kernel update, but so far it looks like this bug was a problem with ASUS firmware after all.
It mostly looks like the issues I was seeing were causes by buggy ASUS firmware. After installing 6.10.8 update everything is working as expected: $ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # C O - 0002 - Fedora Linux 40 (Workstation Edition) 6.10.8-200.fc40.x86_64 (UKI) # O - 0001 - Fedora Linux 40 (Workstation Edition) 6.10.7-200.fc40.x86_64 (UKI) # O - 0004 - Fedora # O - 0000 - Windows Boot Manager For the record, the motherboard on my desktop is an ASRock Fatal1ty B450 Gaming-ITX/ac. Blacklisting nouveau using a config file has worked as well, I am going to bring that up to the RPM Fusion maintainers. Having said that, there is a difference in how kernel-bootcfg-boot-successful.service behaves: $ sudo dnf history kernel-uki-virt Kennun | Befehlszeile | Datum und Zeit | Aktion(en) | Verände ---------------------------------------------------------------------------------------------------------------------------------------------- 2769 | update kernel-6.10.8-200.fc40.x86_64.rpm kernel-core-6.10.8-200.fc40.x86_64.rpm kernel- | 05-09-2024 14:35 | C, E, I, U | 22 E< 2765 | --enablerepo=updates-testing --enablerepo=rpmfusion-free-updates-testing --enablerepo=r | 03-09-2024 10:06 | Install | 1 >E $ sudo journalctl --no-hostname --unit=kernel-bootcfg-boot-successful.service -- 6.10.7 installed here-- Sep 03 10:07:30 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 03 10:07:31 kernel-bootcfg[985]: INFO: Add BootCurrent (Boot0001) to BootOrder Sep 03 10:07:31 kernel-bootcfg[985]: INFO: updating /sys/firmware/efi/efivars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c Sep 03 10:07:31 kernel-bootcfg[985]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 03 10:07:31 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Sep 03 11:46:28 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 03 11:46:28 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot 3a470e5c03544528af1050341d27e10e -- Sep 04 22:28:51 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 04 22:28:52 kernel-bootcfg[985]: INFO: No update needed, BootCurrent is already in BootOrder. Sep 04 22:28:52 kernel-bootcfg[985]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 04 22:28:52 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Sep 04 22:48:24 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 04 22:48:24 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot aa306df2b7454971b6429d9be7a41eee -- Sep 05 14:27:37 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 05 14:27:37 kernel-bootcfg[966]: INFO: No update needed, BootCurrent is already in BootOrder. Sep 05 14:27:37 kernel-bootcfg[966]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 05 14:27:37 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- 6.10.8 update installed here -- Sep 05 14:41:37 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 05 14:41:37 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot b528fd9b2c4241729763a002383a0661 -- Sep 05 23:17:41 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 05 23:17:42 kernel-bootcfg[986]: INFO: Add BootCurrent (Boot0002) to BootOrder Sep 05 23:17:42 kernel-bootcfg[986]: INFO: updating /sys/firmware/efi/efivars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c Sep 05 23:17:42 kernel-bootcfg[986]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 05 23:17:42 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. In places where on the laptop it says: INFO: No update needed, BootCurrent is already in BootOrder. on the desktop it says: INFO: Add BootCurrent (Boot0002) to BootOrder INFO: updating /sys/firmware/efi/efivars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c If the efivars are controlled by the firmware as well, the problem would still be on ASUS.
Interesting development on my desktop machine - the oldest boot UKI entry seems to have disappeared: $ rpm -q kernel-uki-virt kernel-uki-virt-6.10.7-200.fc40.x86_64 kernel-uki-virt-6.10.8-200.fc40.x86_64 kernel-uki-virt-6.10.9-200.fc40.x86_64 $ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # C O - 0001 - Fedora Linux 40 (Workstation Edition) 6.10.9-200.fc40.x86_64 (UKI) # O - 0002 - Fedora Linux 40 (Workstation Edition) 6.10.8-200.fc40.x86_64 (UKI) # O - 0004 - Fedora # O - 0000 - Windows Boot Manager $ sudo journalctl --no-hostname --unit=kernel-bootcfg-boot-successful.service -- 6.10.7 installed here-- Sep 03 10:07:30 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 03 10:07:31 kernel-bootcfg[985]: INFO: Add BootCurrent (Boot0001) to BootOrder Sep 03 10:07:31 kernel-bootcfg[985]: INFO: updating /sys/firmware/efi/efivars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c Sep 03 10:07:31 kernel-bootcfg[985]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 03 10:07:31 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Sep 03 11:46:28 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 03 11:46:28 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot 3a470e5c03544528af1050341d27e10e -- Sep 04 22:28:51 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 04 22:28:52 kernel-bootcfg[985]: INFO: No update needed, BootCurrent is already in BootOrder. Sep 04 22:28:52 kernel-bootcfg[985]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 04 22:28:52 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Sep 04 22:48:24 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 04 22:48:24 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot aa306df2b7454971b6429d9be7a41eee -- Sep 05 14:27:37 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 05 14:27:37 kernel-bootcfg[966]: INFO: No update needed, BootCurrent is already in BootOrder. Sep 05 14:27:37 kernel-bootcfg[966]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 05 14:27:37 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- 6.10.8 update installed here -- Sep 05 14:41:37 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 05 14:41:37 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot b528fd9b2c4241729763a002383a0661 -- Sep 05 23:17:41 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 05 23:17:42 kernel-bootcfg[986]: INFO: Add BootCurrent (Boot0002) to BootOrder Sep 05 23:17:42 kernel-bootcfg[986]: INFO: updating /sys/firmware/efi/efivars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c Sep 05 23:17:42 kernel-bootcfg[986]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 05 23:17:42 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Sep 05 23:49:47 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 05 23:49:47 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot a42fd986765d4c50b702391acdf6c6b1 -- Sep 06 08:23:07 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 06 08:23:07 kernel-bootcfg[962]: INFO: No update needed, BootCurrent is already in BootOrder. Sep 06 08:23:07 kernel-bootcfg[962]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 06 08:23:07 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Sep 06 16:56:26 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 06 16:56:26 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot 85f0c7d6fdd94a96a2c29d6d9ce3f965 -- Sep 06 19:45:52 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 06 19:45:53 kernel-bootcfg[995]: INFO: No update needed, BootCurrent is already in BootOrder. Sep 06 19:45:53 kernel-bootcfg[995]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 06 19:45:53 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. Sep 06 19:48:16 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 06 19:48:16 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot 28e09cedeaf64627a524aeff71abc658 -- Sep 10 08:36:24 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 10 08:36:24 kernel-bootcfg[958]: INFO: No update needed, BootCurrent is already in BootOrder. Sep 10 08:36:24 kernel-bootcfg[958]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 10 08:36:24 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- 6.10.9 update installed here -- Sep 10 09:22:22 systemd[1]: kernel-bootcfg-boot-successful.service: Deactivated successfully. Sep 10 09:22:22 systemd[1]: Stopped kernel-bootcfg-boot-successful.service - UKI Successful Boot. -- Boot 60f975fb946b40a5aae011f1fb8efb36 -- Sep 11 14:22:38 systemd[1]: Starting kernel-bootcfg-boot-successful.service - UKI Successful Boot... Sep 11 14:22:39 kernel-bootcfg[972]: INFO: Add BootCurrent (Boot0001) to BootOrder Sep 11 14:22:39 kernel-bootcfg[972]: INFO: updating /sys/firmware/efi/efivars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c Sep 11 14:22:39 kernel-bootcfg[972]: INFO: Updating /boot/efi/EFI/fedora/BOOTX64.CSV Sep 11 14:22:39 systemd[1]: Finished kernel-bootcfg-boot-successful.service - UKI Successful Boot.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.