Доброго времени суток, Хабр!
В своей работе 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.imgBegin: 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=1536End: 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 и для чего это мне понадобилось
Очень надеюсь, что описание данного кейса сэкономит коллегам кучу нервных клеток и время на поиск решения (спасибо, Хабр, что ты есть). Комментарии к статье приветствуются
Комментарии (27)
aborouhin
18.01.2023 22:04+1У самого "домашний" гипервизор - Proxomox, но что-то он такими вот сюрпризами совсем не радует. У шестой версии был очень много нервов мне стóивший глюк с невозможностью загрузиться после ребута, если корневой раздел на ZFS. Решалось магическими манипуляциями в GRUB rescue mode. Но когда физического доступа к серверу нет - то боишься на этот Proxmox даже дышать :)
Aquahawk
18.01.2023 22:10Сколько я на него смотрю, хочется попробовать, а сыкотно. Да и вообще понимаю что Linux Containers значительно лучше полных виртуалок, разделяемая оператива и ядро с его дисковым кешом, это круто
LuchS-lynx
18.01.2023 22:50Так берите и пробуйте. Глаза боятся, а руки делают ;) начинал с ПК в 2019-м, перевел рабочую ОС с софтом с хоста в виртуалку, год на ноутбуке использую - полет нормальный.
Aquahawk
18.01.2023 22:52+1у меня с 2019 сервер без проблем на железе живёт, работает и есть не просит, железо вот сдохло, пришлось побегать за заменой.
Bessome Автор
19.01.2023 00:26-2Надо не пробовать, а переводить свой прод. Продукт достойный внимания, и это как минимум
13werwolf13
19.01.2023 07:16Да и вообще понимаю что Linux Containers значительно лучше полных виртуалок
всё зависит от задач. действительно зачастую lxc контейнер больше подходит для выполнения задачи чем полноценная виртуалка, но есть и исключения (самое очевидное это НЕ linux based ос в качестве "гостя", или необзодимость внутри "гостя" играться с разными ядрами и/или ядерными модулями)
Сколько я на него смотрю, хочется попробовать, а сыкотно.
попробуйте lxd, очень шустрый и удобный инструмент позволяющий в одну команду получить за пару секунд рабочий lxc контейнер или виртуалку, в чём-то даже поинтереснее чем proxmox, из недостатков - отсутствие какой либо штатной вебморды (хотя емнип на гитхабе видел сторонние вебморды для него). из плюсов - ставится на любой ваш дистрибутив и в случае если не понравится так же легко удаляется (в отличии от проксмокса который сам является дистрибутивом, и в случае с установкой на чистый дебиан знатно так его перепахивающий вдоль и поперёк), а так же дополнительные фичи вроде портфорвардинга и выполнения команд внутри контейнера/вм без входа в её интерактиный шелл.
Mirzapch
19.01.2023 09:26dd if=/dev/nvmes0n1 of=/backupТак можно делать? У вас источник - раздел диска, приёмник - каталог.
Если хотим записать образ в файл, нужно явно указать имя файла. Если хотим переписать физические секторы с одного раздела на другой, то приёмник не нужно никуда монтировать.
UPD. Перепроверил. dd не даёт выполнить команду, потому что "failed to open'~/tmpdir': Is a directory".
Bessome Автор
19.01.2023 10:30Спасибо, подкорректирую, не указал имя файла
Johan_Palych
19.01.2023 15:53Просто надо почитать:
https://wiki.archlinux.org/title/Dd_(Русский) Клонирование всего диска Копирование физического диска /dev/sda в диск /dev/sdb: # dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync status=progressBessome Автор
19.01.2023 16:06Спасибо, да, можно с ключами и прогрессом.
Это бекап всего диска, а в статье и комментариях разговор зашел за бекап gpt/mbr.
Не вижу смысла выкладывать прогресс и ключи для записи около 1500 байт. Если уж на диске сбой, то тут ключ noerror не нужен, нужна правда.
Bessome Автор
19.01.2023 10:39"failed to open'~/tmpdir': Is a directory".
Это что-то у Вас с пользовательскими настройками tmpdir
Сейчас идет дамп диска web-сервера. Ошибок нет, вообще пустой вывод
Mirzapch
20.01.2023 10:58Что, простите? Вам символ "~" ни на что не намекнул?
Bessome Автор
20.01.2023 11:03Я понял, что Вы создали временную директорию tempdir в каталоге пользователя и пытались писать туда вывод dd.
Выше отписался, что поправил вывод команды в статьеЕще раз огромное спасибо за толковый комментарий
polar_yogi
19.01.2023 10:21efi-boot debian, который необходимо установить в загрузочный раздел с типом ext2, в дальнейшем монтируемый в /boot/efi.
В статье (12 года) ext2 не упоминается, естественно, потому что efi форматируется в fat32
Начал подозревать
Имеет смысл разобраться в каком режиме (efi/bios) у вас происходит загрузка, и в зависимости от этого действия по восстановлению загрузчика будут отличаться.
Bessome Автор
19.01.2023 10:33У меня EFI в формате ext3 - диск /dev/nvmes0n1p2
Формат дисков определил lsblk и fsck -l /dev/<имя диска>
polar_yogi
19.01.2023 13:42можете показать вывод
fdisk -l /dev/nvmes0n1
и
efibootmgr
?Bessome Автор
19.01.2023 13:58Уж пардон, не правлено, на работающем
И Убедили, vfat раздел. Что с ним было ранее, непонятно, видимо были проблемы именно с ФС разделов?
polar_yogi
19.01.2023 15:16Да я как бы не пытаюсь убедить, есть спецификация EFI, которая говорит что ФС должна быть FAT32, FAT16 или FAT12 в заивисмости от размера.
Еще момент - у efi раздела должен быть соответствующий тип (не тип файловой системы, а тип раздела), у вас его нигде не видно, поэтому я просил вывод fdisk -l /dev/nvme0n1, но его нет.
Вывод fsck я вроде не спрашивал.Bessome Автор
19.01.2023 16:14Спасибо, Ваш комментарий был важен в плане статьи.
Даю скриншот вывода fdisk/gdisk.Данный скриншот уже был мною добавлен, по крайней мере я был в этом уверен.
werter_l
21.01.2023 15:39Спасибо )
> Недавно, после установки драйверов видеокарты NVIDIA для XFCE4 на Proxmox 7.xx
Вот тут понял (
Вы устанавливаете DE прямо на PVE??
1 Если да, то не надо так делать. Никогда. PVE - это прежде всего гипервизор и ему DE нужно как 5-я нога зайцу.
2 Пользуйте zfs - отличная и оч надежная ФС (+ сжатие на лету, снепшоты etc).
Сказки про "жрущую" ОЗУ zfs не слушайте - размер zfs arc гибко настраивается. Плюс l2arc можно в виде ssd прикрутить для скорости.
Цикл заметок про pve, zfs etc https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2/
Bessome Автор
21.01.2023 19:18Устанавливаю для следующей статьи, хочу полноценно использовать видеокарту для отображения Windows. Экспериментировал с пробросом видяхи в виртуалку, пока безуспешно.
Необходимо было убедиться в работоспособности режима IOMMU и накатить драйверы Nvidia - vgpu и nvidia-grid и протестировать работу. Рассчитывал на вывод содержимого виртуальной машины напрямую на выход видеокарты, подключенной к монитору вместо консоли Proxmox.
Пока безуспешно, только один раз виртуалка с Windows взлетела, пока оставил в связи с загрузкой другими задачами
В итоге есть решение: SPICE в XFCE4 для доступа к Windows из консоли сервера.
Это лабораторная работа, в прод не пойдет и не будет рекомендована
Vasily_Pechersky
19.01.2023 16:25+1У меня в проде 16 нодовый кластер. 5 лет, 3 апгрэйда версий.
werter_l
21.01.2023 16:02А что у вас в кач-ве общего хранилища?
Bessome Автор
21.01.2023 19:09На данный момент у меня один hdd 3Tb WD Green, на котором раздел для VM с Synology (изначально были ограничения ОЗУ на машине в облаке). Это был большой переезд из облака, через копирование дисков. Там был 1Tб вируальный, тут 3. Создал кластер proxmox home + proxmox cloud, перетащил виртуальную машину. Добавил еще 1Tb виртуального места, слил диски в консоли Synology.
В дальнейших планах приобретение малошумного Intel Pentium Gold с установкой туда Freenas на PCI RAID контроллере для NVME. А WD Green 3tb вернуть в NAS WD Live book.
LuchS-lynx
Когда я первый раз получил эту ошибку, то на SSD меня спасла эта инструкция с картинки, найденная на форуме:
https://forum.proxmox.com/threads/upgrade-pve-6-x-to-7-x-grub-issues.92118/page-2#post-429676
Кстати тут есть нюанс, когда грузишься с Live-CD/DVD то консольной команды chroot может и не быть. Ее еще придется ставить. По крайней мере в Debian 11 ее не было.
Я не до конца понимаю, но небольшое изменение размера диска убирает ошибку. На какое-то время. ИМХО, если такое случилось, то лучше всего сделать бэкапы виртуалок и переустановить ProxMox
Bessome Автор
Есть такое. В моем случае не было смысла менять размер дисков. Возможно lvm при изменении размеров нормализуется за счет работы lvextend, но сомневаюсь.
Дистр был ubuntu liveCD вчерашний.