Oh, where to start…
Context: Dual booting Windows and Fedora on the same drive.
So the UEFI update (3.03) came up in Fedora updates, but it complained the /boot/efi partition was too small. OK, I’ll just resize it. Finally did that in Windows via MiniTool, but it apparently changed the UUID of the partition because after restart, neither OS would boot. If I booted Windows, I got two lines of errors that seemed like it couldn’t find bootmgwf.efi, and if I booted Fedora it would just get stuck in emergency mode and wouldn’t quite tell me why. I finally figured out that Fedora wasn’t mounting /boot/efi so I mounted it manually, booted the OS, realized the problem was that the boot partition UUID had changed, so I updated /etc/fstab. Great, Fedora works again, but Windows still won’t boot presumably because it too is looking for the wrong UUID to find the boot directory.
What’s the equivalent way to update the UUID of the boot volume for Windows? Do I have to create recovery media and run some silly command like fix bcd or whatever? Can I find and fix it from Fedora? Is it something in grub that has to change? I grepped the whole /boot/efi directory for the old UUID and didn’t find anything, so I’m a little worried it won’t be as straightforward as it was in Fedora.
Edit: I maybe see a clue in grub2-efi.cfg:
menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-4069->
savedefault
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root 4069-70C9
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
4069-70C9 is the old UUID, but it doesn’t update when I do grub2-mkconfig. Hmmm…
You’ll need to get some Windows boot media (an installer will do! Just press Shift+F10 to get to a shell), and run…
mountvol S: /S
bcdboot C:\Windows /f UEFI /s S:
1 Like
Thanks for the quick reply! Didn’t quite work though. No errors, but no change.
Interestingly, if I go to the firmware boot manager and select Windows, it boots fine. So maybe it’s just a grub problem?
Oddly, when I run grub2-mkconfig, I get output like this:
### BEGIN /etc/grub.d/30_os-prober ###
Found Windows Boot Manager on /dev/nvme1n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
menuentry 'Windows Boot Manager (on /dev/nvme1n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-210D-1AD0' {
savedefault
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root 210D-1AD0
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
which has the right UUID, 210D-1AD0. But then when I look at /etc/grub2-efi.cfg, I still see the same old UUID of 4069-70C9. It’s like it’s not updating it at all. I wonder if this is related to my difficulties changing the font size in grub? I’ve done all the normal things of editing /etc/default/grub but none of the changes ever seem to have any effect. Could this be the same? Or am I just looking at the wrong thing (grub2-efi.cfg) to see changes?
Oh, absolutely! Sorry, I missed that GRUB was involved.
GRUB’s config file contains hardcoded references to partitions. It can be made to “search” rather than take hardcoded paths, but that’s up to the config writer. The overcomplicated config system is one of the things that makes it unsuitable as a safe, modern bootloader.
Your distribution probably has a tool to regenerate the config completely. You can validate it to make sure the ESP filesystem ID matches the one you see by running blkid
EDIT: Oh interesting. It’s weird that it’s not overwriting your existing grub config when you run grub2-mkconfig
…
As a test, you could copy the newly generated file over the one in your ESP! That may solve all your issues. The docs suggest it should do this for you though.
EDIT 2: Ah, there’s the catch. It doesn’t do it for you:
~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg # or wherever it lives
(from the end of the “Changing the Default Boot Entry” section of Chapter 26. Working with GRUB 2 Red Hat Enterprise Linux 7 | Red Hat Customer Portal)
2 Likes
Wow, all this time I was running grub2-mkconfig without -o /boot/grub2/grub.cfg! So it was just building the configuration and dumping it…I wonder where…
Both OS’s boot fine now. Thanks! Well, sorta. Now Fedora boots funny with a grey screen and 3 dots for a few seconds, then a delay before it takes any keyboard input on the login screen. Started after running those Windows commands in my actual Windows installation, not the recovery USB. I also don’t see the firmware update available in Fedora anymore despite it very much being on 3.02. Oh well, problems for later!
Edit: The firmware update must have been waiting for me to plug in and charge a bit, but once it showed back up and went through, it cleared up the weird Fedora boot. Everything back to normal, and I even learned a thing or two about my EFI partition. What a day!
3 Likes