问题
我安装了 Windows 11（Build 27754，来自 Canary 频道），它是与 Fedora 41 KDE Spin 安装（从 F40 升级而来，当时安装为 F40）一起安装的。
最近， F41安装变得无法启动（因为--offline dnf update未正确应用，导致systemd-journald无法在救援内核之外调用）。
要解决此问题：
我通过
Fedora-KDE-Live-x86_64-41-1.4.iso将数据（从fedoraproject.org/spins/kde/download）写入 SANDISK USB-A（大概是 USB2.0）存储设备。FedoraMediaWriter-win64-5.1.3.exe我用另一个 Fedora 41 KDE Spin 安装替换了那个 F41 安装。
Anaconda 中的所有磁盘管理都是完全自动化的。我只需选择存储设备并选择“我想提供更多可用空间”，然后在提示时选择“删除所有”（分区）。
正如我的报告所述，F41 KDE Spin 安装过程（不知何故）从我的 UEFI GUI 和新的 GRUB2 安装中删除了 Windows Boot Loader EFI 条目。
请求的解决方案
这是问题的关键——我想重新创建我的 Windows 11 安装的引导加载程序条目。至少，我希望它出现在我的ASRock X670E Taichi主板的 UEFI GUI 中。理想情况下，我也希望它出现在我的新 F41 的 GRUB2 TUI 中。
推测原因
我推测 Anaconda（安装程序 GUI）中上述选项会删除所有已安装操作系统的启动信息？我得出这个结论是因为，从（尚未引用的）搜索来看，网上的共识是所有操作系统的启动信息应该只驻留在一个存储设备的一个分区上。
这意味着，除非指定单独的存储设备专门用于.EFI文件存储，否则所有后续操作系统的安装（即使在单独的存储设备上）都应将其.EFI文件添加到已安装的第一个操作系统的启动分区中。
如果我的理解正确，那么这意味着我删除了这个分区，而我不应该这样做。请确认这一点。
补救措施
os-prober未检测到 Windows 启动加载程序。我谨慎地遵守
youtu.be/CZ17JrgFFhw（和youtu.be/LILSaEGzhOg），因为它们不处理缺失的 EFI 条目，而是处理格式错误的条目。这意味着前者的健全性检查（bcdedit在恢复过程开始时运行）对我来说不起作用：无法打开启动配置数据存储。
系统找不到指定的文件。我百分之零的信心这
youtu.be/MIvuDTSGdbg不是侥幸。
环境（存储设备）
硬件
值得注意的是，两个存储设备都是通过 NVMe 连接的 SSD：
姓名 M.2 起源 艾迪林 A95 真的 Amazon.co.UK三星 SSD 980 Pro 真的 Amazon.co.UK聪明的
根据我用来检查的 GUI（
partitionmanager以 KDE 为例），我的硬件配置中的所有存储设备（包括前面提到的设备）都具有完美的 SMART 记录：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)不相信的话，请提供命令给我来调用验证。
软件
tree的/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 fileslsblk命令行界面#!/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我费尽心思将输出转换为 Markdown 表：
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 | 0KDE 的
partitionmanagerGUI
Windows 的
diskpart（和bcdedit）CLI在媒体创建工具的嵌入式
cmd.exeGUI 中，我可以运行diskpart.exe，它提供下面提到的信息：
当我可以时我会对其进行 OCR，但我已经用完了所有的 ChatGPT 积分。
EFI 启动项本身除了名称之外包含很少的信息：只有一个分区 GUID（指向“EFI 系统分区”）和该分区内的文件路径。它可以包含加载程序的“额外参数”，但 Windows 启动管理器在没有这些参数的情况下也可以正常启动。
因此，如果文件仍然存在（对于 Windows 来说，就是文件
\EFI\Microsoft\Boot\bootmgfw.efi），则可以使用 Linux 重新添加条目efibootmgr。（启动条目路径相对于分区的根目录，因此这是/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi从 Fedora 的角度来看的。）重要的是，您可能还删除了以前的 EFI 系统分区中的实际文件
BCD。要恢复它们（并构建包含 Windows 启动管理器实际配置的新文件），您需要启动任何 Windows 安装 DVD 或 USB 棒，然后使用它bcdboot.exe重新安装启动管理器。打开 Cmd；
找到与您的 EFI 系统分区相对应的卷，如果它没有，则为其分配一个临时驱动器号（
S:在此示例中）；找到包含您的目录的卷
\Windows；使用以下方法重新安装 Windows 启动管理器：
这将从 \Windows\Boot 复制原件，构建新的配置，并创建 EFI 启动项（默认情况下，其优先级高于“Fedora GRUB”项）。
请注意，您可以为每个物理驱动器设置单独的 EFI 系统分区 - 不限于每个系统一个。因此，在包含 Windows 的磁盘上创建单独的 ESP 并将 Windows 启动管理器安装到其中可能是有意义的。
（在极少数情况下，每个驱动器甚至可以使用多个 ESP；UEFI 规范并不完全禁止这样做，因为启动条目通过 GUID 而不是仅仅通过类型来引用它，尽管它不是很有用。）
同时，GRUB2 菜单与 UEFI 菜单没有关系——向 GRUB2 添加条目是一个完全独立的问题。
通常，在 grub-mkconfig 期间检测 Windows 是 os-prober 的工作。它应该在通过 安装引导管理器后自动执行此操作
bcdboot。当我执行（伪代码）时，我的驱动器中只有一个似乎安装了 Windows
sel disk $number && list part，因此我不需要区分 Windows 安装。但是，diskpart它并没有显示hidden大多数教程似乎依赖的标志。尽管如此，我估计
detail part（或detail vol）会，所以当我确定我的 Windows 安装在哪个磁盘上（在我的情况下是磁盘 3）时，我执行了：sel disk 3list part在每个分区中，我执行了
detail part。瞧，我的估计是正确的，因为后续操作list vol包含了标志。这很有用，因为尽管我之前一直在搜索 FAT32 分区（或卷），但该
hidden标志仅适用于Fedora的 FAT32 卷。对于 Windows，该hidden卷是 NTFS。因此，我指定了一封信给：
sel vol 2assign letter="S"然后，调用上一个答案提供的命令——
bcdboot C:\Windows /s S: /f UEFI有效：只需重新启动即可使 Windows 启动管理器出现在我的主板固件的 GUI 中。