проблемы с uefibootmgr

Вопрос или проблема

Я сделал что-то неправильно с efibootmgr на своем компьютере.

Система больше не загружается. И в BIOS/UEFI я не вижу никаких NVMe дисков для загрузки.

В системе есть два NVMe диска

nvme0n1 : skhynx 256gb и nvme1n1 : wd 1tb

nvme0n1 был последним, с которого я мог до недавнего времени запускать свою систему Linux.

Grub каждый раз говорит мне что-то о “загрузке в слепом режиме” или что-то в этом роде, но система загружалась до того, как я сделал что-то неправильно.

Я попытался добавить nvme1n1 с помощью efibootmgr для загрузки.

Теперь в BIOS/UEFI нет ни одного диска для загрузки.

Я теперь загрузил систему с USB-ключа Kubuntu и затем подключился по SSH с другого компьютера к системе.

gdisk -l /dev/nvme0n1 | grep -A4 '^Partition table scan:'
Сканирование таблицы разделов:
  MBR: защитный
  BSD: отсутствует
  APM: отсутствует
  GPT: присутствует

gdisk -l /dev/nvme1n1 | grep -A4 '^Partition table scan:'
Сканирование таблицы разделов:
  MBR: защитный
  BSD: отсутствует
  APM: отсутствует
  GPT: присутствует

dmesg | grep efi
[    0.000000] efi: EFI v2.7 от American Megatrends

lsblk -f | grep nvme
nvme0n1
├─nvme0n1p1        vfat        FAT12
├─nvme0n1p2        vfat        FAT32
├─nvme0n1p3        crypto_LUKS 2
│ └─nvme0n1p3crypt btrfs
├─nvme0n1p4        crypto_LUKS 2
│ └─nvme0n1p4crypt btrfs
└─nvme0n1p5        crypto_LUKS 2
  └─nvme0n1p5crypt ext4        1.0
nvme1n1
├─nvme1n1p1        vfat        FAT32
├─nvme1n1p2        crypto_LUKS 2
│ └─nvme1n1p2crypt btrfs
├─nvme1n1p3        crypto_LUKS 2
│ └─nvme1n1p3crypt btrfs
└─nvme1n1p4        ext4        1.0

В последние дни я всегда загружался с nvme0n1, теперь я собираюсь переключиться на nvme1n1.

Я буду иметь efi и grub вместе на nvme1n1p1.

Я сейчас полностью очистил с помощью efibootmgr.

Я попробовал это:

efibootmgr -c -d /dev/nvme0n1 -p 1 -L "gentoo_grub_at_sk_hynix_256gb" -l "\EFI\gentoo\grubx86.efi"
efibootmgr -c -d /dev/nvme1n1 -p 1 -L "gentoo_grub_at_wd_1tb"         -l "\EFI\gentoo\grubx86.efi"

efibootmgr теперь показывает мне:

Boot0000* gentoo_grub_at_sk_hynix_256gb HD(1,GPT,7127e659-ff38-43dc-938d-65e861d465ef,0x800,0x1000)/File(\EFI\gentoo\grubx86.efi)
Boot0001* gentoo_grub_at_wd_1tb HD(1,GPT,d11b9b38-0fb9-2241-994d-6051c2280651,0x800,0x200000)/File(\EFI\gentoo\grubx86.efi)
Boot0002* UEFI: SMI USB DISK 1100       PciRoot(0x0)/Pci(0x14,0x0)/USB(6,0)0000424f

Затем я перезагрузил систему, но она загружается только с USB-ключа Kubuntu.

Я заметил что-то странное, если я сейчас использую efibootmgr, я вижу:

Boot0000* gentoo_grub_at_sk_hynix_256gb VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0001* gentoo_grub_at_wd_1tb VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0002* UEFI: SMI USB DISK 1100       PciRoot(0x0)/Pci(0x14,0x0)/USB(6,0)0000424f

Не знаю, что такое 99e275e7-75a0-4b37-a2e6-c5385e6c00cb, но почему обе записи одинаковы и почему это происходит сейчас?

Что мне нужно сделать, чтобы моя система могла загрузиться с nvme1n1 из файла \EFI\gentoo\grubx86.efi?

Редактирование:
Я теперь попробовал

efibootmgr -c -d /dev/nvme0n1 -p 1 -L “gentoo_grub_at_sk_hynix_256gb”
-l “\EFI\gentoo\grubx86.efi” -e 3 efibootmgr -c -d /dev/nvme1n1 -p 1 -L “gentoo_grub_at_wd_1tb” -l “\EFI\gentoo\grubx86.efi” -e 3

Вывод от efibootmgr после перезагрузки:

Boot0000* gentoo_grub_at_sk_hynix_256gb PciRoot(0x0)/Pci(0x1b,0x4)/Pci(0x0,0x0)/NVMe(0x1,AC-E4-2E-81-70-26-2B-18)/HD(1,GPT,7127e659-ff38-43dc-938d-65e861d465ef,0x800,0x1000)/File(\efi\EFI\gentoo\grubx86.efi)
Boot0001  gentoo_grub_at_wd_1tb PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-8B-4A-88-8F-49)/HD(1,GPT,d11b9b38-0fb9-2241-994d-6051c2280651,0x800,0x200000)/File(\EFI\gentoo\grubx86.efi)

В BIOS/UEFI я теперь вижу оба диска nvme0n1 и nvme1n1, но не могу с них загрузиться.

Редактирование2:

lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint,uuid,partuuid
NAME        FSTYPE        SIZE FSUSED LABEL PARTLABEL        MOUNTPOINT     UUID                                 PARTUUID
sda                       3,6T                                                                                   
└─sda1      crypto_LUKS   3,6T                                              045113cb-b00f-4551-9b2c-67fb8d97499f df3d5eb6-bd5b-49e4-83bb-6a606e5be324
sdb                       3,6T                                                                                   
└─sdb1      crypto_LUKS   3,6T                                              189c8e42-f9c1-400a-91df-470124af0c19 6c138f9e-1802-45c0-ac72-4dc9015895b1
sdc                       7,3T                                                                                   
└─sdc1      crypto_LUKS   7,3T              Linux filesystem                26bca951-5441-471b-836c-295c38464710 a415550a-4cb8-424b-96cc-9229780f35d2
sdd                       7,3T                                                                                   
└─sdd1      crypto_LUKS   7,3T              Linux filesystem                3fb9ec1c-e5bb-4e94-b8be-14c31685f819 8609a2eb-f713-4eb4-b2f5-42e25875cd4d
sde                       7,3T                                                                                   
└─sde1      crypto_LUKS   7,3T              Linux filesystem                6576b74d-ffca-440e-bd92-857708f1d1fc 75e788df-10a5-4d20-b20a-0991f11e4310
sdf                       7,3T                                                                                   
└─sdf1      crypto_LUKS   7,3T              Linux filesystem                9abfd98b-c315-487d-8928-9e20c088be08 f2e36ad3-9403-4891-a9de-e0745058dd06
sdg         vfat         29,5G   3,9G                        /cdrom         A28D-C9E1                            
nvme0n1                 238,5G                                                                                   
├─nvme0n1p1 vfat            2M   136K       EFI System       /mnt/nvme0n1p1 20F5-4103                            7127e659-ff38-43dc-938d-65e861d465ef
├─nvme0n1p2 vfat            1G              Linux filesystem                2142-7173                            07365df9-524f-466c-9a3b-21d6f33fa6ba
├─nvme0n1p3 crypto_LUKS    32G              Linux filesystem                3a920ea9-b868-46f0-9101-c926c4b894d5 f7f48cdc-7fed-404c-9c0a-dfd36b482998
├─nvme0n1p4 crypto_LUKS    32G              Linux filesystem                fdb55604-1ca8-4aa3-8af7-41697d63fc32 a5f3d5b8-23d7-428c-a27b-1cf3f83267f3
└─nvme0n1p5 crypto_LUKS 173,5G              Linux filesystem                c5747f0e-8f2d-4df8-82e2-46715d854d0d 750219f3-218c-4b96-b467-8f5d8c2f41de
nvme1n1                 931,5G                                                                                   
├─nvme1n1p1 vfat            1G  30,2M                        /mnt/nvme1n1p1 48B1-0A01                            d11b9b38-0fb9-2241-994d-6051c2280651
├─nvme1n1p2 crypto_LUKS    64G                                              41371f53-e543-4930-a249-ef897cdd0061 f7ee6083-3818-448b-8b35-0007db43068b
├─nvme1n1p3 crypto_LUKS    64G                                              6ff6fad4-3bf0-4f30-a67c-748163638949 37241146-de30-4fa2-9f93-1e7c48c20a21
└─nvme1n1p4 ext4        802,5G                                              49551619-c398-48a4-a991-507c552cbc83 1129fbc5-f848-43c6-a9fa-c0fdd75690b7

Вот вывод boot-repair.

Ссылка на pastebin -> https://pastebin.com/CV0ffCNd

Я пытался добавить обе строки снова с -e 1 вместо -e 3, они тогда опять были с VenHw.

Так что я снова их удалил и добавил их заново с опять -e 3.

Это материнская плата под брендом Gigabyte.

Secure Boot отключен.

Я абсолютно не понимаю, почему они теперь перечислены оба в UEFI/BIOS, но не могут загрузиться!?

Редактирование3:

Я помню, что в UEFI/BIOS USB-ключ с живой системой Kubuntu назван “UEFI…..”, а оба NVMe диска не названы “UEFI” … только “gentoo_grub_….”, имеет ли это значение?

Ответ или решение

Проблемы с загрузчиком UEFI и efibootmgr: Решение проблемы

Учитывая представленные вами данные и выявленные проблемы с загрузкой системы, давайте проанализируем ситуацию и предложим несколько шагов по решению проблемы.

Описание ситуации

У вас имеется две NVMe флешки: nvme0n1 (SK Hynix 256GB) и nvme1n1 (WD 1TB). Вы ранее загружали систему с nvme0n1, однако после того как вы применили efibootmgr, ваш компьютер больше не загружается из этого накопителя. В BIOS/UEFI вы не видите ни одного из NVMe-накопителей для загрузки, что мешает вашей системе загружаться корректно.

Анализ текущего состояния

  1. Разделы на дисках:

    • Выполнив команду gdisk -l на обоих дисках, вы подтвердили, что оба диска имеют таблицу разделов GPT.
    • Содержание разделов указывает на то, что на обоих дисках присутствует EFI-раздел (vfat), который вы, вероятно, используете для хранения загрузчика.
  2. Настройки efibootmgr:

    • Вы использовали efibootmgr для создания записей для загрузки, однако после перезагрузки система так и не загружалась с обоих NVMe-накопителей.
    • Все записи efibootmgr изменяются на VenHw, что может указывать на проблемы с идентификацией или совместимостью.
  3. Статус загрузки:

    • После выполнения ваших команд efibootmgr, обе флешки отображаются в BIOS/UEFI, однако они не загружаются. Это может быть связано с тем, что UEFI не может корректно обнаружить загрузочные файлы или сама структура разделов может быть создана некорректно.

Решение проблемы

Для устранения текущих проблем с загрузчиком предлагаю следующее:

  1. Проверка файловой системы EFI:

    • Загрузитесь с USB-накопителя Kubuntu и проверьте, что файлы загрузчика действительно находятся в указанном пути \EFI\gentoo\grubx86.efi на разделе, который вы пытаетесь использовать.
    • Убедитесь, что grubx86.efi не поврежден и имеет корректные права.
  2. Повторная настройка efibootmgr:

    • Удалите текущие записи с помощью efibootmgr -b <номер> -B, и затем создайте новые записи.
    • Убедитесь, что вы правильно указываете диск и раздел. Например:
      efibootmgr -c -d /dev/nvme1n1 -p 1 -L "gentoo_grub_at_wd_1tb" -l "\EFI\gentoo\grubx86.efi"
  3. Проверка конфигурации BIOS/UEFI:

    • Убедитесь, что в настройках BIOS/UEFI отключено Secure Boot.
    • Проверьте, установлен ли правильный режим (UEFI или Legacy). Поскольку у вас есть UEFI-системы, обязательно выберите UEFI.
  4. Использование Boot-Repair:

    • Если проблема продолжает существовать, воспользуйтесь утилитой Boot-Repair, которая может помочь в восстановлении загрузочной записи и исправлении потенциальных ошибок. Вы можете использовать её в режиме Live USB.
  5. Обновление прошивки BIOS/UEFI:

    • Если ни один из вышеперечисленных шагов не решает проблему, возможно, устаревшая версия BIOS/UEFI может быть причиной. Проверьте наличие обновлений на сайте производителя вашей материнской платы.

Вывод

Ваша проблема с загрузкой может быть следствием неправильной конфигурации UEFI или ошибок в структуре загрузочной информации на дисках. Следуя предложенным шагам, вы сможете найти и исправить ошибку, чтобы система могла вновь загружаться с нужного NVMe-диска. Если после всех попыток проблема остается нерешенной, возможно потребуется обратиться за помощью к специалистам в области информационных технологий.

SEO-Оптимизация

Данная статья содержит исследования, обсуждения и решения относительно проблем с efibootmgr и UEFI, что должно помочь в привлечении целевой аудитории, интересующейся темами загрузки Linux систем, конфигурации загрузчиков и управления дисками.


Запомните, важно регулярно выполнять резервное копирование важных данных, чтобы избежать их потери в случае непредвиденных ситуаций с оборудованием или программным обеспечением.

Оцените материал
Добавить комментарий

Капча загружается...