I faced, as many users in the world, the corruption of the dual boot Linux-Windows 11 after Microsoft launched update 23H2.
I was able lo boot Fedora Linux from a live USB in a limited way but want to regain full command on my system.
Is there already a solution to this issue?
Can you verify that your EFI system partition still contains a folder EFI/fedora ?
If so, you should be able to re-register Fedora’s GRUB in the UEFI NVRAM with a command like:
efibootmgr --create --disk /dev/sda --part 1 --label Fedora --loader \\EFI\\Fedora\\shim.efi
(That assumes your EFI system partition is at /dev/sda1. Change the --disk and --part options appropriately if not.)
You likely have the same problem as the poster of this thread: Unable to boot fedora 41 after installing windows 10 to different hard drive - #16 by pg-tips
Hi, @pg-tips .
Thank you very much for your reply.
Well, seems to be there is no /EFI or /boot/efi folder.
I setup my system the follwing way.
A 500 GB NvME disk for both Windows and Linux system and program files.
Each operating system has its own partition.
Besides, a 1 TB SSD for data. Also two partitions for each Windows and Linux.
Here are two screenshots showing the Linux main folder and the boot folder.
Didn’t find any efi folder.
It’s possible to have a Fedora install without an EFI system partition (by using MBR instead). However if Windows 11 is installed, there should be an EFI system partition somewhere. It probably just isn’t shown in the file manager GUI (I know mine isn’t shown in Dolphin).
In your installed Fedora it would be mounted as /boot/efi, but when running from a live USB it likely isn’t auto-mounted.
From a terminal can you run lsblk -f ? Hopefully that’s going to show us a small (100 - 1000 MB) FAT32 partition, which we can then mount and look at the contents of.
Hi again, @pg-tips .
I finally found my GParte Live USB stick.
The system carries a 500 GB NvMe drive for both Windows and Fedora operating systems system files and an SSD drive for also both Windows and Fedora data files.
Here are the results
As can be seen, there are two partitions affected one at each drive.
OK, so it looks like /dev/nvme0n1p1 is your EFI system partition.
Can you mount that partition, and check that it still has a directory EFI/Fedora containing the shim.efi file (among other .efi files)?
If so, then the Fedora bootloader should still be present, and it can be re-registered in the NVRAM of the UEFI using:
efibootmgr --create --disk /dev/nvme0n1 --part 1 --label Fedora --loader \\EFI\\Fedora\\shim.efi
Then on reboot, your Fedora install should be available as a boot option.
For now, don’t worry about the warnings on that “Microsoft Reserved Partition”. That shouldn’t cause any issues in Linux and it most likely doesn’t cause any in Windows either - it’s a legacy thing that doesn’t seem to be necessary for Windows 11.
This article may help provide a fix for the situation you’re finding yourself in.
Good luck!
You can’t imagine what a burden this has been, @jrredho .
As I declare myself as not the highest knowledged Linux user, I turned to find out how to mount that efi or boot/efi partition.
See, @pg-tips , I’m currently booting from Live Fedora USB.
Here I found these instructions to go against this problem:
A Windows 11 23H2 update can sometimes disrupt dual-boot setups by overwriting the Linux bootloader. Here’s how to fix it:
1. Identify the Problem:
** You can no longer boot into your Linux operating system after the Windows update.*
** The Windows bootloader might have overwritten the Linux bootloader, leaving only Windows options in the boot menu.*
2. Fix the Bootloader:
** Boot from a Linux Live USB:*
Use a bootable USB drive with a live Linux environment (e.g., Fedora, Ubuntu).
** Identify the Linux Partition:*
Use tools like lsblk or fdisk to identify the partition where your Linux OS is installed.
** Mount the Linux Partition:*
Mount the identified partition to a mount point, for example, /mnt/linux.
** Chroot into the Linux System:*
Use sudo chroot /mnt/linux to enter the Linux environment from the live USB.
** Reinstall GRUB:*
Run sudo grub-install /dev/sdX (replace /dev/sdX with the correct device name) and sudo update-grub to reinstall the GRUB bootloader.
** Mount EFI Partition (if applicable):*
If you have an EFI partition, mount it using sudo mount /dev/sdX1 /boot/efi and then reinstall GRUB using the appropriate command for your system (e.g., sudo grub-install /dev/sdX1).
** Reboot:*
After these steps, reboot your system, and you should see the GRUB boot menu with your Linux OS options.
3. Alternative Methods (if applicable):
** Boot Repair (Fedora):*
If you’re using Fedora, you can try the “Boot Repair” tool, which can automatically detect and fix boot issues.
** Boot Menu (UEFI):*
In some cases, Windows might have changed the boot order in the UEFI settings. You can access the UEFI settings (usually by pressing F2, F12, or Delete during boot) and change the boot order to prioritize your Linux bootloader.
Important Notes:
** Backups:*
Back up your data before making significant changes to the bootloader, as errors can lead to data loss.
** Secure Boot:*
If you have Secure Boot enabled, you might need to disable it temporarily to install or repair the bootloader.
** Windows Update History:*
If you believe a specific Windows update is causing the issue, you can try uninstalling it from Windows Update history.
** Separate Drives:*
Consider installing Windows and Linux on separate hard drives or SSDs to prevent Windows updates from overwriting the Linux bootloader.
Any comment on these steps before I attempt to apply this suggestion?
There can be more causes for this issue.
The UEFI boot order has changed. This may be necessary for WIndows to be able to do unattended reboot during upgrades. To fix, boot the Fedora entry from the UEFI menu, and fix the boot order using the UEFI setup or efibootmgr.
The Windows upgrade has installed a .sbat entry in the UEFI memory. To check if this is the case, try to boot with secure boot disabled. To fix run mokutil --set-sbat-policy delete and then reboot still with secure boot off.
The grub entries are really removed from the ESP. To fix, reinstall the grub packages.
Without proper diagnosis you can’t do a proper fix.
