[Windows 8 Activator Loader V3.1 Download
Tilo Chopin
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.
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.
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.
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.
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.
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.
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
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.
I installed a second SATA drive (a 3TB Seagate) and booted up the factory installed OS on the first SATA drive. The operating system has no problem seeing the drive, so I installed a second OS into a 700GB partition on the second SATA drive. However, when I booted the system to finish the OS installation, the BIOS couldn't see the second SATA drive. Booting into the OS on the first SATA drive, no problems, the OS can see the second SATA drive. So, the problem occurs at boot time. The BIOS won't see the second SATA drive.
However, if I interrupt the BIOS at boot, and go in to run a diagnostic (and I cancel that and not run the diagnostic), all of a sudden, the BIOS can see the 2nd SATA drive and I can boot off it. Interrupting the normal BIOS boot and entering the BIOS setup, and then canceling out, will 100% of the time cause the BIOS to see the second SATA drive. If I don't do this, the BIOS doesn't see the other SATA drive 100% of the time. This is a real annoyance.
I do not think it has anything to do with the "Windows Boot Loader (Winload.exe or Winload.efi)". However, I did try it out and running a "bcdedit /set GUID path \windows\system32\winload.exe" produced a non-booting OS (even if I attempted to use my current workaround by interrupting the BIOS at boot).
Here is the current behavior I am seeing when I hit ESC to enter the BIOS setup (you have a window of less than 2 seconds to hit this key before the WIndows Boot Loader menu comes up). The following are the paths to settings in the BIOS menu, followed by the settings I am seeing:
Settings a POST delay (from the default of nearly no delay to 5 seconds) fixes the problem. In fact, if I wait 3 - 4 seconds into the delay, and then hit the ESC key to enter the BIOS setup, everywhere I was seeing "Shows only SATA0" above before, is now showing both SATA0 and SATA1. Everything is looking and working as I would expect it to. Problem solved.
Seagate does have downloads that provide workarounds to the BIOS and operating system issue you are facing. It would have been helpful if you had let me know which OS was installed on the 700 GB partition.
This does not appear to be a Seagate or large disk issue. This appears to be a BIOS issue. If I interrupt the BIOS and enter setup, and then exit without saving, I can select any one of the four volumes I created on the 2nd SATA drive and boot successfully. Sometimes this sticks and I can reboot and make the same volume selection and it works for a 2nd or sometimes a 3rd boot, but then appears broken again. There is no issue with booting either of the two OSes on the 1st SATA drive (Windows 7 64-bit Home Premium Edition or Windows Server 2012 R2 with Hyper-V role installed). I have included some additional disk information below (and please note that all volumes are 'Basic GPT').
The boot loader path might be incorrect. I would try winload.exe and not winload.efi. This is how my boot loader path appears on the 2nd HD that I have four bootable OSs installed. I have yet to see anyone post getting Windows 7 to boot in UEFI mode. R2 is a different animal. I formatted my 2nd HD MBR (2GB) which is a bit different then formatting GPT. It's something to consider but if you do then you will not have the entire HD space to work with but that really shouldn't be a problem.
795a8134c1