This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
UKIs need this to find the root filesystem without root=⌠on the kernel command line.
dnf install kernel-uki-virt
kernel-bootcfg --show
optional step, shows UEFI boot configuration, the new UKI should be added as BootNext
$ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # N - 0008 - 6.5.7-300.fc39.x86_64 <= entry for the the new kernel # C O - 0007 - 6.5.6-300.fc39.x86_64 <= currently running kernel # O - 0006 - Fedora <= grub2 entry # O - 0001 - UEFI QEMU QEMU HARDDISK [ ⌠]
reboot
kernel-bootcfg --show
optional again, after successful boot the new kernel should be first in BootOrder.
$ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # C O - 0008 - 6.5.7-300.fc39.x86_64 # O - 0007 - 6.5.6-300.fc39.x86_64 # O - 0006 - Fedora # O - 0001 - UEFI QEMU QEMU HARDDISK [ ⌠]
known workaround: add a vTPM to the guest configuration.
Booting another kernel
From the booted system:
uefi-boot-menu --reboot
From the firmware:
If your UEFI firmware offers an boot menu you should be able to use that to select the kernel to boot. Unfortunately this is not standardized so there is no standard procedure to do so.
Virtual machines (OVMF): Enter the firmware setup by pressing ESC when you see the tianocore splash screen. Select âBoot Managerâ in the toplevel menu.
Thinkpad laptops: Interupt normal boot (just âEnterâ on recent hardware, or using the special key on older models), then press F12 (âchoose a temporary startup deviceâ).
User Experience
Dependencies
Contingency Plan
Contingency mechanism:
drop kickstart file for the uefi-only cloud image.
Contingency deadline: N/A (not a System Wide Change)
This all seems reasonable, but could you possibly add (to the change or just release notes later) what the use cases/reasons to use this is?
I guess its all just incremental progress to a goal, but if we are making these images and testing them and hoping our users help test them and provide feedback, it might be nice to explain when someone might want to use them?
Might be thereâs something I missed here reading back after the holidays.
sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh
but i forgot what it was. is it safe to run it the second time, just to paste it here?
also, the kernel-bootcfg-boot-successful.service fails with the following errors in journalctl
May 17 10:23:04 fedora kernel-bootcfg[1375]: INFO: No update needed, BootCurrent is already in BootOrder.
May 17 10:23:04 fedora kernel-bootcfg[1375]: Traceback (most recent call last):
May 17 10:23:04 fedora kernel-bootcfg[1375]: File "/usr/bin/kernel-bootcfg", line 33, in <module>
May 17 10:23:04 fedora kernel-bootcfg[1375]: sys.exit(load_entry_point('virt-firmware==24.4', 'console_scripts', 'kernel-bootcfg')())
May 17 10:23:04 fedora kernel-bootcfg[1375]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
May 17 10:23:04 fedora kernel-bootcfg[1375]: File "/usr/lib/python3.12/site-packages/virt/firmware/bootcfg/main.py", line 305, in main
May 17 10:23:04 fedora kernel-bootcfg[1375]: update_boot_csv(cfg, options)
May 17 10:23:04 fedora kernel-bootcfg[1375]: File "/usr/lib/python3.12/site-packages/virt/firmware/bootcfg/main.py", line 168, in update_boot_csv
May 17 10:23:04 fedora kernel-bootcfg[1375]: if entry.devicepath != shimpath:
May 17 10:23:04 fedora kernel-bootcfg[1375]: ^^^^^^^^^^^^^^^^
May 17 10:23:04 fedora kernel-bootcfg[1375]: AttributeError: 'NoneType' object has no attribute 'devicepath'
May 17 10:23:04 fedora systemd[1]: kernel-bootcfg-boot-successful.service: Main process exited, code=exited, status=1/FAILURE
but everything seems to be working correctly, even TPM based unlocking of the root partition (i configured it with all 10 PCRs 0-9)
sorry for the huge delay, somehow i wasnât notified of your message (and iâm back on fedora)
hereâs the output of the sh command
~ sudo sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh
# /dev/nvme0n1 2 -> BC13C2FF-59E6-4262-A352-B275FD6F7172
+ sfdisk --part-type /dev/nvme0n1 2 BC13C2FF-59E6-4262-A352-B275FD6F7172
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or partx(8).
Syncing disks.
# unknown device: /dev/mapper/fedora-root
May 31 23:09:50 fedora kernel-bootcfg[2559]: INFO: No update needed, BootCurrent is already in BootOrder.
May 31 23:09:50 fedora kernel-bootcfg[2559]: Traceback (most recent call last):
May 31 23:09:50 fedora kernel-bootcfg[2559]: File "/usr/bin/kernel-bootcfg", line 33, in <module>
May 31 23:09:50 fedora kernel-bootcfg[2559]: sys.exit(load_entry_point('virt-firmware==24.4', 'console_scripts', 'kernel-bootcfg')())
May 31 23:09:50 fedora kernel-bootcfg[2559]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
May 31 23:09:50 fedora kernel-bootcfg[2559]: File "/usr/lib/python3.12/site-packages/virt/firmware/bootcfg/main.py", line 305, in main
May 31 23:09:50 fedora kernel-bootcfg[2559]: update_boot_csv(cfg, options)
May 31 23:09:50 fedora kernel-bootcfg[2559]: File "/usr/lib/python3.12/site-packages/virt/firmware/bootcfg/main.py", line 168, in update_boot_csv
May 31 23:09:50 fedora kernel-bootcfg[2559]: if entry.devicepath != shimpath:
May 31 23:09:50 fedora kernel-bootcfg[2559]: ^^^^^^^^^^^^^^^^
May 31 23:09:50 fedora kernel-bootcfg[2559]: AttributeError: 'NoneType' object has no attribute 'devicepath'
May 31 23:09:50 fedora systemd[1]: kernel-bootcfg-boot-successful.service: Main process exited, code=exited, status=1/FAILURE
kernel-bootcfg --verbose
# C - BootCurrent, N - BootNext, O - BootOrder
# --------------------------------------------
# C O - 0000 - Fedora
# -> path: Partition(nr=1)/FilePath(\EFI\fedora\shim.efi)
# -> opt/hex: 5243
#
# O - 2001 - EFI USB Device
# -> path:
# -> opt/hex: 5243
#
# O - 3000 - Internal Hard Disk or Solid State Disk
# -> path:
# -> opt/hex: 5243
#
# O - 2002 - [ missing ]
# O - 2004 - [ missing ]
# - 0001 - 6.8.10-300.fc40.x86_64
# -> path: Partition(nr=1)/FilePath(\EFI\fedora\shimx64.efi)
# -> opt/ucs16: \EFI\Linux\46ec5efd86754b4aafddfbb77f6e3ef9-6.8.10-300.fc40.x86_64.efi root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.luks.uuid=luks-5514491e-4c37-4a55-9c85-2d47f3b887a3 rhgb quiet loglevel=3 systemd.show_status=auto amdgpu.sg_display=0 amdgpu.dcdebugmask=0x10 vconsole.font=ter-v28n
#
# - 0004 - Fedora
# -> path: Partition(nr=1)/FilePath(\EFI\fedora\shimx64.efi)
#
Ok, the script doesnât find the root filesystem partition because the root filesystem is on lvm.
The error is harmless, but you need to pass the root filesystem location on the kernel command line because the systemd autodetection works for partitions only. But apparently you figured that already
The kernel-bootcfg-boot-successful.service error is triggered by the missing boot entries. Fixed that in the git repo, with the next python3-virt-firmware update the error should go away.
If shim is always there, whatâs the story for custom signatures? Would it make sense to distinguish the default boot path from generally supported boot paths? I think great care should be put towards not hardcoding shim as a dependency anywhere (though it does make sense to have it in the default boot path).
The systemd folk have often warned system designers that BIOSes are buggy and that the NAND used to store information like boot configuration are often not of the greatest quality. When the NAND wears out or you EFI is buggy and your system does not boot as expected, whatâs the contingency plan?
There is a bootloader spec that provides automatic rollbacks and file-drop-based configuration and both grub and sd-boot follow it. Whatâs the story for these use cases if we exclusively rely on EFI boot menu?
Currently, any UEFI-compliant system will boot, without any manual configuration, a disk containing a valid ESP. With a bootloader, I can guarantee that what is booted is the latest known-working UKI that was put on there. Can something similar be achieved with shim+uki?
Iâm not arguing that bootloader support should be baked in and hardcoded. Just like shim, it should be an element that should be easily discardable if one does not need it. But there is merit in using one by default.
(4) This magic is done by /boot/efi/EFI/BOOT/fbx64.efi (part of shim-x64.rpm) which creates the boot configuration in case it does not exist. Works for UKIs too (otherwise the cloud image wouldnât boot âŚ).
(1) Not using shim is not really an option due to (4). Nevertheless the tools do not insist on shim.efi being present, if the firmware can boot the UKI (for example if secure boot is disabled) they happily create boot entries without shim in the loop.
(2) There is no fallback for broken UEFI implementations.
(3) New kernels are booted once via BootNext, only of that works the change is made permanent in the UEFI configuration.
The workflow is modeled largely after bootloaderspec type 2 entries. Once we have a secure boot support story for sd-boot it should be relatively simple to switch over.
Summary