Proxmox «Не завантажувальний диск»: порядок завантаження BIOS/UEFI, прапори диска та швидкий шлях відновлення

Швидкий план діагностики

Це порядок дій для «припинити кровотечу». Не імпровізуйте. Не починайте перевстановлювати Proxmox, ніби це ноутбук 2009 року.

1) Підтвердьте режим прошивки та порядок завантаження (помилка BIOS/UEFI — головний витрата часу)

• Якщо машина в UEFI-режимі, вам потрібен том системи EFI (ESP), запис завантаження EFI у NVRAM і робочі EFI-бінарні файли.
• Якщо машина у режимі застарілого BIOS, потрібен GRUB у MBR (або BIOS boot partition для GPT), і диск має бути позначено як завантажувальний так, як цього очікує прошивка.

Рішення: оберіть один режим і дотримуйтеся його. Системи з комбінованим режимом «працювали раніше» — поки раптом не перестали, зазвичай після скидання прошивки.

2) Підтвердьте, що диск виявлено і потрібний диск перший

Порядок завантаження в прошивці нестабільний. Перемкніть кабель SATA або додайте NVMe — і ваш завантажувальний диск стає «іншим».

Рішення: якщо диск відсутній на апаратному рівні, зупиніться. Це не проблема GRUB.

3) З середовища відновлення перевірте розділи: ESP/BIOS boot, root і те, що фактично встановив Proxmox

Не вгадуйте. Перегляньте таблиці розділів, прапори та файлові системи. Якщо у вас ZFS, підтвердіть імпорт пулу.

Рішення: якщо ESP відсутній або не змонтований — відновіть/перекладіть його. Якщо ZFS-пул не імпортується, робота з завантажувачем не має значення, доки сховище не буде здоровим.

4) Відновіть завантажувач і записи EFI (мінімуми змін, що повернуть систему в роботу)

• UEFI: змонтуйте ESP, перевстановіть EFI-файли, при потребі відтворіть записи NVRAM за допомогою efibootmgr.
• BIOS: перевстановіть GRUB на правильний диск і згенеруйте конфігурацію заново.

Рішення: не перевстановлюйте Proxmox, якщо ваш розділ ОС не зник або не пошкоджений безповоротно.

5) Забезпечте резервність завантаження (щоб це не стало регулярним засіданням)

Записи UEFI і ESP можуть бути єдиними точками відмови навіть на ZFS-дзеркалах. Виправляйте це після того, як вузол завантажиться, а не до.

Одна парафразована ідея, якої часто дотримуються в SRE-кругах: «Надія — це не стратегія» — використовуйте чеклисти, а не відчуття.

Що насправді означає «не завантажувальний диск»

Це скарга прошивки, а не Proxmox. Це означає, що системна прошивка спробувала свої налаштовані цілі завантаження й не знайшла нічого, що вважає завантажувальним.

Де ланцюжок дає збій

1. Виявлення апаратури: чи бачить прошивка взагалі диск?
2. Вибір завантаження прошивкою: чи намагається вона зчитати правильний диск і в правильному режимі (UEFI чи legacy)?
3. Розташування коду завантаження:
   • Legacy BIOS: MBR/boot sector → GRUB stage1 → GRUB core image → /boot/grub
   • UEFI: запис у NVRAM → ESP FAT32 → EFI-бінарник (shim/grub/systemd-boot) → kernel/initramfs
4. Передача керування ОС: ядро монтує кореневу файлову систему; у випадку ZFS воно може імпортувати пул на ранньому етапі.

Більшість інцидентів Proxmox із «не завантажувальним диском» — одне з наступного:

• Прошивка мовчки скинулася до значень за замовчуванням (часто змінюючи поведінку UEFI/legacy).
• Порядок завантаження змінився після додавання/видалення дисків.
• ESP було перезаписано, не змонтовано або створено тільки на одному диску у дзеркалі.
• GRUB встановлено на неправильний пристрій (поширено після заміни диска).
• Записи NVRAM UEFI стерті (оновлення прошивки, скидання CMOS, деякі маніпуляції з віддаленим управлінням).

Жарт №1: Порядок завантаження прошивки — як офісні місця: ви можете бути «важливим», поки Обслуговування не переставить горщик з рослиною.

Цікаві факти та історичний контекст (бо минуле продовжує ламати теперішнє)

• BIOS старший за вашу кар’єру: конвенції IBM PC BIOS ведуться з початку 1980-х, і багато «чарів завантаження» — це суміш сумісності з минулим і латок.
• UEFI мав замінити BIOS: він формалізував завантаження як запуск EFI-бінарників з FAT-файлової системи, а не з непрозорих boot-секторів.
• GPT vs MBR — не тільки про кількість розділів: GPT природно поєднується з UEFI, тоді як завантаження legacy BIOS з GPT потребує спеціального «bios_grub» розділу для GRUB.
• ESP — це просто FAT32: ваш «високодоступний хост віртуалізації» часто завантажується з файлової системи, призначеної для камер і флешок.
• Записи NVRAM крихкі: оновлення прошивки, скидання CMOS і навіть інколи відключення живлення можуть їх витерти, навіть якщо диски ідеальні.
• Secure Boot змінив очікування: машини все частіше за замовчуванням вмикають Secure Boot; розгортання Proxmox зазвичай вимикає його, якщо не керувати підписаним ланцюгом завантаження.
• Завантажувачі Linux еволюціонували: LILO змінився на GRUB, потім GRUB2; кожен додав гнучкості й нові способи неправильно налаштувати середовище завантаження.
• ZFS для завантаження «підтримується», але не «простішає»: ZFS дає надійність для даних, але завантаження все ще залежить від крихітних не-ZFS шматочків: ESP, GRUB, initramfs-модулів.
• Імена пристроїв нестабільні: /dev/sda сьогодні може стати /dev/sdb завтра після змін у HBA; сучасна практика використовує by-id шляхи саме з цієї причини.

Практичні завдання: команди, що означає вивід, і яке рішення прийняти

Це польові дії, які можна виконати з shell Proxmox, Debian live ISO або інсталятора Proxmox у режимі відновлення (де доступно). Мета — перейти від «не завантажується» до «я точно знаю, який шар дав збій».

Завдання 1: Підтвердіть, чи середовище відновлення завантажено в UEFI чи BIOS-режимі

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Значення: Якщо це виведе UEFI, ваша сесія відновлення — UEFI. Це має відповідати тому, як ви плануєте завантажувати вузол.

Рішення: Якщо машина раніше завантажувалась у legacy BIOS, а ви зараз в UEFI (або навпаки), виправте налаштування прошивки перед тим, як чіпати диски.

Завдання 2: Перевірте, які диски бачить ОС (перевірка апаратної цілісності)

cr0x@server:~$ lsblk -e7 -o NAME,SIZE,MODEL,SERIAL,TYPE,FSTYPE,MOUNTPOINTS
NAME      SIZE MODEL            SERIAL           TYPE FSTYPE MOUNTPOINTS
sda     447.1G INTEL SSDSC2KB   BTWL1234567      disk
├─sda1    512M                  -                part vfat
├─sda2   1007K                  -                part
└─sda3  446.6G                  -                part zfs_member
sdb     447.1G INTEL SSDSC2KB   BTWL7654321      disk
├─sdb1    512M                  -                part vfat
├─sdb2   1007K                  -                part
└─sdb3  446.6G                  -                part zfs_member

Значення: Диски видимі, розділи існують, і ви вже можете помітити ESP (vfat) та члени ZFS.

Рішення: Якщо ваш завантажувальний диск зовсім не перелічено — зупиніться і виправте підключення/контролер/налаштування BIOS. Робота з завантажувачем не поверне відсутній диск.

Завдання 3: Визначте, як розбито диск (GPT чи MBR) і чи існує ESP

cr0x@server:~$ parted -l
Model: ATA INTEL SSDSC2KB (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  538MB  537MB  fat32              boot, esp
 2      538MB   539MB  1049kB                   bios_grub
 3      539MB   480GB  479GB

Model: ATA INTEL SSDSC2KB (scsi)
Disk /dev/sdb: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  538MB  537MB  fat32              boot, esp
 2      538MB   539MB  1049kB                   bios_grub
 3      539MB   480GB  479GB

Значення: GPT-диски з позначками esp і bios_grub поширені в інсталяціях Proxmox, які прагнуть гнучкості. Для UEFI найважливіший прапор — ESP.

Рішення: Якщо немає ESP (boot, esp), а сервер в UEFI-режимі — ви знайшли невідповідність.

Завдання 4: Перевірте цілісність файлової системи ESP (це FAT; ставтесь до нього як 1998 року)

cr0x@server:~$ fsck.vfat -n /dev/sda1
fsck.fat 4.2 (2021-01-31)
/dev/sda1: 12 files, 1646/130560 clusters

Значення: Перевірка в режимі читання пройшла; явних помилок FAT немає.

Рішення: Якщо бачите помилки FAT — плануйте ремонт (-a) або відтворення ESP та перевстановлення EFI-файлів.

Завдання 5: Змонтуйте ESP і перевірте наявність EFI-бінарників

cr0x@server:~$ mkdir -p /mnt/esp && mount /dev/sda1 /mnt/esp && find /mnt/esp/EFI -maxdepth 2 -type f | sed -n '1,10p'
/mnt/esp/EFI/BOOT/BOOTX64.EFI
/mnt/esp/EFI/proxmox/grubx64.efi
/mnt/esp/EFI/debian/grubx64.efi

Значення: Файли існують; є запасний шлях EFI/BOOT/BOOTX64.EFI і каталоги постачальників.

Рішення: Якщо /mnt/esp/EFI порожній або відсутній — перевстановіть завантажувач і розгляньте створення запасного шляху.

Завдання 6: Перегляньте записи завантаження UEFI NVRAM (список закладок прошивки)

cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0002,0001,0000
Boot0000* UEFI: PXE IPv4 Intel(R) I350
Boot0001* UEFI: Built-in EFI Shell
Boot0002* proxmox	HD(1,GPT,2b0c3f1a-9b2f-4a7e-9d64-3f3c3a0e2f21,0x800,0x100000)/File(\EFI\proxmox\grubx64.efi)

Значення: Є запис Proxmox і він перший. Чудово — якщо тільки він не вказує на неправильний диск/UUID розділу.

Рішення: Якщо запису Proxmox немає або він вказує на мертвий диск — створіть його заново за допомогою efibootmgr після перевірки правильного ESP.

Завдання 7: Імпортуйте ZFS-пул з середовища відновлення і підтвердіть його придатність для завантаження

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

	rpool        ONLINE
	  mirror-0    ONLINE
	    sda3      ONLINE
	    sdb3      ONLINE

Значення: Кореневий пул існує і його можна імпортувати.

Рішення: Якщо пул DEGRADED, ви часто все ще можете завантажитись, але слід використати ремонти завантаження як нагоду відновити резервність.

Завдання 8: Змонтуйте встановлену систему і підготуйте chroot

cr0x@server:~$ zpool import -R /mnt rpool
cr0x@server:~$ zfs mount -a
cr0x@server:~$ mount | grep -E '(/mnt|rpool)' | sed -n '1,8p'
rpool/ROOT/pve-1 on /mnt type zfs (rw,relatime,xattr,posixacl)
rpool/data on /mnt/rpool/data type zfs (rw,relatime,xattr,posixacl)

Значення: Ваш кореневий датасет змонтовано у /mnt.

Рішення: Якщо монтування не вдається — не продовжуйте з перевстановленням GRUB. Спочатку виправте імпорт/монтування ZFS.

Завдання 9: Прив’яжіть runtime-файлові системи і зайдіть у chroot

cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do mount --bind $i /mnt$i; done
cr0x@server:~$ chroot /mnt /bin/bash
root@server:/# cat /etc/os-release | head -2
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"

Значення: Ви в середині встановленого ОС; інструменти завантажувача поведуться коректно.

Рішення: Якщо chroot не вдається через відсутні бінарники — ваш кореневий FS не той, що ви думаєте.

Завдання 10 (UEFI): Переконайтесь, що ESP змонтовано в /boot/efi і перевстановіть GRUB EFI

root@server:/# mkdir -p /boot/efi
root@server:/# mount /dev/sda1 /boot/efi
root@server:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=proxmox
Installing for x86_64-efi platform.
Installation finished. No error reported.

Значення: GRUB EFI-бінарники встановлено в ESP під міткою proxmox.

Рішення: Якщо помилка про «EFI variables not supported» — ймовірно, ви завантажили середовище відновлення в BIOS-режимі. Перезавантажте образ у UEFI.

Завдання 11 (UEFI): Перегенеруйте меню GRUB і initramfs

root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-2-pve
Found initrd image: /boot/initrd.img-6.8.12-2-pve
done
root@server:/# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-2-pve

Значення: Меню завантаження вказує на реальні ядра; initramfs перебудовано.

Рішення: Якщо ядра не знайдено — можливо, ви в chroot у неправильному кореневому датасеті або /boot не змонтовано правильно.

Завдання 12 (UEFI): Відтворіть відсутній NVRAM-запис

root@server:/# efibootmgr -c -d /dev/sda -p 1 -L "proxmox" -l '\EFI\proxmox\grubx64.efi'
BootCurrent: 0002
BootOrder: 0002,0001,0000,0003
Boot0003* proxmox	HD(1,GPT,2b0c3f1a-9b2f-4a7e-9d64-3f3c3a0e2f21,0x800,0x100000)/File(\EFI\proxmox\grubx64.efi)

Значення: Створено новий запис. Він може ще не бути першим у порядку завантаження.

Рішення: Встановіть BootOrder так, щоб proxmox був першим, або покладіться на fallback-завантажувач як додатковий захист.

Завдання 13 (BIOS): Перевстановіть GRUB у MBR диска (або в область BIOS boot)

root@server:/# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-2-pve
Found initrd image: /boot/initrd.img-6.8.12-2-pve
done

Значення: Legacy GRUB встановлено на /dev/sda.

Рішення: Якщо у вас дзеркало — встановіть GRUB на кожен диск, з якого може відбуватись завантаження.

Завдання 14: Перевірте, що GRUB бачить правильний root і не посилається на /dev/sdX

root@server:/# grep -R "root=" /boot/grub/grub.cfg | sed -n '1,5p'
linux	/boot/vmlinuz-6.8.12-2-pve root=ZFS=rpool/ROOT/pve-1 ro quiet

Значення: Root вказано через ZFS-датасет, а не через нестабільні шляхи дисків.

Рішення: Якщо бачите root=/dev/sda3 на системах, де імена можуть змінюватись, виправте /etc/default/grub і перегенеруйте.

Завдання 15: Створіть запасний EFI-шлях (бо NVRAM не заслуговує довіри)

root@server:/# mkdir -p /boot/efi/EFI/BOOT
root@server:/# cp -f /boot/efi/EFI/proxmox/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
root@server:/# ls -l /boot/efi/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1536000 Dec 26 11:11 /boot/efi/EFI/BOOT/BOOTX64.EFI

Значення: Навіть якщо прошивка забуде записи NVRAM, вона часто може завантажити за замовчуванням із цього шляху.

Рішення: Зробіть це на кожному ESP, з якого ви очікуєте завантаження.

Завдання 16: Після перезавантаження підтвердіть, що система фактично завантажилась у запланованому режимі

cr0x@server:~$ dmesg | grep -i "efi\|UEFI" | sed -n '1,6p'
[    0.000000] efi: EFI v2.70 by American Megatrends
[    0.000000] efi: ACPI=0x9bfe6000 ACPI 2.0=0x9bfe6014 SMBIOS=0x9c01c000

Значення: Ядро бачить EFI; ви в UEFI-завантаженні.

Рішення: Якщо ви планували legacy-завантаження, а бачите EFI — знову ви у «змішаному режимі»; виправте це до наступного вікна технічного обслуговування.

UEFI проти BIOS: як обрати шлях відновлення

Найпростіше правило

Якщо машина підтримує UEFI (більшість підтримує), віддавайте перевагу UEFI для нових інсталяцій. Але не «конвертуйте» під час активного інциденту, якщо не хочете несподіваного простою. Відновлюйте в режимі, в якому було встановлено, а потім плануйте контрольовану міграцію за потреби.

Як Proxmox зазвичай розкладає речі

Proxmox VE базується на Debian. Інсталятор створює розділи для:

• ESP (зазвичай 512MB FAT32) при використанні UEFI.
• bios_grub маленький розділ (приблизно 1MB) при завантаженні BIOS з GPT, щоб GRUB мав куди вбудуватися.
• Кореневої файлової системи на ext4, LVM або ZFS (поширено у сучасних установках Proxmox).

Режими відмови UEFI, що виглядають як «диск не завантажувальний»

• ESP існує, але не використовується: порядок завантаження вказує на PXE або «UEFI: USB» вище за ваш диск.
• Запис NVRAM відсутній: прошивка забула запис Proxmox. Диск цілий; пам’ять прошивки — ні.
• Неправильний шлях диска в NVRAM: ви замінили дзеркальний диск, а запис завантаження все ще вказує на GUID старого диска.
• ESP лише на одному диску: ZFS-дзеркало зберігає дані, але у вас тільки одна ESP. Втратили цей диск — втратили завантаження.

Режими відмови BIOS, що виглядають як «диск не завантажувальний»

• GRUB встановлено на неправильний диск: система завантажується з першого диска в порядку BIOS, а GRUB знаходиться на другому.
• MBR перезаписано: операція клонування диска, інсталятор або «корисний» інструмент постачальника знищив boot-сектор.
• GPT без bios_grub: legacy-GRUB не може коректно вбудувати свій core image.

Жарт №2: BIOS вас не ненавидить. Він просто висловлює любов, ігноруючи ваші останні три зміни конфігурації.

Proxmox + ZFS: де резервність завантаження допомагає, а де ні

ZFS робить кореневе сховище надійним. Він не робить завантаження автоматично надійним. Ваш ZFS-дзеркал може спокійно зберігати ідеальні блоки, поки прошивка дивиться у порожній список NVRAM, ніби ніколи не бачила ваш сервер.

Що захищає ZFS

• Кореневі датасети, диски віртуальних машин на пулі, консистентність метаданих і виявлення тихої корупції.
• Оперативне відновлення: замініть збійний диск, проведіть resilver і продовжуйте роботу.

Чого ZFS не захищає

• ESP, якщо ви не створили ESP на кількох дисках і не синхронізуєте їх.
• Записи NVRAM UEFI, бо вони живуть у прошивці, а не на диску.
• Порядок завантаження прошивки, бо це налаштування прошивки і воно може скинутись у найгірший момент.

Що робити на дзеркальних дисках для завантаження

Якщо у вас два диски і ви хочете пережити втрату будь-якого з них, вам потрібні два завантажувальні шляхи:

• Дві ESP (по одній на диск) і план їх синхронізації.
• Записи UEFI для обох або надійний fallback-завантажувач у EFI/BOOT/BOOTX64.EFI на обох.
• Якщо завантажуєтесь у legacy BIOS: встановіть GRUB на обидва диски.

У Proxmox-середовищах практичний підхід простий: ESP на кожному диску + fallback-завантажувач + періодична перевірка відхилення. Усе інше — опціонально.

Типові помилки (симптом → корінь проблеми → виправлення)

1) Симптом: «Немає завантажувального пристрою» після оновлення прошивки

Корінь проблеми: записи NVRAM UEFI стерто або переставлено; PXE або «UEFI Shell» з’явились вище в порядку.

Виправлення: Зайдіть у налаштування прошивки й оберіть правильний запис UEFI. Якщо його немає — відтворіть через efibootmgr з середовища відновлення та скопіюйте fallback BOOTX64.EFI.

2) Симптом: Завантажується тільки при наявності конкретного диска (дзеркало існує, але один диск «особливий»)

Корінь проблеми: На одному диску є ESP або тільки на ньому встановлено GRUB.

Виправлення: Створіть ESP на іншому диску, змонтуйте його, встановіть GRUB EFI туди (або GRUB BIOS на диск), потім додайте запасний шлях.

3) Симптом: Під час ремонту з’являється «EFI variables are not supported»

Корінь проблеми: Ви завантажили середовище відновлення в BIOS-режимі, тому efivars недоступні.

Виправлення: Перезавантажте інсталятор/live ISO в UEFI-режимі і повторіть встановлення GRUB EFI.

4) Симптом: GRUB завантажується, а потім переходить у «grub rescue>»

Корінь проблеми: GRUB не може знайти свої модулі або конфіг через переміщені розділи, змінені UUID або /boot не там, де очікується.

Виправлення: З середовища відновлення зайдіть у chroot і повторіть grub-install + update-grub. Перевірте /etc/fstab і що ESP змонтовано правильно.

5) Симптом: «Не завантажувальний диск» відразу після додавання нового диска

Корінь проблеми: Порядок завантаження змінився; прошивка тепер намагається завантажитись з нового диска першою. Деякі HBA також перенумеровують диски.

Виправлення: Перенастройте порядок завантаження; відключіть можливість завантаження з небажаних дисків, якщо прошивка це дозволяє.

6) Симптом: Працює після ручного вибору завантаження, але падає при наступному перезавантаженні

Корінь проблеми: Прошивка зберігає одноразове перенаправлення, але не постійний порядок; або постійні налаштування не зберігаються через розряджену батарейку CMOS.

Виправлення: Задайте постійний порядок завантаження; перевірте журнали BIOS; замініть батарейку CMOS, якщо налаштування «пливуть».

7) Симптом: Після заміни диска система не завантажується, але ZFS-пул виглядає OK

Корінь проблеми: Новий диск не має ESP/завантажувача або запис NVRAM вказує на GUID старого диска.

Виправлення: Розмітьте новий диск правильно, створіть ESP, встановіть GRUB, оновіть efiboot записи і додайте fallback-завантажувач.

8) Симптом: Secure Boot скарги або «invalid signature»

Корінь проблеми: Secure Boot увімкнено, але ваш ланцюг завантаження не підписаний так, як цього очікує прошивка.

Виправлення: Вимкніть Secure Boot для типових розгортань Proxmox, якщо у вас немає керованого підписаного ланцюга завантаження.

Контрольні списки / покроковий план

Контрольний список A: Що зібрати перед тим, як щось змінювати

1. У якому режимі було встановлено вузол — UEFI чи BIOS?
2. Чи щось змінювалося? Оновлення прошивки, заміна диска, новий HBA, переміщення кабелю, подія живлення, віддалені роботи?
3. Чи є доступ до консолі (iKVM/IDRAC/iLO) або лише SSH (швидше за все, SSH у вас нема)?
4. Який макет сховища: ZFS дзеркало, ZFS RAIDZ, ext4, LVM-thin?
5. Який диск має бути завантажувальним? Ідентифікуйте за серійним номером, а не за /dev/sdX.

Контрольний список B: Мінімальне відновлення (UEFI)

1. Завантажте середовище відновлення в UEFI-режимі.
2. Підтвердіть видимість дисків через lsblk.
3. Перевірте наявність ESP та FAT32 за допомогою parted -l.
4. Імпортуйте ZFS-пул (якщо застосовно) і змонтуйте корінь у /mnt.
5. Прив’яжіть /dev, /proc, /sys, /run і зайдіть у chroot.
6. Змонтуйте ESP у /boot/efi.
7. Запустіть grub-install --target=x86_64-efi і update-grub.
8. Створіть/перевірте NVRAM-запис за допомогою efibootmgr.
9. Скопіюйте fallback-завантажувач у EFI/BOOT/BOOTX64.EFI.
10. Перезавантажте й перевірте режим завантаження через dmesg.

Контрольний список C: Мінімальне відновлення (legacy BIOS)

1. Завантажте середовище відновлення (режим тут менш критичний, але будьте послідовні).
2. Підтвердіть наявність дисків і розмітку; якщо GPT — переконайтесь у наявності bios_grub.
3. Змонтуйте корінь (або імпортуйте ZFS) і зайдіть у chroot.
4. Запустіть grub-install /dev/sdX на правильний диск.
5. Запустіть update-grub.
6. Якщо є дзеркало — повторіть grub-install на інших дисках.
7. Встановіть порядок завантаження BIOS на диск, який фактично має GRUB.

Контрольний список D: Закріплення після відновлення (зробіть це, поки ще свіжі враження)

1. Забезпечте резервність ESP на дзеркальних завантажувальних дисках.
2. Запишіть режим прошивки та потрібні налаштування BIOS у runbook.
3. Вимкніть завантаження з даних дисків і випадкових носіїв у прошивці.
4. Після будь-якої заміни диска перевстановлюйте завантажувач на новий диск як частину процедури.
5. Додайте періодичне завдання «аудит ланцюга завантаження» (вміст ESP + вивід efibootmgr + статус grub-install).

Три корпоративні міні-історії з полів бою завантаження

Міні-історія 1: Інцидент через неправильне припущення

У них був кластер Proxmox, де кожний вузол був «ідентичний». «Ідентичний» — небезпечне слово в продакшені, бо воно заохочує людей перестати дивитися. Один вузол відмовився завантажитись після планового простою: «не завантажувальний диск». На чергового випало припущення про відмову диска і відкрили заявку на заміну. Розумний крок, але диски були в порядку.

Справжня причина була в скиданні прошивки під час обслуговування. Сервер перемкнувся з legacy BIOS на UEFI-first, а система була встановлена в legacy. Диски були GPT з BIOS boot розділом, і GRUB був правильно встановлений для i386-pc. Але прошивка шукала EFI-бінарники на ESP, якого не існувало.

Відновлення було майже образливо просте: повернули прошивку в legacy, перезавантажили — і вузол ожив. «Інцидент» не був корупцією сховища чи оновленням ОС. Це була невідповідність налаштувань, створена припущенням, що «UEFI скрізь ввімкнено».

Після цього змінились не технології, а процеси. Вони додали односторінковий профіль апаратури для кожного вузла: режим завантаження, стан Secure Boot, режим RAID/HBA і серійний номер очікуваного завантажувального диска. Це не було гламурно. Це також запобігло повторенню.

Міні-історія 2: Оптимізація, що відгукнулась боком

Інша команда хотіла швидше завантажуватись після оновлень ядра. Вони вирізали те, що вважали «зайвим» у завантаженні. ESP зменшили до мінімуму і видалили fallback EFI-файли, бо «в нас є коректний NVRAM-запис». Вони також стандартизували одну ESP на першому диску ZFS-дзеркала, бо підтримувати дві здавалося «марнотратством».

Потім один диск відмовив. ZFS зробив свою роботу; пул залишився онлайн. Вони замінили диск, resilver завершився, і запланували перезавантаження для перевірки. Під час перезавантаження прошивка спробувала завантажитись із залишеного диска (тепер першого в очах прошивки) і не знайшла дійсного EFI-шляху. Єдина ESP була на вилученому диску. Запасний шлях був видалений під час оптимізації.

Простий простій не став катастрофою, але був непотрібним і дратівливим. Більшість часу витратили на організацію доступу консолі та демонтованих носіїв, а не на програмні виправлення. Виправленням стала стратегія дзеркальної ESP і відновлення стандартного fallback-бінарника.

Урок не в «ніколи не оптимізуйте». Урок у тому, що стійкість завантаження — це властивість системи, а не лише диска. Резервність ZFS не покриває амнезію прошивки або відсутність завантажувальних артефактів на живому диску.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Одне підприємство дотримувалось рутинної практики: після будь-якої заміни диска на хості Proxmox процедура включала перевстановлення завантажувачів і перевірку обох шляхів завантаження. Кожного разу. Це була такий крок, що люди закочували очі — поки він не «оплатив оренду».

Одного вихідного дня вузол втратив живлення, потім відмовився завантажитись. Консоль показувала, як прошивка сканує диски і здається. Черговий дотримався playbook: перевірити UEFI-режим, інспектувати ESP на обох дисках і перевірити efibootmgr. Записи NVRAM були втрачені, ймовірно через глюк при відновленні живлення.

Зазвичай це означало б ручне відновлення записів. Але їхня нудна практика включала копіювання fallback-завантажувача до EFI/BOOT/BOOTX64.EFI на обох ESP. Прошивка, забувши все інше, знала лише стандартний шлях. Система завантажилась без втручання в NVRAM.

Після цього вони відновили нормальні записи. Ключовий момент: відновлення відбулося швидко, без особливого доступу і без вгадувань. Це не було героїзмом. Це була рутина, яка зробила систему менш драматичною.

Поширені запитання

1) Чи зазвичай «не завантажувальний диск» означає мертвий диск?

Ні. Мертві диски трапляються, але частіше насправді причина — порядок завантаження або невідповідність режиму прошивки. Спочатку підтвердіть виявлення диска, потім режим завантаження.

2) Чи можна виправити це перевстановленням Proxmox?

Можна, але не слід. Перевстановлення — це грубий інструмент, який ризикує зруйнувати сховище або порушити очікування кластера. Спочатку відновіть завантаження; це швидше і безпечніше при обережних діях.

3) Як дізнатися, чи Proxmox був встановлений у UEFI-режимі?

Якщо встановлена система має /sys/firmware/efi під час запуску — вона завантажувалась через UEFI. На диску шукайте ESP (FAT32, з прапором esp).

4) Чому заміна диска в ZFS-дзеркалі ламає завантаження?

ZFS дзеркалить ваші дані, але не автоматично ESP або записи прошивки. Якщо ESP або завантажувач були тільки на вилученому диску — залишній диск сам по собі не завантажиться.

5) Чи потрібні і ESP, і bios_grub?

Не завжди. UEFI потребує ESP. Legacy BIOS при роботі з GPT виграє від наявності bios_grub. Деякі інсталятори створюють обидва для гнучкості. Головне: активний режим завантаження повинен мати потрібні компоненти.

6) Який найшвидший спосіб «хоч би щось завантажити», якщо записи NVRAM зламані?

Створіть fallback-шлях EFI/BOOT/BOOTX64.EFI на ESP. Багато реалізацій прошивки завантажать його навіть при порожніх NVRAM.

7) Чи варто вмикати Secure Boot на Proxmox?

Якщо у вас немає протестованого підписаного ланцюга завантаження — Secure Boot часто призводить до збоїв під час оновлень або ремонтів. Багато розгортань Proxmox навмисно його вимикають.

8) Чому grub-install каже «EFI variables are not supported»?

Бо ви не завантажені в UEFI-режимі (або efivars недоступні). Завантажте середовище відновлення в UEFI, щоб /sys/firmware/efi існував, і спробуйте знову.

9) Чи треба перевстановлювати GRUB після кожного оновлення ядра?

Зазвичай ні. Оновлення ядра автоматично регенерує конфігурацію GRUB і initramfs. Перевстановлюйте GRUB при зміні дисків, відновленні ESP або відсутності файлів завантажувача.

10) Чи можна зберегти стабільні записи завантаження при зміні апаратури?

Частину стабільності дає використання правильних GUID розділів і синхронність ESP, але поведінка прошивки різниться. Саме тому fallback-завантажувачі та резервні ESP — практичні рішення.

Висновок: практичні наступні кроки

Якщо ви бачите «не завантажувальний диск», розглядайте це як інцидент на межі прошивки/завантаження, а не як привід перевстановити ОС. Почніть з режиму і порядку завантаження. Потім перевірте розділи і вміст ESP. Лише після цього перевстановлюйте GRUB або відтворюйте записи EFI. Така послідовність уникне двох класичних втрат часу: ремонту неправильного шару та «виправлення» системи в інший режим завантаження ненавмисно.

Після повернення в робочий стан зробіть нудне закріплення: зробіть ESP резервними на дзеркальних дисках, скопіюйте fallback-EFI-завантажувач і задокументуйте очікувані налаштування прошивки для кожного вузла. Наступний перезавантаження має пройти нудно — продакшн любить нудне.