From this list, I would say that /dev/nvme0n1p1 is your ESP (EFI System Partition, which exists on GPT formated drives) and /dev/nvme0n1p5 is a BTRFS volume, which most likely has a number of subvolumes, including for your /, possibly /home and others that are automatically created in /var. (AFAIK, Fedora does not create a separate /boot anymore since GRUB2 can find everything it needs in a BTRFS subvolume. So, your /boot is probably just a regular directory in your / BTRFS subvolume.) In any case, this should all be pretty irrelevant since this was caused by a Windows update, which usually just messes up the boot entries in your UEFI. In particular, it should not touch any binary in \ESP\fedora\.
Looking at your first post, you wrote that there is a Fedora entry in your UEFI but that selecting it boots Windows. In your next post you wrote that âFedora doesnât appear in the boot order listâ. Which one is it, do you have a UEFI entry for Fedora or not?
From your third post, with the output of efibootmgr -v, I would believe that you actually have a Fedora entry. The \EFI\fedora\shimx64.efi path that you mention there references the ESP. At this point, I would suggest that you check the ESP and make sure that it actually contains these binaries. You can use a slight variation of the commands that @josevillani suggested to do that from a live system:
$ sudo mkdir /mnt/efi
$ sudo mount /dev/nvme0n1p1 /mnt/efi
$ sudo ls -la /mnt/efi
$ sudo ls -la /mnt/efi/EFI/fedora
The last one should show you shimx64.efi and grubx64.efi (assuming that you are on a x86-64 system); shim is used for Secure Boot support, it is signed by Microsoft and it verifies the signature of the GRUB2 binary before handing over control to it, which then in turn loads the kernel, initramfs, etc.
Letâs see what the situation is and then we can look at the next steps.
These steps work but may be overkill. The official Fedora documentation to restore GRUB2 lists multiple steps, with conditional ones depending on things like LUKS or lvm, then bind-mounting /dev, /proc, etc, before finally chrooting. All of this might be intimidating or error-prone for someone new to Linux.
Since the reason for this is usually just the Windows setup making its bootloader the default, I would really try to resolve this with a more targeted approach before breaking out the big guns.
OK, what I get from your pictures and your first posts is that
when selecting the advanced boot options in Windows, it shows an entry âFedoraâ, but selecting that boots straight back into Windows
in your UEFI boot menu, there is no entry âFedoraâ, but
when running efibootmgr from a live system, there is indeed an entry named âFedoraâ, pointing to \EFI\fedora\shimx64.efi.
Is this summary correct? If it is, observations 2 and 3 have me scratching my head. My only explanation for that is that the UEFI implementation does some filtering of the list and removes non-functional entries. Your investigation of the ESP shows that there is no \EFI\fedora, so no shim or GRUB2 binaries either, which leaves the âFedoraâ boot entry unable to boot (this is also consistent with the first observation => after booting with advanced settings from your Windows installation, the UEFI does not find the binary for the âFedoraâ entry and then proceeds to boot the default one, back into Windows).
To fix the missing \EFI\fedora directory and binaries, I think you actually need to follow Fedoraâs documentation. I will adjust the steps to match what we have seen so far, but will keep the same numbering, so you can compare the steps:
Boot a live system. Since you need to download some RPMs towards the end, I suggest you set up networking at this point, too (plug in an Ethernet cable, connect to an access point, open the pidgeon cages, âŚ).
Open a terminal; note: the documentation shows all steps running from a root terminal (indicated by the # in front of the command); I list everything from a user terminal (indicated by $), with sudo prefix. Alternatively, you can elevate your prompt with sudo -i and leave out sudo in the following steps.
Skip, you have already posted the output and my adjustments are based on that.
This step depends on whether you have encrypted your root with LUKS; from what I can tell, you have not, but just for completeness
Skip, I do not see a separate /boot partition in your lsblk output. However, you might have a separate subvolume for that in your BTRFS volume. Unfortunately, I am not sure about Fedora Workstationâs default BTRFS layout â mine are customized â and the documentation is not helpful, as it talks about a separate ext4 /boot, which you clearly do not have. I am going to assume that your /boot is either a directory in your root subvolume or a nested subvolume underneath your root subvolume and is mounted automatically. To check, see if /mnt/fedora/boot contains any files. If it is empty, we need to mount something there. In this case, pause here and post the output of the second and third command:
$ ls /mnt/fedora/boot
$ cat /mnt/fedora/etc/fstab
$ sudo btrfs subvolume list /mnt/fedora
(Bind) Mount runtime directories from the live system inside your Fedora rootfs:
$ sudo mount -o bind /dev /mnt/fedora/dev
$ sudo mount -o bind /proc /mnt/fedora/proc
$ sudo mount -o bind /sys /mnt/fedora/sys
$ sudo mount -o bind /run /mnt/fedora/run
Some more mount points for UEFI systems:
$ sudo mount -o bind /sys/firmware/efi/efivars /mnt/fedora/sys/firmware/efi/efivars
$ sudo mount /dev/nvme0n1p1 /mnt/fedora/boot/efi
Almost there, letâs chroot (change root) into the system on your internal drive (because of the sudo command here, the resulting shell has root privileges and I will leave out sudo in the following steps):
$ sudo chroot /mnt/fedora
Reinstall GRUB2 and shim (in fact, because we are now inside the system on your disk, anything special about your config â like which partition is your rootfs â is now transparent and all the remaining steps are exactly the same as the ones in the official documentation):
# dnf reinstall shim-\* grub2-efi-\* grub2-common
Regenerate the config file:
# grub2-mkconfig -o /boot/grub2/grub.cfg
Write everything to disk, take one last look at your ESP to make sure you now have /EFI/fedora and the binaries inside, and leave the chroot environment:
I have strangely had the boot order changing twice now without having booted into Windows prior. So either something in Fedora triggered it or the EFI bios decided to do it on itâs own. Itâs pretty strange, iâm not sure how to debug something like thatâŚ
I have seen UEFI implementations that automatically add boot entries for the Windows bootloader.
But the point I was trying to make is that Windows shows a âFedoraâ entry, efibootmgr shows a âFedoraâ entry, but the UEFI boot menu does not show that entry. And my only explanation is that the UEFI performs some basic sanity checks on the entries, such as âIs the binary this entry references even available? No. OK, no point showing it then.â
I would probably start by recording the output of efibootmgr and then compare the recorded state to the latest one if/when it happens again. This will show you if it is only the boot order changing or if an entry is removed and a new one created.
There could be another ESP file system that has the Fedora loader and shim installed. lsblk -fp did show two VFAT file systems if approximately the size a ESP would have.
The efibootmgr also shows the partition UUID, which can be matched with the output of lsblk -o NAME,PARTUUID. The partition UUID is not the same as the file system UUID. The latter is what you find in grub.cfg and /etc/fstab.
Unfortunately this didnât work
There were no errors when I ran the commands (I changed /mnt/sys/firmware/efi/efivars to /mnt/fedora/sys/firmware/efi/efivars in step 9). After reboot, computer still opens windows, still no working fedora entries in the boot menus. I am at a loss to what could be causing this
I am pretty sure that you can have only one EFI System Partition on a single disk. You could have a âLinux extended bootâ partition (XBOOTLDR) but, first, that is not the same as an ESP and, second, I would consider this an advanced configuration, which shouldnât be created automatically without the OP knowing about it and mentioning it.
The specs is not entirely clear on that, and some say that the boot loaders donât need to be installed in an ESP file system, as long as it is installed in a (V)FAT file system and a corresponding boot entry is stored in the UEFI non-volatile memory.
Then you have quite a few different implementations of UEFI and some may tolerate multi ESP partitions on one disk and some may not. Apart from that, Windows as well as Linux systems may get confused with two ESPs and that could be the cause of the problem in the first place.
Only the output of lsblk -o NAME,PARTTYPENAME,PARTUUID from the system with the problem can tell you what you do have or donât have. Also the output from efibootmgr can help with that. Without that, it is anyoneâs guess what is going on.
Also, the contents of both nvme0n1p1 and nvme0n1p4 should be checked.
True, there is no explicit statement that any disk can only contain a single ESP. But since it also does not define behavior for when there are more than one, I would consider having more than one on a disk a really bad ideaâ˘. But yeah, ultimately itâs all just bits and bytes and there is nothing stopping you from adding the ESP GUID to other, random partitions, even to ones that arenât VFAT.
This comes back to the spec not defining behavior for multiple ESPs, which is why none of the mainstream tooling I know would do that for you (things like a Windows installer or any of the Linux distros). Something like parted can probably do it but I doubt this would happen by accident.
After the recovery steps, I expect nvme0n1p1 to contain both shim and GRUB2 binaries in EFI\fedora. But yes, we have not seen exactly which partition the existing âFedoraâ boot entry references. And taking a look at the contents of nvm0n1p4 (and also fstab to see if and how it is used in Fedora) will provide more information.
Thanks, already suggested. OP wasnât able to boot it. Probably due to extra steps to install to USB key. Itâs designed IIRC to be installed on a CD.
I am not sure why there is an Ubuntu entry. At one point I had a dual boot Windows/Ubuntu, but I switched to Fedora. Maybe it wasnât properly deleted
