How to restore a Windows Boot Loader entry (removed by installation of another OS) to my UEFI GUI (and GRUB2)?

Question

Problem

I have an installation of Windows 11 (Build 27754, from the Canary channel) which was installed alongside a Fedora 41 KDE Spin installation (upgraded from F40, which it was installed as).

Recently, that F41 installation became unbootable (because an --offline dnf update did not correctly apply, rendering systemd-journald unable to invoke, outside the rescue kernel).

To remediate this:

1. I wrote Fedora-KDE-Live-x86_64-41-1.4.iso (from fedoraproject.org/spins/kde/download) to a SANDISK USB-A (presumably USB2.0) storage device, via FedoraMediaWriter-win64-5.1.3.exe.

2. I replaced that F41 installation with another Fedora 41 KDE Spin installation.

   All disk management in Anaconda was entirely automatic. I merely selected the storage device and chose "I would like to make additional space available" and chose "Delete all" (partitions) when prompted to do so.

As this report of mine states, the F41 KDE Spin installation process (somehow) removed the Windows Boot Loader EFI entry from both my UEFI GUI and the new GRUB2 installation.

Requested Solution

This is the crux of this issue - I want to recreate my Windows 11 installation's bootloader entry. At the least, I want it to appear inside my ASRock X670E Taichi motherboard's UEFI GUI. Ideally, I want it to also inside my new F41's GRUB2 TUI, too.

Hypothesised Cause

I presume that the latter aforereferenced option in Anaconda (the installer GUI) removes the boot information for all installed OSes? I have concluded this because, from (yet uncited) searches, the consensus online is that boot information for all OSes should solely reside on one partition on one storage device.

This means that unless a separate storage device is designated solely for .EFI-file storage, all subsequent OS installations (even on separate storage devices) shall add their .EFI files to the boot partition of the first OS that was installed.

If my comprehension is correct, then this means that I deleted this partition, and that I should not have. Please confirm this.

Remediation Attempts

1. os-prober does not detect the Windows Boot Loader.

2. I am wary to adhere to youtu.be/CZ17JrgFFhw (and youtu.be/LILSaEGzhOg) because they do not deal with an absent EFI entry - rather, a malformed one. This means that the former's sanity check (running bcdedit at the start of the restoration process) is non-functional for me:

   The boot configuration data store could not be opened.
   The system could not find the file specified.

3. I have 0% confidence that youtu.be/MIvuDTSGdbg isn't a fluke.

Environment (Storage Devices)

1. Hardware

   If of note, both storage devices are SSDs connected via NVMe:

   Name	M.2	Origin
   Addlink A95	True	Amazon.co.UK
   Samsung SSD 980 Pro	True	Amazon.co.UK

   SMART

   All storage devices in my hardware configuration, including the aforementioned, have perfect SMART records, according to the GUIs I have checked them with (KDE's partitionmanager, as an example):

   smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.11.10-300.fc41.x86_64] (local build)
   Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
   === START OF INFORMATION SECTION ===
   Model Number:                       Samsung SSD 980 PRO 250GB
   Serial Number:                      S5GZNF0R106204B
   Firmware Version:                   2B2QGXA7
   PCI Vendor/Subsystem ID:            0x144d
   IEEE OUI Identifier:                0x002538
   Total NVM Capacity:                 250,059,350,016 [250 GB]
   Unallocated NVM Capacity:           0
   Controller ID:                      6
   NVMe Version:                       1.3
   Number of Namespaces:               1
   Namespace 1 Size/Capacity:          250,059,350,016 [250 GB]
   Namespace 1 Utilization:            141,146,243,072 [141 GB]
   Namespace 1 Formatted LBA Size:     512
   Namespace 1 IEEE EUI-64:            002538 b111b054a0
   Local Time is:                      Sun Dec  1 19:56:30 2024 GMT
   Firmware Updates (0x16):            3 Slots, no Reset required
   Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
   Optional NVM Commands (0x0057):     Comp Wr_Unc DS_Mngmt Sav/Sel_Feat Timestmp
   Log Page Attributes (0x0f):         S/H_per_NS Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg
   Maximum Data Transfer Size:         128 Pages
   Warning  Comp. Temp. Threshold:     82 Celsius
   Critical Comp. Temp. Threshold:     85 Celsius
   Supported Power States
   St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
    0 +     8.49W       -        -    0  0  0  0        0       0
    1 +     4.48W       -        -    1  1  1  1        0     200
    2 +     3.18W       -        -    2  2  2  2        0    1000
    3 -   0.0400W       -        -    3  3  3  3     2000    1200
    4 -   0.0050W       -        -    4  4  4  4      500    9500
   Supported LBA Sizes (NSID 0x1)
   Id Fmt  Data  Metadt  Rel_Perf
    0 +     512       0         0
   === START OF SMART DATA SECTION ===
   SMART overall-health self-assessment test result: PASSED
   SMART/Health Information (NVMe Log 0x02)
   Critical Warning:                   0x00
   Temperature:                        44 Celsius
   Available Spare:                    100%
   Available Spare Threshold:          10%
   Percentage Used:                    10%
   Data Units Read:                    29,241,658 [14.9 TB]
   Data Units Written:                 85,878,151 [43.9 TB]
   Host Read Commands:                 267,134,839
   Host Write Commands:                1,101,319,506
   Controller Busy Time:               5,926
   Power Cycles:                       1,304
   Power On Hours:                     1,206
   Unsafe Shutdowns:                   197
   Media and Data Integrity Errors:    0
   Error Information Log Entries:      0
   Warning  Comp. Temperature Time:    0
   Critical Comp. Temperature Time:    0
   Temperature Sensor 1:               44 Celsius
   Temperature Sensor 2:               47 Celsius
   Error Information (NVMe Log 0x01, 16 of 64 entries)
   No Errors Logged
   Read Self-test Log failed: Invalid Field in Command (0x002)
   

   If you do not believe this, please provide me with commands to invoke to verify.

2. Software

   1. tree of /boot/efi/EFI/

      /boot/efi/EFI/
      ├── BOOT
      │   ├── BOOTIA32.EFI
      │   ├── BOOTX64.EFI
      │   ├── fbia32.efi
      │   └── fbx64.efi
      └── fedora
          ├── BOOTIA32.CSV
          ├── BOOTX64.CSV
          ├── gcdia32.efi
          ├── gcdx64.efi
          ├── grub.cfg
          ├── grubia32.efi
          ├── grubx64.efi
          ├── mmia32.efi
          ├── mmx64.efi
          ├── shim.efi
          ├── shimia32.efi
          └── shimx64.efi
      3 directories, 16 files
      

   2. lsblk CLI

      #!/usr/bin/env -S bash
      sudo lsblk -o NAME,KNAME,MAJ:MIN,FSTYPE,MOUNTPOINT,LABEL,UUID,RO,RM,MODEL,SIZE,STATE,OWNER,GROUP,MODE,ALIGNMENT,MIN-IO,OPT-IO,PHY-SEC,LOG-SEC,ROTA,SCHED,RQ-SIZE,TYPE,DISC-ALN,DISC-GRAN,DISC-MAX,DISC-ZERO
      

      I have painstakingly converted the output to a Markdown table:

      NAME        | KNAME     | MAJ:MIN | FSTYPE | MOUNTPOINT | LABEL   | UUID                                 | RO | RM | MODEL                               | SIZE   | STATE   | OWNER | GROUP | MODE       | ALIGNMENT | MIN-IO | OPT-IO | PHY-SEC | LOG-SEC | ROTA  | SCHED | RQ-SIZE | TYPE | DISC-ALN | DISC-GRAN | DISC-MAX | DISC-ZERO
      ------------|-----------|---------|--------|------------|---------|--------------------------------------|----|----|-------------------------------------|--------|---------|-------|-------|------------|-----------|--------|--------|---------|---------|-------|-------|---------|------|----------|-----------|----------|----------
      sda         | sda       |   8:0   |        |            |         |                                      | 0  | 1  | Flash Disk                          |  14.5G | running | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 1     | bfq   |       2 | disk |        0 |      512B |       0B |         0
      └─sda1      | sda1      |   8:1   | vfat   |            | ESD-USB | C4E0-38AE                            | 0  | 1  |                                     |  14.5G |         | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 1     | bfq   |       2 | part |        0 |      512B |       0B |         0
      sdb         | sdb       |   8:16  |        |            |         |                                      | 0  | 1  | MassStorageClass                    |     0B | running | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | bfq   |       2 | disk |        0 |      512B |       0B |         0
      sdc         | sdc       |   8:32  |        |            |         |                                      | 0  | 1  | MassStorageClass                    |     0B | running | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | bfq   |       2 | disk |        0 |      512B |       0B |         0
      zram0       | zram0     | 252:0   |        | [SWAP]     |         |                                      | 0  | 0  |                                     |     8G |         | root  | disk  | brw-rw---- |         0 | 4096   | 4096   | 4096    | 4096    | 0     |       |         | disk |        0 |        4K |       2T |         0
      nvme0n1     | nvme0n1   | 259:0   |        |            |         |                                      | 0  | 0  | addlink M.2 PCIE G4x4 NVMe          |   1.8T | live    | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | disk |        0 |      512B |       2T |         0
      ├─nvme0n1p1 | nvme0n1p1 | 259:2   | vfat   | /boot/efi  |         | 8C16-B16E                            | 0  | 0  |                                     |   600M |         | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | part |        0 |      512B |       2T |         0
      ├─nvme0n1p2 | nvme0n1p2 | 259:3   | ext4   | /boot      |         | 84cfd3a5-f2a3-4a30-80e9-75885f086a17 | 0  | 0  |                                     |     1G |         | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | part |        0 |      512B |       2T |         0
      └─nvme0n1p3 | nvme0n1p3 | 259:4   | btrfs  | /home      | fedora  | e8f3f913-c9b3-4d02-9343-0b91e71950e0 | 0  | 0  |                                     |   1.8T |         | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | part |        0 |      512B |       2T |         0
      nvme1n1     | nvme1n1   | 259:1   |        |            |         |                                      | 0  | 0  | addlink M.2 PCIE G4x4 NVMe          |   1.8T | live    | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | disk |        0 |      512B |       2T |         0
      └─nvme1n1p1 | nvme1n1p1 | 259:5   | btrfs  |            | s11vzd  | a8dc8530-f314-407a-896c-861783f62ecf | 0  | 0  |                                     |   1.8T |         | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | part |        0 |      512B |       2T |         0
      nvme3n1     | nvme3n1   | 259:6   |        |            |         |                                      | 0  | 0  | SK hynix PC401 HFS256GD9TNG-62A0A   | 238.5G | live    | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |     511 | disk |        0 |      512B |       2T |         0
      nvme2n1     | nvme2n1   | 259:7   |        |            |         |                                      | 0  | 0  | Samsung SSD 980 PRO 250GB           | 232.9G | live    | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | disk |        0 |      512B |       2T |         0
      ├─nvme2n1p1 | nvme2n1p1 | 259:8   | btrfs  |            | s2ve9g  | 17c0335b-73c9-45b1-aabe-f62a6e633d98 | 0  | 0  |                                     |    16M |         | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | part |        0 |      512B |       2T |         0
      ├─nvme2n1p2 | nvme2n1p2 | 259:9   | ntfs   |            |         | 182A50072A4FE07C                     | 0  | 0  |                                     | 232.1G |         | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | part |        0 |      512B |       2T |         0
      └─nvme2n1p3 | nvme2n1p3 | 259:10  | ntfs   |            |         | E8DA341BDA33E50A                     | 0  | 0  |                                     |   830M |         | root  | disk  | brw-rw---- |         0 |  512   |    0   |  512    |  512    | 0     | none  |    1023 | part |        0 |      512B |       2T |         0
      

   3. KDE's partitionmanager GUI

      

      

      

      

      

      

   4. Windows's diskpart (and bcdedit) CLIs

      Inside the Media Creation Tool's embedded cmd.exe GUI, I can run diskpart.exe, which provides the undermentioned information:

      

      

      I'll OCR this when I can, but I've used all my ChatGPT credits.

Answer 1

The EFI boot entry itself contains very little information besides the name: just a partition GUID (pointing to the "EFI System Partition") and a file path within that partition. It can contain "extra arguments" for the loader, but the Windows Boot Manager starts fine without them.

So if the file is still present – for Windows it's the \EFI\Microsoft\Boot\bootmgfw.efi file – then the entry can be re-added using efibootmgr from Linux. (Boot entry paths are relative to the root of the partition, so this would be /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi from the Fedora perspective.)

efibootmgr -c -l '\EFI\foobar' -L "Windows"

The important part is that you likely have also deleted the actual files that were in the previous EFI System Partition. To restore them (and to build a new BCD file that contained the actual configuration for Windows Boot Manager), you'll need to boot into any Windows installation DVD or USB stick and use bcdboot.exe to reinstall the boot manager.

1. open Cmd;

2. find the volume that corresponds to your EFI System Partition, and assign it a temporary drive letter if it doesn't have one (S: in this example);

3. find the volume that contains your \Windows directory;

4. reinstall the Windows Boot Manager using:

   bcdboot C:\Windows /s S: /f UEFI
   

This will copy originals from \Windows\Boot, build a new configuration, and create the EFI boot entry (by default giving it higher priority than the "Fedora GRUB" entry).

Note that you can have a separate EFI System Partition for each physical drive – it is not limited to one per system. So it might make sense to create a separate ESP on the disk containing Windows and install the Windows Boot Manager into that instead.

(In rare cases even multiple ESPs per drive can be used; the UEFI specification doesn't outright forbid that, since boot entries reference it by GUID and not merely by type, although it's not very useful.)

---

Meanwhile, the GRUB2 menu has no relationship with the UEFI menu – adding entries to GRUB2 is a completely separate issue.

Usually, detecting Windows is the job of os-prober during grub-mkconfig. It should do this automatically after the boot manager is installed via bcdboot.

Answer 2

Solely one of my drives appeared to have a Windows installation when I performed (the pseudocode) sel disk $number && list part, so I didn't need to differentiate Windows installations. However, diskpart wasn't displaying the hidden flag that most tutorials appear to rely upon.

Despite this, I estimated that detail part (or detail vol) would, so when I had ascertained which disk my Windows installation was on (in my case, disk 3), I performed:

1. sel disk 3
2. list part

In each partition, I then performed detail part. Lo and behold, my estimation was correct, for a subsequent list vol included the flags.

This was useful, because although I had previously been searching for a FAT32 partition (or volume) the hidden flag was solely applied to Fedora's FAT32 volume. For Windows, the hidden volume was NTFS.

Consequently, I assigned a letter with:

1. sel vol 2
2. assign letter="S"

Then, invoking the command provided by the previous answer — bcdboot C:\Windows /s S: /f UEFI — worked:

Boot files successfully created.

A mere reboot was enough for Windows Boot Manager to appear within my motherboard firmware's GUI.

---

superuser.com/revisions/1507645/3 is probably the most comprehensive source of information pertaining to this. However, most of its steps are inapplicable except for the most damaged installations.