Grub boot menu not showing after enlarging /boot/efi partition and restoring Windows bootloader through bcdboot

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.

You could try manage-bde status to double-check?


It’s in italian, but basically says:
Bitlocker version: None

So yeah there is no bitlocker

1 Like

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