In CMD running:
manage-bde -protectors -get C:
says that it doesnt find a key, so I guess I deactivated it because maybe I read that it could give problem while dual booting?
Ah, that would make sense. If youâre reading your Windows drive from Linux then presumably you would have deactivated it for that reason.
Upon deleting windows entries we correctly boot in grub menu without goinf with boot menu with success!
Thanks to:
@pg-tips @anotheruser @augenauf @vekruse for having the patience to deal with me with this issue.
1 Like
Youâre welcome, that was an interesting one and I didnât predict the plot twist with the UKI kernels.
Since this thread is already pretty long, you might want to start a new topic on how to remove those UKI kernels / packages and revert to the normal way of installing kernels.
Iâm guessing that if you ls /boot you donât have vmlinuz, initramfs etc files for your kernels in your boot partition? See mine below for comparison
$ ls -al /boot
total 1163061
dr-xr-xr-x. 6 root root 4096 2025-10-31 14:05 .
dr-xr-xr-x. 19 root root 4096 2025-08-01 10:58 ..
-rw-r--r--. 1 root root 290048 2025-10-02 01:00 config-6.16.10-200.fc42.x86_64
-rw-r--r--. 1 root root 290048 2025-10-06 01:00 config-6.16.11-200.fc42.x86_64
-rw-r--r--. 1 root root 290048 2025-10-12 01:00 config-6.16.12-200.fc42.x86_64
-rw-r--r--. 1 root root 292938 2025-10-19 01:00 config-6.17.4-200.fc42.x86_64
-rw-r--r--. 1 root root 292938 2025-10-23 01:00 config-6.17.5-200.fc42.x86_64
drwx------. 3 root root 1024 1970-01-01 01:00 efi
drwx------. 3 root root 4096 2025-11-05 09:55 grub2
-rw-------. 1 root root 274697051 2025-09-10 13:58 initramfs-0-rescue-710adb0a2d8145e289d6b7d549ffa38f.img
-rw-------. 1 root root 149162876 2025-10-07 16:21 initramfs-6.16.10-200.fc42.x86_64.img
-rw-------. 1 root root 149171466 2025-10-14 09:35 initramfs-6.16.11-200.fc42.x86_64.img
-rw-------. 1 root root 149761614 2025-10-18 17:33 initramfs-6.16.12-200.fc42.x86_64.img
-rw-------. 1 root root 149753903 2025-10-22 09:30 initramfs-6.17.4-200.fc42.x86_64.img
-rw-------. 1 root root 150179917 2025-10-31 14:05 initramfs-6.17.5-200.fc42.x86_64.img
drwxr-xr-x. 3 root root 4096 2025-02-19 15:50 loader
drwx------. 2 root root 16384 2025-02-19 15:30 lost+found
lrwxrwxrwx. 1 root root 47 2025-10-07 16:21 symvers-6.16.10-200.fc42.x86_64.xz -> /lib/modules/6.16.10-200.fc42.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 47 2025-10-14 09:35 symvers-6.16.11-200.fc42.x86_64.xz -> /lib/modules/6.16.11-200.fc42.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 47 2025-10-18 17:33 symvers-6.16.12-200.fc42.x86_64.xz -> /lib/modules/6.16.12-200.fc42.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 46 2025-10-22 09:30 symvers-6.17.4-200.fc42.x86_64.xz -> /lib/modules/6.17.4-200.fc42.x86_64/symvers.xz
lrwxrwxrwx. 1 root root 46 2025-10-31 14:05 symvers-6.17.5-200.fc42.x86_64.xz -> /lib/modules/6.17.5-200.fc42.x86_64/symvers.xz
-rw-r--r--. 1 root root 11840761 2025-10-02 01:00 System.map-6.16.10-200.fc42.x86_64
-rw-r--r--. 1 root root 11840823 2025-10-06 01:00 System.map-6.16.11-200.fc42.x86_64
-rw-r--r--. 1 root root 11847227 2025-10-12 01:00 System.map-6.16.12-200.fc42.x86_64
-rw-r--r--. 1 root root 12020373 2025-10-19 01:00 System.map-6.17.4-200.fc42.x86_64
-rw-r--r--. 1 root root 12020817 2025-10-23 01:00 System.map-6.17.5-200.fc42.x86_64
-rwxr-xr-x. 1 root root 17652072 2025-09-10 13:58 vmlinuz-0-rescue-710adb0a2d8145e289d6b7d549ffa38f
-rwxr-xr-x. 1 root root 17656168 2025-10-02 01:00 vmlinuz-6.16.10-200.fc42.x86_64
-rw-r--r--. 1 root root 162 2025-10-02 01:00 .vmlinuz-6.16.10-200.fc42.x86_64.hmac
-rwxr-xr-x. 1 root root 17652072 2025-10-06 01:00 vmlinuz-6.16.11-200.fc42.x86_64
-rw-r--r--. 1 root root 162 2025-10-06 01:00 .vmlinuz-6.16.11-200.fc42.x86_64.hmac
-rwxr-xr-x. 1 root root 17656168 2025-10-12 01:00 vmlinuz-6.16.12-200.fc42.x86_64
-rw-r--r--. 1 root root 162 2025-10-12 01:00 .vmlinuz-6.16.12-200.fc42.x86_64.hmac
-rwxr-xr-x. 1 root root 18257960 2025-10-19 01:00 vmlinuz-6.17.4-200.fc42.x86_64
-rw-r--r--. 1 root root 161 2025-10-19 01:00 .vmlinuz-6.17.4-200.fc42.x86_64.hmac
-rwxr-xr-x. 1 root root 18257960 2025-10-23 01:00 vmlinuz-6.17.5-200.fc42.x86_64
-rw-r--r--. 1 root root 161 2025-10-23 01:00 .vmlinuz-6.17.5-200.fc42.x86_64.hmac
I would guess that someone was testing the uki images using the instructions at https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2.
I canât image any other way that this could have happened. This also includes installing the packages uki-direct and python3-virt-firmware which are used to manipulate the uefi boot menu when upgrading kernel-uki.
Thatâs where the neat part comes, I also have all the initramfs, symverses, maps, vmlinuz files of all of the kernels, I will soon start a new thread on that, also I have no idea which answer to point as Solution since itâs more like a path ahahah
If by someone you mean me I didnât know what a UKI was until today and I never saw those two packages before lmao
@vekruse I might have to call you in action once again ahaha.
After fedora updated from 6.17.7, it appears that the install automatically modified efi entries and removed grub entry and instead put 6.17.7 and 6.17.7 debug in its place, so basically what it did was:
Before:
Boot0001* Fedora HD(1,GPT,50167b90-e0e8-41dc-a91a-6749808556ab,0x800,0x190000)/\EFI\fedora\shimx64.efi
After:
Boot0000* Windows Boot Manager HD(1,GPT,50167b90-e0e8-41dc-a91a-6749808556ab,0x800,0x190000)/\EFI\Microsoft\Boot\bootmgfw.efi0000424f
Boot0001* Fedora Linux 41 (Workstation Edition) 6.17.7-100.fc41.x86_64 (UKI) on EFI system partition HD(1,GPT,50167b90-e0e8-41dc-a91a-6749808556ab,0x800,0x190000)/\EFI\fedora\shimx64.efi
**Debug kernel**
And when I booted it also booted directly in debug kernel (weird asf lol), so upon deleting debug kernel entry and booting through F11 boot menu in fedora, I regenerated grub entry through:
sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Fedora" -l '\EFI\fedora\shimx64.efi'
And through F11 in that partition GRUB menu shows up once again, so I assume that once again when I remove the other entries from efibootmgr the system will boot back up in the menu.
The problem is that obviously whenever Fedora is going to update following this behaviour the entry is going to be deleted and replaced with those goddamn kernel-ukis, which I have yet to find a solution for.
Claude suggests either:
- creating a config file for grubby and putting the line:
BOOT_ROOT=/boot
- Running:
sudo grub2-install --no-nvram --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=fedora
saying that the flag --no-nvram tells grub to not touch EFI entries
3. Creating a hook script that regenerates the entry each time an update happens.
Iâm guessing that disabling all this UKI stuff will fix all of the problems, Iâm just unsure on how to proceed.
At that point when the system is booting with grub, all the kernel-uki-virt packages should be removed together with the uki-direct packages. Also you may have inadvertently installed some âkernel*â packages shouldnât be installed, for example by running dnf install 'kernel*' or something similar.
So run rpm -qa 'kernel*' to see whate is actually installed on the system.
Stop right there. Doing this destroys the ability to boot in secure mode. It probably wonât allow you do that anyway.
The right way is to run dnf reinstall 'grub2*'.
Sorry if I answer late,
This fixes what problem? The deletion of grub efi entry and the replacement with UKIs?