Заметка о восстановлении 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'. В статье "Команда dd и все, что с ней связано" описан механизм бекапа mbr:

# 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 и для чего это мне понадобилось

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