Вопрос или проблема
Проблема
У меня установлена Windows 11 (сборка 27754, из канала Canary), которая была установлена вместе с Fedora 41 KDE Spin (обновленной с F40, в которую она была установлена).
Недавно та установка F41 стала не загрузочной (потому что --offline dnf update не применился корректно, что сделало systemd-journald неспособным к вызову вне спасательного ядра).
Чтобы устранить это:
-
Я записал
Fedora-KDE-Live-x86_64-41-1.4.iso(сfedoraproject.org/spins/kde/download) на USB-накопитель SANDISK (предположительно USB2.0), черезFedoraMediaWriter-win64-5.1.3.exe. -
Я заменил ту установку F41 на другую установку Fedora 41 KDE Spin.
Все операции управления дисками в Anaconda были полностью автоматическими. Я просто выбрал накопитель и выбрал “Я хотел бы освободить дополнительное пространство” и выбрал “Удалить все” (разделы) при появлении соответствующего запроса.
Как упоминается в моем отчете, процесс установки F41 KDE Spin (как-то) удалил запись EFI загрузчика Windows из моего UEFI GUI и новой установки GRUB2.
Запрашиваемое решение
Это суть проблемы – я хочу восстановить запись загрузчика моей установки Windows 11. Как минимум, я хочу, чтобы она появилась в UEFI GUI моей материнской платы ASRock X670E Taichi. В идеале, я бы хотел, чтобы она также появилась в новом GRUB2 TUI F41, тоже.
Предполагаемая причина
Я предполагаю, что упомянутая опция в Anaconda (GUI установщика) удаляет загрузочную информацию для всех установленных ОС? Я пришел к такому выводу, потому что, согласно (пока не цитируемым) поискам, общее мнение в сети состоит в том, что загрузочная информация для всех ОС должна находиться только на одном разделе на одном накопителе.
Это означает, что если не выделен отдельный накопитель исключительно для хранения файлов .EFI, все последующие установки ОС (даже на отдельных накопителях) добавят свои файлы .EFI в загрузочный раздел первой установленной ОС.
Если я правильно понял, это означает, что я удалил этот раздел, и не должен был этого делать. Пожалуйста, подтвердите это.
Попытки устранения неисправностей
-
os-proberне обнаруживает загрузчик Windows. -
Я осторожен с тем, чтобы следовать
youtu.be/CZ17JrgFFhw(иyoutu.be/LILSaEGzhOg), потому что они не касаются отсутствующей записи EFI – скорее, дефектной. Это означает, что проверка целостности первого (выполнениеbcdeditв начале процесса восстановления) не работает для меня:Не удалось открыть хранилище конфигурации загрузки.
Система не смогла найти указанный файл. -
Я не верю, что
youtu.be/MIvuDTSGdbgне является случайностью.
Окружение (Накопители)
-
Аппаратное обеспечение
Если это имеет значение, оба накопителя являются SSD, подключенными через NVMe:
Название M.2 Производитель Addlink A95 Да Amazon.co.UKSamsung SSD 980 Pro Да Amazon.co.UKSMART
Все накопители в моей аппаратной конфигурации, включая вышеназванные, имеют идеальные записи SMART, согласно GUI, с которыми я их проверял (например,
partitionmanagerKDE):smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.11.10-300.fc41.x86_64] (локальная сборка) Авторское право (C) 2002-23, Брюс Аллен, Кристиан Франке, www.smartmontools.org === НАЧАЛО РАЗДЕЛА ИНФОРМАЦИИ === Модель: Samsung SSD 980 PRO 250GB Серийный номер: S5GZNF0R106204B Версия прошивки: 2B2QGXA7 Идентификатор поставщика PCI/подсистемы: 0x144d Идентификатор IEEE OUI: 0x002538 Общий объем NVM: 250,059,350,016 [250 ГБ] Неиспользуемый объем NVM: 0 Идентификатор контроллера: 6 Версия NVMe: 1.3 Количество пространств имен: 1 Размер пропускной способности пространства имен 1: 250,059,350,016 [250 ГБ] Использование пространства имен 1: 141,146,243,072 [141 ГБ] Форматированный размер LBA пространства имен 1: 512 IEEE EUI-64 пространства имен 1: 002538 b111b054a0 Локальное время: Вск Дек 1 19:56:30 2024 GMT Обновления прошивки (0x16): 3 слота, сброс не требуется Необязательные команды администратора (0x0017): Безопасная форма Frmw_DL Самотест Необязательные команды NVM (0x0057): Comp Wr_Unc DS_Mngmt Sav/Sel_Feat Timestmp Атрибуты страниц журнала (0x0f): S/H_per_NS Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg Максимальный размер передачи данных: 128 страниц Предупреждение о температуре компоновки: 82 Цельсия Критическая температура компоновки: 85 Цельсия Поддерживаемые состояния питания Состояние Макс Активный Неактивный 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 Поддерживаемые размеры LBA (NSID 0x1) Id Формат Данные Метаданные Относительная производительность 0 + 512 0 0 === НАЧАЛО РАЗДЕЛА ДАННЫХ SMART === Результат теста на общую работоспособность SMART: УСПЕШНО Информация SMART/Здоровье (Журнал NVMe 0x02) Критическое предупреждение: 0x00 Температура: 44 Цельсия Доступный запас: 100% Порог доступного запаса: 10% Использованный процент: 10% Единицы данных, прочитанные: 29,241,658 [14.9 ТБ] Единицы данных, записанные: 85,878,151 [43.9 ТБ] Команды чтения с хоста: 267,134,839 Команды записи с хоста: 1,101,319,506 Время занятости контроллера: 5,926 Циклы питания: 1,304 Часы работы: 1,206 Неправильные выключения: 197 Ошибки целостности медиа и данных: 0 Записи журнала информационных ошибок: 0 Время предупреждения о температуре: 0 Время критической температуры: 0 Датчик температуры 1: 44 Цельсия Датчик температуры 2: 47 Цельсия Информация об ошибках (Журнал NVMe 0x01, 16 из 64 записей) Ошибок не зарегистрировано Журнал самоиспытания не удалось: Неверное поле в команде (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 каталога, 16 файлов -
lsblkCLI#!/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 | 0 -
Графический интерфейс
partitionmanagerKDE
-
CLI
diskpart(иbcdedit) WindowsВ встроенном GUI
cmd.exeинструмента создания образа я могу запуститьdiskpart.exe, который предоставляет следующую информацию:
Я засканирую это, когда смогу, но у меня закончились кредиты ChatGPT.
-
Запись EFI загрузчика содержит очень мало информации, кроме имени: всего лишь GUID раздела (указывает на “Раздел EFI”) и путь к файлу внутри этого раздела. Она может содержать “дополнительные аргументы” для загрузчика, но Windows Boot Manager запускается без них.
Так что если файл все еще присутствует – для Windows это файл \EFI\Microsoft\Boot\bootmgfw.efi – то запись может быть восстановлена с помощью efibootmgr из Linux. (Пути записей загрузки относительны к корню раздела, так что это будет /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi с точки зрения Fedora.)
efibootmgr -c -l '\EFI\foobar' -L "Windows"
Важная часть заключается в том, что вы, вероятно, также удалили самие файлы, которые были на предыдущем разделе EFI. Чтобы восстановить их (и создать новый файл BCD, содержащий актуальную конфигурацию для Windows Boot Manager), вам нужно будет загрузиться с любого DVD или USB-накопителя установки Windows и использовать bcdboot.exe для переустановки загрузчика.
-
открыть Cmd;
-
найти том, который соответствует вашему разделу EFI, и присвоить ему временную букву диска, если у него ее нет (
S:в этом примере); -
найти том, который содержит вашу директорию
\Windows; -
переустановить загрузчик Windows с помощью:
bcdboot C:\Windows /s S: /f UEFI
Это скопирует оригиналы из \Windows\Boot, создаст новую конфигурацию и создаст запись загрузки EFI (по умолчанию давая ей более высокий приоритет, чем записи “Fedora GRUB”).
Обратите внимание, что вы можете иметь отдельный раздел EFI для каждого физического диска – это не ограничено одним на систему. Так что имеет смысл создать отдельный раздел ESP на диске, содержащем Windows, и установить туда Windows Boot Manager.
(В редких случаях можно использовать несколько ESP на одном диске; спецификация UEFI этого не запрещает, поскольку записи загрузки ссылаются на него по GUID, а не только по типу, хотя это не очень полезно.)
Тем временем меню GRUB2 не имеет отношения к меню UEFI – добавление записей в GRUB2 является совершенно отдельной задачей.
Обычно обнаружение Windows – это задача os-prober во время grub-mkconfig. Оно должно делать это автоматически после установки загрузчика с помощью bcdboot.
Ответ или решение
Восстановление загрузчика Windows в UEFI и GRUB2 после установки другой ОС
Введение
Ваша ситуация, в которой установка Fedora 41 привела к удалению загрузчика Windows 11 из меню UEFI и GRUB2, является довольно распространенной проблемой среди пользователей, совмещающих несколько операционных систем. В данном руководстве мы разберем шаги, необходимые для восстановления загрузчика Windows, чтобы он снова появился в UEFI GUI и в GRUB2.
Понимание проблемы
Процесс установки новой ОС может привести к изменению или удалению загрузочной информации предыдущих операционных систем, особенно если не была предусмотрена отдельная EFI-система или если при установке использовались автоматические настройки. Удаление разделов диска, на которых хранятся загрузочные файлы, может повлечь за собой потерю доступа к ним. В вашей ситуации, при установке Fedora, могла произойти такая ситуация.
Первоначальный анализ
Прежде чем двигаться дальше, важно удостовериться, что файлы Windows Boot Manager все еще присутствуют в системе. Это файл bootmgfw.efi, который обычно находится по адресу \EFI\Microsoft\Boot\bootmgfw.efi. Если файл доступен, следует использовать efibootmgr для восстановления соответствующей записи в EFI.
- Убедитесь, что ваша EFI-система ещё функционирует и доступна:
ls /boot/efi/EFI/Microsoft/Boot/Если файл
bootmgfw.efiотсутствует, то необходимо восстановить его с помощью Windows установочного диска.
Шаги для восстановления Windows Boot Manager
-
Загрузите установочный DVD или USB-накопитель Windows:
- Загрузите систему с установочного носителя Windows.
-
Запустите командную строку:
- В меню установки выберите "Восстановление системы", затем откройте "Командную строку".
-
Определите букву диска для EFI-раздела:
- Введите
diskpartдля запуска утилиты разделов диска. - Выполните команду
list vol, чтобы найти букву раздела, содержащего EFI (обычно это 100-500 МБ FAT32 раздел).
- Введите
-
Назначьте временную букву для EFI-раздела (если требуется):
assign letter=S: -
Проверьте наличие окна Windows:
- Вернитесь к командной строке и выполните команду:
dir C:\Windows
- Вернитесь к командной строке и выполните команду:
-
Скопируйте загрузчик Windows:
- Выполните следующую команду для восстановления Boot Manager:
bcdboot C:\Windows /s S: /f UEFI
- Выполните следующую команду для восстановления Boot Manager:
Обновление GRUB2 для обнаружения Windows
После того как Windows Boot Manager был восстановлен, необходимо обновить базу данных GRUB2, чтобы он мог обнаруживать Windows:
-
Перезагрузитесь в Fedora и откройте терминал.
-
Убедитесь, что у вас установлен пакет
os-prober:sudo dnf install os-prober -
Выполните обновление конфигурации GRUB:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Выводы
Следуя приведённым шагам, вы сможете успешно восстановить загрузчик Windows и сделать его доступным как в UEFI GUI, так и в GRUB2. Важно всегда следить за конфигурацией загрузочных разделов при установке новой ОС, чтобы избежать подобных проблем в будущем.
Если вы столкнулись с какими-либо трудностями на любом этапе, не стесняйтесь обратиться к профессиональным IT-специалистам или сообществу пользователей, ориентированному на многосистемные конфигурации.