Use flags: dracut efistub systemd uki ukify -grub -refind -systemd-boot After installing the kernel, I would expect the boot order to be updated, but it does not. BootNext: 0001 BootCurrent: 0002 Timeout: 1 seconds BootOrder: 0002,0000 Boot0000* Windows Boot Manager HD(1,GPT,d46ae804-c639-4c9b-b1b2-2dfabb55dedc,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000031000100000010000000040000007fff0400 Boot0001* Gentoo Linux 2.14 6.6.28-gentoo-dist (UKI) HD(1,GPT,c12a7328-f81f-11d2-ba4b-00a0c93ec93b,0x800,0x200000)/File(\EFI\Linux\38e65513f3a07521ee10eb466607ea26-6.6.28-gentoo-dist.efi) Boot0002* 6.6.21-gentoo-dist (UKI) HD(1,GPT,c12a7328-f81f-11d2-ba4b-00a0c93ec93b,0x800,0x200000)/File(\EFI\Linux\38e65513f3a07521ee10eb466607ea26-6.6.21-gentoo-dist.efi) When I then depclean the old kernel out, it will only boot to Windows.
Please see: https://wiki.gentoo.org/wiki/EFI_stub#Systemd_kernel-install Kernel-bootcfg from virt-manager creates the new entry and sets it as BootNext, then on successful reboot the systemd service kernel-bootcfg-boot-successful.service is responsible for adding the new entry to the bootorder. This is working correctly since you have > BootNext: 0001 And 0001 is the entry for Gentoo If you firmware boots directly into windows on reboot then it does not respect BootNext and this means you unfortunately cannot use efistub booting on that machine. If it boots into Gentoo correctly on the first reboot, but then reboots into windows on consecutive reboots then you have not enabled the kernel-bootcfg-boot-successful.service systemd service. If the firmware does respect BootNext, and the systemd service is enabled, and it still does not update the bootorder, then your firmware does not allow adjusting the bootorder from the OS (this is not uncommon) and this also unfortunately means you cannot use efistub booting on that machine. Note that some systems do allow adjusting the bootorder from the OS, but only if Secure Boot is enabled and the efi file that was booted is signed with an accepted key (NOT via sys-boot/shim). So please double check that you have enabled kernel-bootcfg-boot-successful.service and that it exits successfully after rebooting. If this is setup correctly and the service exists successfully but it still does not work then this is another case of a "bugged" UEFI firmware. You can try updating the firmware, but if that does not resolve the issue I recommend using systemd-boot or rEFInd instead.
Ah yes, I had not enabled kernel-bootcfg-boot-successful -- thanks!
