Bug 2303676
| Summary: | BootOrder does not get updated upon a successful BootNext, entries disappear | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Julian Sikorski <belegdol> |
| Component: | python-virt-firmware | Assignee: | Gerd Hoffmann <kraxel> |
| Status: | NEW --- | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 42 | CC: | kraxel, vkuznets |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Julian Sikorski
2024-08-08 12:55:02 UTC
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. |