Восстановить uefi загрузчик linux

Заметка о восстановлении Grub UEFI для Proxmox 7.xx (Debian 11)

В своей работе IT-специалист иногда сталкивается с задачами, которые входят только в общий кругозор на уровне «читал, осознал», требующими срочного решения.

Недавно, после установки драйверов видеокарты NVIDIA для XFCE4 на Proxmox 7.xx перестал пинговаться гипервизор с роутера и компов сети. После его перезагрузки я увидел черный экран и надписью «grub disk native sectors not found».

Загрузившись с LiveUSB Ubuntu я прочитал разделы диска, убедился, что данные целы, проблема в загрузчике. Стало ясно, что проблема с разделом Grub BIOS, так как разделы диска EFI и рабочий монтировались корректно.

Надо сказать, что я устанавливал Proxmox 7.xx со стандартными настройками разбиения диска, то есть три раздела GPT-диска /dev/nvmes0n1: /dev/nvmes0n1p1 — GrubBIOS; /dev/nvmes0n1p2 — EFI диск; /dev/nvmes0n1p3 — LVM раздел, в котором Proxmox по-умолчанию задает два LVM диска /dev/pve/root и /dev/pve/swap

Убедившись, что данные корректны, диски fsck — тест проходят приступил к восстановлению. Я вставил поисковик текст ошибки и открыл статью-инструкцию на сайте Proxmox.

Смысл ясен: грузим Linux-ОС с поддержкой LVM, активируем диск LVM с загрузчиком гипервизора, монтируем в папку, заходим chroot и восстанавливаем загрузчик (ничего сложного). Ниже листинг до проблемы, которая возникла у меня:

#Использую права админа постоянно, чтобы не писать везде sudo sudo su - #Сканирую LVM диски vgscan Found volume group "pve" using metadata type lvm2 #Активирую Volume Group (VG) "pve" vgscan -ay pve #Смотрим, что есть lsblk nvmes0 ├─nvmes0n1p1 ├─nvmes0n1p2 vfat └─nvmes0n1p3 LVM2_member └──pve-swap swap └─pve-root ext4 #монтируем в директорию /mnt mount /dev/pve/root /mnt mount /dev/nvmes0n1 /mnt/boot

Ошибка следующая: диск уже активен, смонтировать его нельзя. Естественно активен, ведь он активирован как том VG (LVM). То есть, один шаг инструкции не работает. Иду дальше:

mount /dev/nvmes0n1p2 /mnt/boot ls /mnt/boot EFI

Вывод показывает, что мы смонтировали EFI — раздел с загрузчиком Debian. Перемонтируем его правильно:

umount /mnt/boot mount /mnt/boot/efi ls /mnt/boot config-5.15.30-2-pve initrd.img-5.15.74-1-pve System.map-5.15.74-1-pve config-5.15.74-1-pve initrd.img-5.15.83-1-pve System.map-5.15.83-1-pve config-5.15.83-1-pve memtest86+.bin vmlinuz-5.15.30-2-pve efi memtest86+_multiboot.bin vmlinuz-5.15.74-1-pve grub pve vmlinuz-5.15.83-1-pve initrd.img-5.15.30-2-pve System.map-5.15.30-2-pve

Ясно, что в /mnt/boot есть необходимые файлы-образы ядра для загрузки, следовательно монтировать туда диск нет необходимости. Действуем дальше:

mount -t proc proc /mnt/proc mount -t sysfs sys /mnt/sys mount -o bind /dev /mnt/dev mount -o bind /run /mnt/run chroot /mnt update-grub

Апгрейд grub произведен, загрузочные файлы сформированы по необходимым им путям, необходимо восстановить загрузчик. Изучаем предметную область:

fdisk -l /dev/nvmes0n1p1 Disk /dev/nvmes0n1p1: 1 MiB, 1048576 bytes, 2048 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes fsck -N /dev/nvmes0n1p1 root@pve:~# fsck -n /dev/nvme0n1p1 fsck from util-linux 2.36.1 e2fsck 1.46.5 (30-Dec-2021) ext2fs_open2: Bad magic number in super-block fsck.ext2: Superblock invalid, trying backup blocks. fsck.ext2: Bad magic number in super-block while trying to open /dev/nvme0n1p1 The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 lsblk -no name,fstype nvmes0n1 ├─nvmes0n1p1 ├─nvmes0n1p2 vfat └─nvmes0n1p3 LVM2_member ├─pve-swap swap └─pve-root ext4 gdisk /dev/nvmes0n1 GPT fdisk (gdisk) version 1.0.6 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Command (? for help): i Partition number (1-3): 1 Partition GUID code: 21686148-6449-6E6F-744E-656564454649 (BIOS boot partition) Partition unique GUID: AEC0785C-ECA8-0C4C-A7AD-C5C11F0B2B20 First sector: 34 (at 17.0 KiB) Last sector: 2047 (at 1023.5 KiB) Partition size: 2014 sectors (1007.0 KiB) Attribute flags: 0000000000000004 Partition name: '' # Следовательно, файловая система BIOS boot partition, размер диска 1Мб #диск /dev/nvmes0n1p2 - vfat, EFI загрузчик #напомню, мы в chroot, поэтому тут каталог /mnt свободен mount /dev/nvmes0n1p1 /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/nvmes0n1p1, missing codepage or helper program, or other error.

Если кратко, то по запросу UEFI boot Debian 11 получил статью, где описывается, что есть некий efi-boot debian, который необходимо установить в загрузочный раздел с типом vfat, в дальнейшем монтируемый в /boot/efi. Начал подозревать, что /dev/nvmes0n1p1 и является таким разделом, в отличие от заявленного в статье о восстановлении загрузки /dev/sda.

Читателю рекомендую произвести перед каждым действием с изменением данными бекап «оперируемого» диска, например на внешний диск. Самое простое, но и длительное, это зацепить внешний HDD (предполагаю, что он примонтирован в каталог /backup) и на него выполнить клон диска утилитой DD:

dd if=/dev/nvmes0n1 of=/backup/nvmes0n1.img

Begin: UPD#1 19.01.2023

# dd if=/dev/sda of=mbr.img bs=512 count=1

Для бекапа загрузки GPT, взято из этого источника

dd if=/dev/nvmes0n1 of=/backup/gpt_table_nvmes0n1 bs=1 count=1536

End: UPD#1 19.01.2023

Я же сделал бекап сразу после запуска LiveCD, поэтому продолжаю:

grub-install /dev/nvmes0n1p1

После выхода из chroot, выключения ОС LiveUSB, изъятия флеш-диска из системного блока, произошла корректная загрузка моего Proxmox 7.xx со всеми виртуальными машинами и настройками.

В течение недели, до 24 января 2023 года напишу еще пару статей о:

• зачем IT-специалисту вообще дома гипервизор Proxmox 7.xx
• как запустить в Proxmox 7.xx гостевую машину в окне Proxmox 7.xx и для чего это мне понадобилось

Очень надеюсь, что описание данного кейса сэкономит коллегам кучу нервных клеток и время на поиск решения (спасибо, Хабр, что ты есть). Комментарии к статье приветствуются

Источник

Восстановить uefi загрузчик linux

Сегодня мы рассмотрим с вами один из вариантов восстановления загрузки Ubuntu 16.04, установленной в режиме UEFI. Предыстория этого эпизода очень простая — на ПК были установлены две ОС — Ubuntu и Windows 10, при этом разбиение по разделам было «хитрым», т.е. на одном диске был загрузочный раздел EFI System (ESP), а также раздел Linux filesystem и Linux своп, а на другом диске был системный раздел NTFS Windows и еще один дополнительный раздел ext4 от Linux. который монтировался в отдельную папку. Материнская плата — Asus Z170-P. Потребовалось просто физически переставить всю эту систему, т.е. материнскую плату, накопители и т.п. в другой корпус. Однако, после включения Ubuntu уже не загружалась 🙁 Начнем с того что в обычном варианте загрузки (когда все работает и Ubuntu, и Windows установлены с использованием UEFI) мы видим в BIOS’е следующие варианты загрузки:

Однако, после переустановки MB и накопителей в другой корпус вариант загрузки с Ubuntu просто пропал. Что могло произойти? GRUB находящийся на разделе с Ubuntu никуда не делся, его конфигурация тоже вообщем-то не изменилась, однако, из списка доступных типов загрузки вариант с Ubuntu просто пропал. Попытка выбрать накопитель с установленной Ubuntu в качестве приоритетного для загрузки — тоже вообщем-то ничего не дала, т.к. BIOS находил Windows Boot Manager и упрямо загружал Windows. В интернете можно найти множество потрясающих (в хорошем смысле этого слова), но бесполезных в данной ситуации мануалов (приведу ссылки на них, т.к. ситуации возможны разные и информация в любом случае будет полезной):

• Восстановление GRUB
• How To Repair Grub Boot Loader On Ubuntu Linux 16.04 /15.10 / 15.04
• Boot repair, Boot-Repair, UEFI
• Boot Repair — EFI Mode
• UEFI Installing — Tips
• Установка дистрибутива на компьютер с EFI
• Настройка UEFI-загрузчика. Самое краткое руководство в мире (рекомендуется к прочтению для понимая смысла UEFI загрузки)

Но в большинстве из них не приводится информация о восстановлении загрузки именно в UEFI режиме или найти ее достаточно сложно или же рекомендуется использовать утилиту boot-repair, которой нет на LiveCD по-умолчанию. А между тем все достаточно просто.

Загружаемся с LiveCD с Ubuntu через UEFI (если у вас ПК подключен через HDMI может возникнуть проблема с загрузкой с LiveCD, решается она добавлением параметра nomodeset, как описано здесь), в крайнем случае если GUI не стартует — переключаемся на текстовую консоль (Ctrl-Alt-F1). Далее смотрим какие разделы у нас есть с помощью sudo fdisk -l :

 Device Start End Sectors Size Type /dev/sda1 2048 1128447 1126400 550M EFI System /dev/sda2 1128448 79626398 78497951 37.4G Linux filesystem /dev/sda3 79628288 85917854 6289567 3G Linux swap 

Здесь наша задача определить загрузочный EFI раздел. Как мы видим — это /dev/sda1. Монтируем раздел /dev/sda1 так — sudo mount /dev/sda1 /mnt и убеждаемся в том в ней есть EFI загрузчик Ubuntu /EFI/ubuntu/grubx64.efi :

efibootmgr -c -d /dev/sda -p НОМЕР_РАЗДЕЛА -L "Ubuntu" -l "\Efi\ubuntu\grubx64.efi" 

В нашем случае НОМЕР_РАЗДЕЛА = 1, т.к. EFI System находится на /dev/sda1. Еще несколько полезных возможностей efibootmgr:

• sudo efibootmgr — просмотреть список доступных вариантов загрузки.
• sudo efibootmgr —bootnum xxxx —delete-bootnum — удалить вариант с номером xxxx.

Вот и все, перезагружаем ПК, выбираем в UEFI Bios первичным только что добавленный нами вариант загрузки «Ubuntu» и радуемся работающей ОС.

Источник