I have been working with a user here who had a functional fedora install, then did an install (or reinstall) of windows 11. His ending situation was that the efi partition was recreated by windows and all fedora config of grub within the ESP was wiped out.
Working with the user I have been able to do a full recovery (almost). We have been able to use the live usb and do a full install of grub to restore the /boot/efi/EFI/fedora directory and files as well as recreating a new /boot/grub2/grub.cfg file. All his files in /, /home, and /boot were unaffected.
The remaining issue is that the bios is unable to see fedora grub and boot it. The bios boot menu currently shows only the windows boot loader on his drive.
I have never had to make a boot loader functional from scratch previously, so would appreciate any assistance in the steps involved to make the link between grub being installed and the boot loader being accessible from bios to boot grub.
I know the final steps of an installation configure and activate the grub boot loader, but I am unaware of the exact steps and commands involved.
Doing further research I wonder. Would the grub-install command be the one needed? Possibly grub-install --target=x86_64-efi --efi-directory=/boot/efi /dev/nvme0n1 when the system is fully mounted and active in a chroot environment? His system is installed on nvme0n1 with the ESP on /dev/nvme0n1p1.
That may be correct for Ubunto, but not for Fedora. On Fedora grub2-install checks if you are on a UEFI system and refuses to do anything. On older Fedora it would break the ability to boot in secure mode.
That is efibootmgr with the --create or ‘-c’ option. Its user experience is very poor but it does work. On MS-windows it is called bcd–somthing, and perhaps the UEFI configuration can also do it.
Then there is a fall-back magic feature. If the boot menu is empty, the system can boot from \EFI\BOOT\BOOTX64.EFI which is a copy of shimx64.efi. Then the file EFI/fedora/BOOTX64.CSV is read and the contents of this file is used to create the proper boot entry. Pure magic. On my system, this works only if I remove all boot entries. On some other systems you may be able to select the hard disk as boot device.
I find it better just to disconnect the drive Linux is on and reboot install windows on the drive you want. connect the drive and reboot. Press whatever key your computer uses to access the boot menu and select which OS you want. If you are sharing files of some sort save to a common drive that both OS can access…NO problems and there you go…
Oh and by the by go into cmos and set boot order to drive you want as default.
That works fine with multiple drives and installing discretely on separate drives. The original thread however is about a dual boot system on which both OSes were already installed and functional using a single efi partition.
Then a windows install/reinstall wiped out the ESP partition so it was necessary to reinstall grub and enable the system to access grub for booting. Of course that also meant /etc/fstab had to be altered for the new /boot/efi partition and other changes.
Did windows change the efi UUID?, if so /etc/fstab will need updating.
Check they match
sudo blkid |grep EFI
/dev/nvme0n1p1: SEC_TYPE="msdos" UUID="2B94-16CF" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="3706357a-ad7e-4e93-81aa-276991f966b8"
# Created by anaconda on Sat Sep 18 13:37:23 2021
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
UUID=8d497433-c3a5-4beb-a76b-34a443e324a4 / ext4 defaults 1 1
UUID=6b3197d9-7240-41c9-acc1-a9cade4401b5 /boot ext4 defaults 1 2
UUID=2B94-16CF /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=29fbcff6-b921-459c-bb7f-1c3000b0f2d9 none swap defaults 0 0
That would be particularly bad since this is dual boot with a shared ESP partition and windows boots properly.
If you read through the other thread where I have been working with the other user you would see that windows did completely wipe out the efi partition and recreated it with a new UUID.
The fedora portion of that has been restored, with advice from here uefi is now able to see and start grub, but it seems the issue now may be something to do with LVM not properly activating the VG so the root file system cannot be mounted. Fedora goes to emergency mode. Still working that out at present.
AFAICT windows is in the default position, and boots normally. The issue now is some lingering tweaks to finish the fedora recovery.
Just a quick recap of the total steps involved in recovery on the other users system. (mostly done within a chroot environment)
The windows install changed the UUID for the ESP so /etc/fstab needed to be updated with the new UUID to mount /boot/efi
Verify that the /boot/efi/EFI/fedora directory had been removed by windows.
reinstall grub2* and shim* (to rebuild the /boot/efi/EFI/fedora directory)
run efibootmgr -c to tell the UEFI bios that grub was installed and available for booting
The users system was using LVM and the original VG was not accessible for activation. The user renamed the VG which made it accessible but also necessitated an update to the kernel command line in /etc/default/grub to update the new VG name. The new VG name also necessitated further editing of /etc/fstab.
After updating grub.cfg with grub2-mkconfig -o /boot/grub2/grub.cfg and verifying that all the boot loader entries in /boot/loader/entries were properly updated with the new LVM data the user rebooted and the recovery from the windows install was complete.
Hope this helps someone else if they have the misfortune of installing windows after linux is already installed.
That is an awesome troubleshooting guide there. Congratulations for solving it, and resolving the UUID problem.
For users looking for a first time dual boot, or planning a fresh install…
My experience has taught me to isolate windows on a physically separate drive if possible. I rely on GRUB as the main bootloader. It lives on the sda drive with fedora. When I am doing a major upgrade to Windows I remove the Linux drive so it is impossible for a Windows update or install to change it in any way. The normal updates have caused no problems since configuring this way.
It’s extreme, but effective.
I never like windows taking control of my computer so I would install both with Linux first unplug that drive and hook up a second drive then install windows as though it is alone. Then I would hook up booth and when I boot press the drive selector and boot the one I want. As far as data Linux can read the work files in windows directory and save to them if needed. In this way if I want windows games I can boot to windows and play the games. The Linux versions of the games are either limited or suck…so I play them in windows. We are talkin’ major 3d games…
To expand on my previous comment, there are 3 issues that are critical for me when running any machine, especially when I have linux and windows parritions.
1 - being able to reliably boot external media
2 - being able to reliably choose which installed partition to boot
3 - having a backup strategy that can successfully recover from a crash
1 - most BIOS take care of this but not reliably. rEFId usually works when the BIOS won’t
2 - rEFInd takes care of this.
3 - The most reliable whole machine backup that I have found is Macrium Reflect. It does require a windows systrm to create the rescue media but this is no problem in a dual boot scenario. The rescue media will both backup and restore. It is invaluable for recovering from windows BSOD’s that are rare but catastrophic without a good tool. I run timeshift as well. Clonezilla and Rescuezilla are not reliable because partclone odten chokes on the windows partition (thinks it not shutdown, wants fsck, ext)
rEFInd is pure uefi code (unlike grub) and auto-detects bootable partitions on most all connected devices (unlike some BIOS) .
I don’t know if this is the same problem but just in case: I had a similar problem several times with an old Sony Vaio laptop after applying some heavy Windows 10 updates. It was just updates, not a Windows install or reinstall. I also had the same problem with a new Lenovo Legion also with Windows 10.
In both cases I managed to recover the Grub loader from Windows without needing to reinstall Grub or booting from an USB. I used the bcdedit Windows command executed in a Windows DOS box with administrator privilege.
The first thing to do is to list the items in the EFI partition with the following command:
bcdedit /enum all /v
If one of the listed entries is similar to the next one then the Grub2 entry is still in the EFI partition and it is possible to reactivate it: