Are you saying that Fedora and Kali work, just not Windows? Or are you saying that nothing boots?
The the long hex number that efibootmgr shows for each boot entry is the partition UUID. Does a partition with that UUID exist on your system? If so, is it the right partition and does it contain the files at the paths listed in the output of efibootmgr (EFI\fedora\shimx64.efi and EFI\kali\grubx64.efi)?
Are you saying that Fedora and Kali work, just not Windows? Or are you saying that nothing boots?
Does a partition with that UUID exist on your system?
root@localhost-live:/# efibootmgr
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0004,0005,0001
Boot0000* UEFI SanDisk Cruzer Blade 4C532000070422110241 PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/USB(2,0)/USB(0,0)/HD(2,GPT,bd0ce27d-a6e0-4c37-beee-ab4b6f9b6a73,0x440594,0x63cc)/\EFI\Boot\BootX64.efi{auto_created_boot_option}
Boot0001 UEFI HTTPs Boot PciRoot(0x0)/Pci(0x1f,0x6)/MAC(000000000000,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(){auto_created_boot_option}
Boot0004* Fedora HD(1,GPT,75e93101-e060-4b9a-b97c-8564acd10794,0x800,0x32000)/\EFI\fedora\shimx64.efi
Boot0005* kali HD(1,GPT,75e93101-e060-4b9a-b97c-8564acd10794,0x800,0x32000)/\EFI\kali\grubx64.efi
root@localhost-live:/# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0 squashfs 4.0
loop1 ext4 1.0 Anaconda 57b2da08-9667-4695-9f1f-13d099a97592
├─live-rw ext4 1.0 Anaconda 57b2da08-9667-4695-9f1f-13d099a97592
└─live-base ext4 1.0 Anaconda 57b2da08-9667-4695-9f1f-13d099a97592
loop2 DM_snapshot_cow
└─live-rw ext4 1.0 Anaconda 57b2da08-9667-4695-9f1f-13d099a97592
sda iso9660 Joliet Extension Fedora-WS-Live-40-1-14 2024-04-14-23-09-56-00
├─sda1 iso9660 Joliet Extension Fedora-WS-Live-40-1-14 2024-04-14-23-09-56-00
├─sda2 vfat FAT16 ANACONDA 23EA-7494
└─sda3
zram0 [SWAP]
nvme0n1
├─nvme0n1p1 vfat FAT32 BF90-7EFC 174.2M 12% /boot/efi
├─nvme0n1p2
├─nvme0n1p3 ntfs Windows 11 DEE23F4EE23F29E3
├─nvme0n1p4 ntfs 5A94DAB294DA8FBD
├─nvme0n1p5 ext4 1.0 Kali 87e331dc-b6ae-4e0d-baec-2c0ed0266e06
├─nvme0n1p6 swap 1 95d90363-a33a-458f-b9a5-2d0ccaed40e9
├─nvme0n1p7 ext4 1.0 0a7ee8d5-ec9a-4e78-a80a-6f01f4a285d8 353M 57% /boot
└─nvme0n1p8 btrfs fedora c2f7d1b6-8d46-401a-b3ae-1b1c4ec00d8c 833.5G 28% /home
/
root@localhost-live:/# cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Thu Jun 20 17:33:48 2024
#
# 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=c2f7d1b6-8d46-401a-b3ae-1b1c4ec00d8c / btrfs subvol=root,compress=zstd:1 0 0
UUID=0a7ee8d5-ec9a-4e78-a80a-6f01f4a285d8 /boot ext4 defaults 1 2
UUID=BF90-7EFC /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=c2f7d1b6-8d46-401a-b3ae-1b1c4ec00d8c /home btrfs subvol=home,compress=zstd:1 0 0
If so, is it the right partition and does it contain the files at the paths listed in the output of efibootmgr (EFI\fedora\shimx64.efi and EFI\kali\grubx64.efi)?
That is the wrong UUID. The UUIDs listed in /etc/fstab with UUID=… are filesystem UUIDs, not partition UUIDs. (It is possible to use partition UUIDs in /etc/fstab with lines beginning PARTUUID=…, but that is unusual.)
I prefer to use sgdisk for all partition-related tasks. If you don’t have that command on your system, install the gdisk package.
Use sgdisk -i <N> /dev/nvme0n1 where <N> is the partition number you are interest in to get detailed information about a partition. Use sgdisk -p /dev/nvme0n1 to get list of all the partitions.
If your partition UUID does not match, you can use sgdisk to change it. I think something like sgdisk -u 1:75e93101-e060-4b9a-b97c-8564acd10794 /dev/nvme0n1 should work (assuming your EFI system partition is the first partition on your disk; if it isn’t change the first number after -u accordingly).
Edit: The partition UUIDs are labeled “Partition unique GUID:” in the output of sgdisk -i <N> ....
Yea… You’re right with the difference file system UUIDs and and partition UUID.
root@localhost-live:/mnt/boot/efi/EFI/fedora# sgdisk -i 1 /dev/nvme0n1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition)
Partition unique GUID: 44D2EB14-B31A-4A6B-B845-73AD10FF6FBC
First sector: 2048 (at 1024.0 KiB)
Last sector: 411647 (at 201.0 MiB)
Partition size: 409600 sectors (200.0 MiB)
Attribute flags: 8000000000000000
Partition name: 'EFI System Partition'
root@localhost-live:/mnt/boot/efi/EFI/fedora# sgdisk -i 5 /dev/nvme0n1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 1D0E0399-F1BC-40EB-B58F-70DC20DDE3AB
First sector: 586176512 (at 279.5 GiB)
Last sector: 1562738687 (at 745.2 GiB)
Partition size: 976562176 sectors (465.7 GiB)
Attribute flags: 0000000000000000
Partition name: ''
root@localhost-live:/mnt/boot/efi/EFI/fedora# sgdisk -i 7 /dev/nvme0n1
Partition GUID code: BC13C2FF-59E6-4262-A352-B275FD6F7172 (XBOOTLDR partition)
Partition unique GUID: 9F270D7D-D92C-45C8-AFF4-925B9B9A9179
First sector: 1562738688 (at 745.2 GiB)
Last sector: 1564835839 (at 746.2 GiB)
Partition size: 2097152 sectors (1024.0 MiB)
Attribute flags: 0000000000000000
Partition name: ''
root@localhost-live:/mnt/boot/efi/EFI/fedora# sgdisk -i 8 /dev/nvme0n1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 95EF0B20-36D4-4174-B921-CE0A0100C0D2
First sector: 1564835840 (at 746.2 GiB)
Last sector: 3997206527 (at 1.9 TiB)
Partition size: 2432370688 sectors (1.1 TiB)
Attribute flags: 0000000000000000
Partition name: ''
So you’re basically saying I could replace the information in /etc/fstab with the correct Partition unique GUID?
No, that won’t work. What needs to match are the UUIDs in the output of efibootmgr and the “Partition unique GUID” in the output of sgdisk -i 1 /dev/nvme0n1. Right now, those two do not match and that is the problem.
It doesn’t matter which one you change, but the partition UUID is easier to update than the EFI firmware variables, so I would run sgdisk -u 1:75e93101-e060-4b9a-b97c-8564acd10794 /dev/nvme0n1.
Oooooh ok…
Got this:
root@localhost-live:/mnt/boot/efi/EFI/fedora# sgdisk -u 1:75e93101-e060-4b9a-b97c-8564acd10794 /dev/nvme0n1
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
It might boot now; at least the Fedora and Kali entries should work.
Edit: Assuming Fedora Linux boots, a command like the following might work to re-add your MS Windows bootloader to the list of boot options that come up when you press F12 when booting.
sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -l '\\EFI\\Microsoft\\Boot\\bootmgfw.efi' -L "MS Windows"
No joy once more…
No devices to boot.
Tried both Fedora and Kali, returns back to no devices to boot from.
Can you post the output from lsblk -o +partuuid?
liveuser@localhost-live:~$ lsblk -o +partuuid
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS PARTUUID
loop0 7:0 0 2G 1 loop
loop1 7:1 0 8G 1 loop
├─live-rw 253:0 0 8G 0 dm /
└─live-base 253:1 0 8G 1 dm
loop2 7:2 0 32G 0 loop
└─live-rw 253:0 0 8G 0 dm /
sda 8:0 1 3.7G 0 disk
├─sda1 8:1 1 2.1G 0 part /run/initramfs/live bd0ce27d-a6e0-4c37-beed-ab4b6f9b6a73
├─sda2 8:2 1 12.5M 0 part bd0ce27d-a6e0-4c37-beee-ab4b6f9b6a73
└─sda3 8:3 1 300K 0 part bd0ce27d-a6e0-4c37-beef-ab4b6f9b6a73
zram0 252:0 0 8G 0 disk [SWAP]
nvme0n1 259:0 0 1.9T 0 disk
├─nvme0n1p1 259:1 0 200M 0 part 75e93101-e060-4b9a-b97c-8564acd10794
├─nvme0n1p2 259:2 0 16M 0 part d19097fc-96cb-448d-95ae-fcbcd138a5b0
├─nvme0n1p3 259:3 0 279.3G 0 part 0b3c412b-61d3-4159-a8fe-7ab1b552ca82
├─nvme0n1p4 259:4 0 775M 0 part 1d93e76d-602f-4ce5-bb8f-fbe1674aa9f9
├─nvme0n1p5 259:5 0 465.7G 0 part 1d0e0399-f1bc-40eb-b58f-70dc20dde3ab
├─nvme0n1p6 259:6 0 977M 0 part 856c7045-bc0c-480c-8cb4-3cb6066348c9
├─nvme0n1p7 259:7 0 1G 0 part 9f270d7d-d92c-45c8-aff4-925b9b9a9179
└─nvme0n1p8 259:8 0 1.1T 0 part 95ef0b20-36d4-4174-b921-ce0a0100c0d2
And can you mount nvme0n1p1 with something like mount -o ro /dev/nvme0n1p1 /mnt, then post the output from tree /mnt?
Edit: It’s helpful if you put ``` on the lines right before and after the command output so the forum will format it with a fixed-width font.
root@localhost-live:/home/liveuser# tree /mnt
/mnt
└── EFI
├── Dell
│ └── logs
│ ├── diags_current.xml
│ └── diags_previous.xml
└── fedora
└── fw
└── fwupd-f9241bf7-b0a8-4f8b-a224-a7dfbf35cb35.cap
6 directories, 3 files
It looks like you need to restore your backup of your old EFI partition to your new one. The EFI executables are missing.
Edit: Use mount -o remout,rw /mnt to remount that EFI partition in writable mode. I had you mount it readonly initially as a safety precaution, but the partition is already corrupt.
I don’t have the old files any more.
I did a mv from the backups.
It’s gone now. It seems don’t know why…
There was a Boot, Dell, Microsoft, Fedora and Kali folders in the EFI folder.
root@localhost-live:/home/liveuser# mount -o remout,rw /mnt
mount: /mnt: can't find in /etc/fstab.
It should be possible to restore the Fedora boot files with commands along the lines of what Jeff detailed in an earlier post. I think his instructions might have failed because your filesystem UUID has also changed and you probably didn’t update that in /etc/fstab before running mount -a. I’ll ask Jeff to help you from here on out though because it’s been too long since I messed with GRUB. (I switched to using systemd-boot many years ago. 
)
Thanks much for all your help though, really appreciated.
I did everything in the order he told me and posted anywhere I got issues.
Not having the right partition UUID was a significant missing piece. If you retry his instructions now, you might be able to get the Fedora Linux boot files restored.
Ok thanks… I will search around while I wait to hear from Jeff.
Went back and followed the instructions from Jeff and figured how to restore Fedora Linux boot files.
I added this command after mounting.
dnf reinstall grub2-efi grub2-efi-modules shim-\*
Then did grub2-mkconfig -o /boot/grub2/grub.cfg
Now I’m able to boot into Fedora again… All seems well so far.
Will this still be valid to restore windows?
sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -l '\\EFI\\Microsoft\\Boot\\bootmgfw.efi' -L "MS Windows"It would be if you still had that bootmgfw.efi file (and a bunch of others that, unfortunately, MS Windows needs).
The Windows install disk should have a recover boot files option hidden in its menus somewhere. However, I would expect that to erase your Fedora boot files. If you want to try Windows’ boot recovery system, I’d suggest making another backup copy of your ESP first.
Edit: There might be another shortcut of sorts that you can try to boot back into Windows. MS Windows used to install a Partition Boot Record on its system partition. That was for legacy boot support. However, it might still work. To try to “chainload” MS Windows via its legacy PBR, drop to grub’s command line (press c), then enter something like set root=(hd0,3), chainloader +1 and finally, boot. I’m not sure about the (hd0,3). Use commands like ls and ls (hd0,3)/ to preview the contents of the filesystems to be sure that you are pointing the “root” variable at the MS Windows system partition (the one with the “Windows” directory).