Proxmox не завантажується після оновлення ядра: правильне відкатування через GRUB

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

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

Перше: визначте тип відмови (секунди, не хвилини)

• Немає меню GRUB / прямо в прошивку: ймовірно, проблема з EFI boot entry/ESP або змінився порядок завантаження.
• GRUB з’являється, є вибір ядра: добре. Спочатку відкотіться до попереднього ядра.
• Ядро завантажується, потім panic / зависання: зазвичай відсутні модулі в initramfs, невідповідність драйверів DKMS або не знайдено кореневу файлову систему.
• Завантажується до аварійної оболонки: невдача монтування кореневого FS, неімпортований ZFS, або неправильні параметри ядра.
• Чорний екран після GRUB: часто проблеми з передачею консолі GPU або framebuffer; система все ще може завантажуватися — перевірте активність дисків або ping з іншої машини.

Друге: оберіть найменш інвазивний шлях відновлення

1. Використайте GRUB, щоб завантажити старіше ядро (швидко, відновлювано, зберігає систему цілою).
2. Відредагуйте запис GRUB для додавання тимчасового параметра (наприклад debug або nomodeset), якщо потрібно.
3. Завантажувальні rescue‑носії лише якщо GRUB не може завантажити нічого або відсутній ESP.

Третє: вирішіть, що треба зберегти

Перш ніж «очищати старі ядра» або перевстановлювати щось, вирішіть, що важливо:

• Чи потрібно зберегти пошкоджене ядро для подальшого дебагу? Зазвичай так — принаймні до стабілізації вузла.
• Чи ви на ZFS root? Тоді initramfs і ZFS модулі слід розглядати як пов’язану систему.
• Чи ви використовуєте vendor DKMS модулі (HBA драйвери, out‑of‑tree NIC драйвери)? Очікуйте проблем при їх перебудові.

Операційне правило: ваша перша мета при завантаженні — отримати стабільну консоль + стабільне сховище + стабільну мережу. Proxmox UI почекає.

Що фактично зламалось, коли Proxmox не завантажується

Оновлення ядра не просто замінює vmlinuz. Воно оновлює сімейство щільно пов’язаних компонентів: образ ядра, initramfs, модулі під /lib/modules, DKMS‑збірки драйверів, записи меню завантажувача і іноді мікрокод та EFI‑біти. Будь‑який з цих елементів може зіпсувати вам ранкову каву.

Типові режими відмови після оновлення ядра

• Нове ядро завантажується, але не знаходить root filesystem: відсутній драйвер сховища або модуль ZFS не включено в initramfs; неправильний root=; пошкоджена генерація initramfs.
• Kernel panic на ранній стадії завантаження: часто невідповідність модулів/ABI, пошкоджений initramfs або невдала DKMS збірка.
• Меню GRUB є, але показане тільки нове ядро: старі ядра видалено, або /boot не оновлено, або конфіг GRUB не перегенеровано.
• UEFI переходить у прошивку / “No bootable device”: ESP не змонтовано під час оновлення, або запис UEFI в NVRAM втрачено.
• Бут‑лупи: watchdog‑перезавантаження, panic з автоматичним рестартом або systemd, що падає з kernel: panic і миттєвим рестартом.
• Система завантажується, але служби Proxmox падають: не помилка завантаження, але нестабільність після оновлення (corosync, pveproxy, точки монтування сховищ).

Трохи неприємна правда: відкат через GRUB виправляє симптоми, а не причини. Але це дає вам чисте середовище для виправлення причини без операцій в оболонці initramfs.

Цікаві факти й історичний контекст (бо це допомагає приймати рішення)

1. GRUB 2 став дефолтним у Debian роки тому, головно через його кращу підтримку складних сценаріїв завантаження (LVM, RAID, декілька ядер) у порівнянні зі старим GRUB.
2. Proxmox ґрунтується на Debian, отже більшість «проблем завантаження Proxmox» — це класичні проблеми Debian: ядро + initramfs + завантажувач у PVE‑обгортці.
3. Initramfs — це не театральний атрибут: це невелика файлова система в RAM, що потрібна для підключення сховища та root. Якщо в ній немає потрібних драйверів, ядро не дістане root.
4. DKMS існує, щоб перебудовувати драйвери під нові ядра. Коли воно падає, ви можете отримати ядро, що завантажується, але без NIC або ще гірше — без контролера сховища.
5. ZFS on Linux — out‑of‑tree, тобто чутливий до змін ABI ядра. Нова версія ядра без відповідного ZFS модуля = “root pool not found”.
6. UEFI зробив завантаження гнучкішим і крихкішим: ESP, NVRAM boot entries та різні реалізації від постачальників додають поверхні для відмов.
7. Linux зберігає кілька встановлених ядер за замовчуванням, аби ви могли відкотитися. Люди саботують цю подушку безпеки агресивним видаленням «невикористованих» ядер.
8. Пакети ядра Proxmox (pve-kernel) налаштовані для віртуалізації; міксування ядер з випадкових репозиторіїв призводить до сюрпризів.

Трохи сухий утіш: ця відмова настільки поширена, що кроки відновлення переважно нудні. А нудне — добре у production.

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

Відкат через GRUB (BIOS і UEFI) без ускладнень

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

Крок 1: потрапити в меню GRUB надійно

На багатьох системах меню GRUB приховане, якщо нічого не пішло не так. Коли вже щось пішло не так, часто доводиться натиснути швидко.

• BIOS: натисніть і утримуйте Shift під час завантаження.
• UEFI: натискайте Esc (іноді Shift) під час завантаження.
• Дистанційний IPMI/iKVM: надсилайте натискання клавіш раніше; деякі консолі мають поганий буфер.

Крок 2: вибрати старіше ядро безпечно

У GRUB:

1. Виберіть Advanced options for Debian GNU/Linux (на Proxmox він може все ще називатися Debian).
2. Виберіть попередню версію ядра (зазвичай та, що нижче найновішої).
3. Віддавайте перевагу звичайному запису, а не “recovery mode”, якщо звичайний запуск не падає.

Яке ядро обрати? На практиці: найновіше ядро, яке раніше працювало. Якщо ви оновили з 6.5 до 6.8 і 6.8 падає — оберіть 6.5. Не відскакуйте назад на кілька великих релізів без крайньої потреби; старіші ядра можуть не відповідати сучасним userspace‑асумпціям, а ваша мета — стабілізація, не подорож у часі.

Крок 3: коли вибору ядра замало

Якщо екран чорний або підозрюєте проблему з графікою консолі, спробуйте тимчасовий параметр. У GRUB виділіть запис ядра, натисніть e, знайдіть рядок, що починається з linux, додайте параметри, потім завантажтеся Ctrl+x або F10.

Корисні тимчасові параметри:

• nomodeset (проблеми передавання відеодрайвера; часто на дивних GPU)
• systemd.unit=multi-user.target (пропустити графічні таргети; зазвичай не критично для серверів Proxmox, але може допомогти)
• debug або loglevel=7 (більше подробиць ядра)
• panic=30 (затримка перезавантаження при panic; дає час прочитати помилку)

Не «ремонтуйте» GRUB з редактора GRUB далі ніж тимчасові параметри. Якщо ви можете завантажитися старим ядром, робіть реальні виправлення з працюючої системи.

Крок 4: зробити старе ядро дефолтним (тимчасово)

Після успішного завантаження ви можете зафіксувати дефолтне ядро, налаштувавши GRUB default menu entry. Це запобіжить випадковим перезавантаженням у зламане ядро під час роботи. Робиться це з ОС, а не з меню прошивки.

Після завантаження: підтвердити, стабілізувати і запобігти повторенню

Завантаження — це не «виправлено». Завантаження означає «можемо знову дихати». Тепер треба зрозуміти, чому нове ядро впало, і вирішити, чи ремонтувати його, тримати заблокованим або видалити.

Ось ментальна модель, що не дозволяє плутатися:

• Якщо нове ядро панікує на початку: перевірте вміст initramfs, відсутні модулі, доступність ZFS, питання з мікрокодом.
• Якщо завантажується, але немає мережі: перебудова DKMS, пакети firmware, перейменовані інтерфейси або регрес драйвера.
• Якщо завантажується, але не імпортує ZFS: невідповідність ZFS‑модуля, initramfs без ZFS або проблеми з pool feature flags.
• Якщо проблема в GRUB/UEFI: mount ESP, grub-install (BIOS) або відновлення EFI entry (UEFI) і перевірки.

Також: якщо це кластерний Proxmox, тримайте вузол у статусі «out of service» до стабілізації. Напівпрацюючий вузол може завдати більше шкоди, ніж вимкнений, особливо якщо він буде флапати членство corosync або монтування сховищ.

Жарт №2: Нічого так не згуртовує команду, як мовчазне спостереження за сервером при завантаженні — немов це театральна вистава.

Цитата, що тримає вас чесним

«Hope is not a strategy.» — General Gordon R. Sullivan

В термінах SRE: зробіть відкат детермінованим, потім зробіть подальший шлях нудним.

ZFS root та нюанси сховища під час відкату ядра

Якщо ваш Proxmox хост завантажується з ZFS, оновлення ядра може провалюватися специфічним шляхом: ядро стартує, initramfs завантажується, але не може імпортувати rpool, бо модуль ZFS недоступний (або не відповідає ядру). Це дає помилки на кшталт «cannot import ‘rpool’: no such pool available» або «ZFS: module not found», після чого ви потрапляєте в аварійну оболонку.

Чому ZFS ускладнює ситуацію

• ZFS не вбудований у дерево Linux kernel; це окремий модуль. Тому його потрібно збирати під кожне ядро.
• На ZFS root initramfs має містити ZFS‑компоненти, щоб імпортувати pool на ранній стадії завантаження.
• Пакети Proxmox зазвичай це враховують, але часткові оновлення, зламані DKMS‑збірки або незмонтований ESP можуть створити сценарії «ядро оновлено, initramfs фактично не оновлено».

Безпечний підхід

Завантажтеся з останнього відомого робочого ядра. Підтвердіть, що pool імпортується й набори даних монтуються. Потім виправте зламане ядро, перебудувавши initramfs і переконавшись, що ZFS‑модулі існують для нього. Лише після цього дозволяйте системі завантажитись у нове ядро.

Якщо ви на ZFS root і агресивно чистите старі ядра, ви можете себе загнати в пастку: останнім залишиться ядро, яке потребує ZFS‑модулів, що ніколи не були збудовані. Ось як 10‑хвилинний відкат перетворюється на післяобідню операцію з завантаження з ISO та chroot.

Практичні завдання (команди, значення виводу, рішення)

Нижче справжні завдання, які ви можете виконати після успішного завантаження (зазвичай через старіше ядро). Кожне містить: команду, що означає її вивід, і рішення, яке слід прийняти.

Завдання 1: підтвердити, яке ядро ви фактично завантажили

cr0x@server:~$ uname -r
6.5.13-5-pve

Значення: Зараз запущено 6.5.13-5-pve.

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

Завдання 2: перелік встановлених Proxmox ядер

cr0x@server:~$ dpkg -l 'pve-kernel-*' | awk '/^ii/ {print $2, $3}'
pve-kernel-6.5.13-5-pve 6.5.13-5
pve-kernel-6.8.12-3-pve 6.8.12-3

Значення: І старе, і нове ядро встановлені.

Рішення: Якщо встановлене лише зламане ядро — зупиніться і подумайте про встановлення відомо‑працюючого пакета ядра перед подальшими діями (можливо через chroot/rescue, якщо не вдається завантажитися).

Завдання 3: перевірити останні журнали завантаження, щоб дізнатися, чому нове ядро впало

cr0x@server:~$ journalctl -b -1 -p err --no-pager | tail -n 30
Dec 26 10:02:11 server kernel: zfs: module verification failed: signature and/or required key missing
Dec 26 10:02:11 server kernel: ZFS: Failed to load module
Dec 26 10:02:12 server systemd[1]: Failed to mount /.
Dec 26 10:02:12 server systemd[1]: Dependency failed for Initrd Root File System.

Значення: Попередній запуск (-1) мав помилку завантаження модуля ZFS, тому монтування root не відбулося.

Рішення: Це вказує на Secure Boot/підпис модулів, помилку збірки DKMS або відсутність ZFS в initramfs. Розбирайтеся саме з цими причинами, а не перевстановлюйте GRUB навмання.

Завдання 4: перевірити, чи ввімкнено Secure Boot

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Значення: UEFI Secure Boot увімкнено.

Рішення: Якщо out‑of‑tree модулі (ZFS, драйвери постачальника) не підписані, вони можуть не завантажитися. Або підпишіть модулі / зареєструйте ключі, або вимкніть Secure Boot (політичне рішення). Не вимикайте просто так, якщо в організації це вимога.

Завдання 5: перевірити наявність образів initramfs для кожного ядра

cr0x@server:~$ ls -lh /boot | egrep 'vmlinuz|initrd.img' | tail -n 10
-rw-r--r-- 1 root root  78M Dec 25 21:14 initrd.img-6.5.13-5-pve
-rw-r--r-- 1 root root  82M Dec 25 21:16 initrd.img-6.8.12-3-pve
-rw-r--r-- 1 root root 8.6M Dec 25 21:14 vmlinuz-6.5.13-5-pve
-rw-r--r-- 1 root root 9.1M Dec 25 21:16 vmlinuz-6.8.12-3-pve

Значення: Обидва ядра мають initramfs і vmlinuz.

Рішення: Наявність не гарантує коректність, але відсутність — одразу червоний прапорець: перебудуйте initramfs і переконайтеся, що /boot змонтовано правильно.

Завдання 6: підтвердити, що /boot і EFI System Partition змонтовані (UEFI)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE /boot /boot/efi
/boot /dev/sda2 ext4
/boot/efi /dev/sda1 vfat

Значення: І /boot, і /boot/efi змонтовані.

Рішення: Якщо /boot/efi не змонтовано під час оновлень, GRUB EFI бінарники та NVRAM записи можуть розсинхронізуватися. Виправте точки монтування перед повторним запуском update-grub або перевстановленням компонентів завантажувача.

Завдання 7: перебудувати initramfs для зламаного ядра

cr0x@server:~$ sudo update-initramfs -u -k 6.8.12-3-pve
update-initramfs: Generating /boot/initrd.img-6.8.12-3-pve
Running hook script 'zz-proxmox-boot'..

Значення: Initramfs перегенеровано для вказаного ядра.

Рішення: Якщо це провалиться через відсутні модулі або помилки в hook‑скриптах, зупиніться і виправте їх перед перезавантаженням. Успішна генерація initramfs необхідна, але не достатня — далі перевірте наявність модулів.

Завдання 8: перевірити наявність ZFS‑модуля для цільового ядра

cr0x@server:~$ ls /lib/modules/6.8.12-3-pve/updates/dkms/ 2>/dev/null | head
zfs.ko
zcommon.ko
znvpair.ko
zunicode.ko
zavl.ko

Значення: DKMS‑збудовані модулі ZFS існують для нового ядра.

Рішення: Якщо ця директорія відсутня або порожня, ZFS не збудувався для нового ядра. Перегляньте статус DKMS і логи збірки.

Завдання 9: перевірити статус DKMS і перебудувати за потреби

cr0x@server:~$ dkms status
zfs/2.2.4, 6.5.13-5-pve, x86_64: installed
zfs/2.2.4, 6.8.12-3-pve, x86_64: built

Значення: Для нового ядра ZFS тільки “built”, а не “installed” (або може зовсім відсутній).

Рішення: Встановіть його для цього ядра або перебудуйте. Стан “built” може означати, що модуль не поміщено у правильну дерево.

cr0x@server:~$ sudo dkms install zfs/2.2.4 -k 6.8.12-3-pve
Installing to /lib/modules/6.8.12-3-pve/updates/dkms/
depmod...

Значення: DKMS встановив ZFS у дерево модуля нового ядра і запустив depmod.

Рішення: Перебудуйте initramfs знову, щоб initramfs містив потрібні компоненти.

Завдання 10: перебудувати записи меню GRUB

cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-3-pve
Found initrd image: /boot/initrd.img-6.8.12-3-pve
Found linux image: /boot/vmlinuz-6.5.13-5-pve
Found initrd image: /boot/initrd.img-6.5.13-5-pve
done

Значення: Конфіг GRUB тепер містить обидва ядра.

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

Завдання 11: встановити дефолтний запис ядра (тимчасова фіксація)

Спочатку перелічте записи меню з індексами:

cr0x@server:~$ grep -n "menuentry '" /boot/grub/grub.cfg | head -n 8
105:menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-11111111-2222-3333-4444-555555555555' {
153:menuentry 'Advanced options for Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-advanced-11111111-2222-3333-4444-555555555555' {
161:menuentry 'Debian GNU/Linux, with Linux 6.8.12-3-pve' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.8.12-3-pve-advanced-11111111-2222-3333-4444-555555555555' {
199:menuentry 'Debian GNU/Linux, with Linux 6.5.13-5-pve' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.5.13-5-pve-advanced-11111111-2222-3333-4444-555555555555' {

Значення: Ви можете посилатися на menuentry за точним заголовком або за ID. Заголовки можуть змінюватися; ID стабільніші.

Рішення: Використайте механізм «saved» GRUB для передбачуваних завантажень, потім встановіть saved entry на відоме робоче ядро.

cr0x@server:~$ sudo sed -i 's/^GRUB_DEFAULT=.*/GRUB_DEFAULT=saved/' /etc/default/grub
cr0x@server:~$ sudo grub-set-default "Debian GNU/Linux, with Linux 6.5.13-5-pve"
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
done

Значення: GRUB за замовчуванням буде завантажувати ядро 6.5 до зміни налаштувань.

Рішення: Тримайте фіксацію доти, доки нове ядро не перевірите у контрольованому вікні перезавантаження.

Завдання 12: перевірити запущені служби та стан кластера (якщо є)

cr0x@server:~$ systemctl --failed --no-pager
UNIT                     LOAD   ACTIVE SUB    DESCRIPTION
0 loaded units listed.

Значення: Немає неуспішних systemd‑юнітів.

Рішення: Якщо бачите юніти, що впали, пов’язані зі сховищем, мережею або pve‑сервісами, виправте їх перед поверненням вузла до робочих навантажень.

cr0x@server:~$ pvecm status 2>/dev/null | egrep 'Quorate|Nodes|Name'
Name:             prod-cluster
Nodes:            3
Quorate:          Yes

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

Рішення: Якщо вузол ізольований або викликає флапи членства, тримайте його поза сервісом і розслідуйте мережу, конфіг corosync та синхронізацію часу перед подальшими діями.

Завдання 13: підтвердити здоров’я ZFS pool (ZFS root або дата‑пули)

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:09:12 with 0 errors on Sun Dec 22 02:10:12 2025
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda3    ONLINE       0     0     0
            sdb3    ONLINE       0     0     0

errors: No known data errors

Значення: Сховище здорове.

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

Завдання 14: перевірити EFI boot entries, якщо прошивка кидає в налаштування

cr0x@server:~$ sudo efibootmgr -v | head -n 20
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI: Built-in EFI Shell
Boot0002* UEFI PXE IPv4
Boot0003* debian	HD(1,GPT,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,0x800,0x32000)/File(\EFI\debian\grubx64.efi)

Значення: Є валідний Debian/GRUB EFI запис, що вказує на \EFI\debian\grubx64.efi.

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

Завдання 15: перевірити вміст ESP (UEFI)

cr0x@server:~$ sudo ls -R /boot/efi/EFI | head -n 40
/boot/efi/EFI:
BOOT
debian
proxmox

/boot/efi/EFI/debian:
grub.cfg
grubx64.efi
shimx64.efi

Значення: Файли EFI існують. Наявність shimx64.efi часто вказує на підтримку Secure Boot.

Рішення: Якщо директорія порожня або відсутня, ваш ESP не змонтовано під час оновлень або він був перезаписаний. Потрібно перевстановити GRUB EFI бінарники і, можливо, відновити NVRAM записи.

Завдання 16: перевірити вільне місце на /boot (потенційно фатально)

cr0x@server:~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       512M  489M   23M  96% /boot

Значення: /boot майже заповнено.

Рішення: Повний /boot може призвести до неповних записів initramfs або відсутніх образів. Можливо, потрібно видалити старі ядра — але тільки після перевірки, що у вас є принаймні один відомо‑робочий fallback, встановлений і завантажуваний.

Три корпоративні міні‑історії з полів

1) Інцидент, спричинений хибним припущенням

Вузол був звичайним Proxmox‑гіпервайзером. ZFS root, кілька NVMe mirror‑ів і невелика група критичних VM, які колись вважали «некритичними», поки вони не впали. Команда мала звичку: застосувати оновлення ввечері, перезавантажитись і йти додому. Зазвичай це працювало. «Зазвичай» — не стратегія.

В один цикл оновлень вузол не повернувся. IPMI показав kernel panic на ранньому етапі завантаження. Хтось припустив, що «GRUB має бути пошкоджений», бо це найпопулярніша історія з 2012 року. Вони завантажили rescue‑носій, перевстановили GRUB і перезавантажились. Та сама panic. Потім перевстановили GRUB знову, бо повторення — в деяких галузях визнана техніка налагодження.

Справжня проблема була простішою: initramfs для нового ядра не містив драйвер сховища для HBA, що давав доступ до boot pool. Модуль існував на диску, але він не потрапив у initramfs через помилку hook під час оновлення — спричинену майже повним /boot. Старе ядро завантажувалося нормально. Нове не могло знайти root. GRUB був невинний.

Після відкату через GRUB до попереднього ядра виправлення зайняло 15 хвилин: звільнити місце в /boot, перегенерувати initramfs, перевірити наявність модулів і перезавантажити в нове ядро. Урок не в «не оновлюйте». Урок у тому, щоб не припускати, що винний завантажувач, лише тому що ви його бачите.

2) Оптимізація, що зіграла злий жарт

Інше середовище мало жорстоку культуру «тримати в чистоті». Вони запустили cron‑задачу, яка видаляла старі ядра, щоб звільняти місце в /boot. Хтось побачив попередження про використання /boot і вирішив, що постійне вирішення — видаляти «невикористані» ядра. Це розгорнули скрізь. Це стало «стандартом». Ніхто не пам’ятав, хто це написав.

Потім прийшло оновлення ядра, що внесло регрес драйвера для основного NIC. Система завантажилася, але без мережі. Це було б неприємно, але відновлювано через консоль — якби процес remote hands дата‑центру не вимагав мережі для доступу в management plane. Їхнє OOB теж було залежне від тієї ж мережі та політики. Вражаюче.

Відкат був би тривіальним, якби в GRUB було старіше ядро. Його не було. Потрібно було завантажитися з rescue, змонтувати файлові системи, встановити старе ядро з локальних mirror‑ів, перебудувати initramfs і перезавантажитися. Все вдалося, але це забрало години й увагу кількох команд — бо процедуру ніколи не відпрацьовували.

Після розборів cron‑задачу жорстко розкритикували. /boot утримують під контролем з правилом: завжди тримати принаймні два відомо‑робочих ядра і сповіщати при заповненні /boot, а не бездумно чистити вашу парашутну подушку.

3) Сумно, але правильна практика, що врятувала ситуацію

Та сама категорія відмов: після оновлення ядра хост завантажився в аварійну оболонку initramfs з повідомленням «cannot mount root». Різниця була в дисципліні команди. Вони не пхалися випадковими командами. Вони дотримувалися невеликого runbook і ставилися до консолі як до доказу.

Спочатку сфотографували екран і зафіксували точну помилку. Потім перезавантажилися і через GRUB обрали попереднє ядро. Воно завантажилося. Негайно зафіксували старе ядро як default у GRUB, щоб уникнути випадкового переходу на зламане, і перевели вузол у maintenance‑режим, щоб туди не потрапляли нові навантаження.

Потім виконали нудну, але правильну роботу: перевірили, що /boot і /boot/efi змонтовані, перевірили вільне місце, статус DKMS, перебудували initramfs для нового ядра і переконалися, що ZFS‑модулі існують для цього ядра. Лише після цього протестували перезавантаження в нове ядро у контрольованому вікні.

Нічого героїчного. Жодних хитрощів. Просто послідовність дій і пріоритет для зворотності. Ось як виглядає надійність, коли вона працює.

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

1) Симптом: GRUB з’являється, але завантаження нового ядра кидає в аварійну оболонку

Корінь: initramfs без драйверів сховища або ZFS‑модуля; DKMS не встановив модулі для нового ядра; повний /boot призвів до часткових образів.

Виправлення: завантажте старе ядро; звільніть місце в /boot; запустіть dkms status; встановіть відсутні модулі для нового ядра; перегенеруйте initramfs для того ядра; запустіть update-grub; протестуйте.

2) Симптом: «ZFS: module not found» або пул не імпортується під час завантаження

Корінь: ZFS‑модулі не збудовані/не встановлені для нового ядра або блоковані політикою Secure Boot.

Виправлення: завантажтеся старим ядром; перебудуйте/встановіть ZFS DKMS для цільового ядра; перегенеруйте initramfs; якщо Secure Boot увімкнено — впевніться в підписуванні модулів або відкоригуйте політику.

3) Симптом: після оновлення прошивка каже «no bootable device»

Корінь: втрачене UEFI NVRAM запис; ESP пошкоджено; ESP не змонтовано під час оновлення і файли завантаження не там, де прошивка очікує.

Виправлення: підтвердіть mount ESP; перевірте /boot/efi/EFI; відтворіть запис за допомогою efibootmgr якщо потрібно; перевстановіть GRUB EFI бінарники з працюючої системи або через chroot.

4) Симптом: система завантажується, але немає мережі

Корінь: регрес NIC драйвера; відсутній пакет firmware; DKMS драйвер не зібраний; зміна імен інтерфейсів через порядок PCI/firmware.

Виправлення: завантажте старе ядро; порівняйте вихід ip link між ядрами; перевірте journalctl -k на помилки завантаження драйверів; перевстановіть пакети firmware; перебудуйте DKMS; підтягніть конфігурацію інтерфейсів, якщо імена змінились.

5) Симптом: меню GRUB має тільки один запис (зламане ядро)

Корінь: старі ядра видалені; update-grub не запускали; /boot не змонтовано; образи ядра відсутні.

Виправлення: з rescue або chroot встановіть принаймні одне відоме робоче ядро; переконайтеся, що /boot змонтовано; запустіть update-grub. Припиніть автоматичне видалення ядер без політики збереження відкатів.

6) Симптом: чорний екран після GRUB, але вентилятори крутяться і індикатори дисків блимають

Корінь: передача framebuffer/графічної консолі; неправильно налаштований serial console; завантаження триває, але ви не бачите вивід.

Виправлення: спробуйте nomodeset; перевірте налаштування IPMI Serial‑over‑LAN; встановіть параметри kernel console постійно, якщо ви залежите від serial. Підтвердіть доступність через мережу з іншого хоста.

Чек‑листи / покроковий план

Чек‑лист A: відновити вузол зараз (мінімальний ризик)

1. Отримайте доступ до системи через консоль/IPMI. Не робіть гадань віддалено.
2. Примусово викличте меню GRUB (Shift для BIOS, Esc для UEFI).
3. Виберіть Advanced options, завантажте останнє відоме робоче ядро.
4. Підтвердіть версію ядра за допомогою uname -r.
5. Перевірте стан сховища (ZFS: zpool status; не‑ZFS: перевірте монтування).
6. Підтвердіть, що мережа працює достатньо для доступу в management.
7. Зафіксуйте відоме робоче ядро як дефолт через механізм saved у GRUB.

Чек‑лист B: відремонтувати зламане ядро (щоб можна було безпечно оновити)

1. Перевірте, що /boot і /boot/efi змонтовані і є місце.
2. Проаналізуйте останні логи проваленого запуску (journalctl -b -1 -p err).
3. Якщо є ZFS/DKMS: перевірте dkms status і файли модулів у /lib/modules/<new-kernel>.
4. Перебудуйте initramfs для цільового ядра: update-initramfs -u -k <version>.
5. Запустіть update-grub і переконайтеся, що воно знаходить kernel + initrd.
6. Якщо UEFI‑проблеми: перевірте EFI записи через efibootmgr -v і вміст ESP.
7. Заплануйте контрольоване перезавантаження в нове ядро. Будьте на консолі. Фіксуйте вивід при відмові.

Чек‑лист C: зміцнити захист від наступного разу

1. Тримайте не менше двох завантажувальних ядер. Розглядайте це як політику, а не опцію.
2. Моніторте використання /boot і сповіщайте до 90% заповнення.
3. Для ZFS root: переконайтеся, що ZFS‑модулі збудовано для нових ядер перед перезавантаженням (DKMS‑перевірки в процесі змін).
4. Визначте політику Secure Boot: або підтримуйте підпис модулів правильно, або вимикайте його спеціально. «Напівзаходи» — джерело відмов.
5. Тестуйте оновлення ядер на подібному вузлі перед продакшеном (апарат має значення для драйверів).

FAQ

1) Чи відкат через GRUB — «правильний спосіб» чи просто хак?

Це правильний спосіб. Він використовує механізм, призначений саме для цього: кілька встановлених ядер із меню завантажувача. Хак — це видаляти всі старі ядра.

2) Чому оновлення Proxmox зламало завантаження, якщо на іншому вузлі воно пройшло?

Через різницю в апаратному забезпеченні. Різні HBA, NIC, GPU, версії прошивки, стани Secure Boot та розмітки ESP. Ядра поводяться пристойно до першої зустрічі з вашою конкретною PCI‑платою.

3) Чи слід видаляти зламаний пакет ядра?

Не одразу. Спочатку стабілізуйтеся на старому ядрі, зберіть логи і спробуйте виправити нове ядро (initramfs + DKMS + ESP). Видаляйте його лише якщо ви впевнені, що воно неремонтопридатне для вашого обладнання або вам терміново потрібне місце в /boot.

4) Скільки ядер потрібно тримати встановленими?

Не менше двох завантажувальних ядер (поточне стабільне і попереднє). На критичних хостах три — не надмірно, особливо при вузьких вікнах змін.

5) Моє меню GRUB не показується. Як зробити його постійно видимим?

У працюючій системі можна змінити налаштування GRUB (наприклад, timeout або показ меню). Операційно я віддаю перевагу прихованому меню і використанню консолі, якщо потрібно. Якщо вам потрібен постійний показ для remote hands — встановіть ненульовий timeout і уникайте «quiet» під час стабілізації.

6) Я на ZFS root. Чи потрібні особливі кроки?

Так: перевірте наявність ZFS‑модулів для цільового ядра і що initramfs їх містить. Якщо ZFS не завантажиться, root pool не імпортується і ви опинитесь в оболонці initramfs.

7) Чи може Secure Boot блокувати ZFS або інші модулі після оновлення ядра?

Так. Secure Boot може заборонити завантаження непідписаних модулів ядра. Якщо в логах згадується помилка перевірки підпису, розглядайте це як політичну невідповідність, а не випадкову помилку завантаження.

8) Система завантажується старим ядром, але служби Proxmox поводяться дивно. Що далі?

Перевірте неуспішні юніти та стан кластера. Перезавантаження могло виявити не пов’язані проблеми: деградовані ZFS пули, дрейф часу, флапи corosync. Виправте платформенне здоров’я, а потім думайте про повторне оновлення.

9) Якщо /boot повний, чи можна просто вручну видалити старі initrd файли?

Не робіть так. Видаляйте пакети ядер через менеджер пакетів, щоб хук‑скрипти оновили GRUB та initramfs правильно. Ручне видалення створює меню, що посилається на відсутні файли — цікаве джерело другого інциденту.

10) Коли слід використовувати rescue‑носій?

Коли GRUB не може завантажити жодного ядра, коли ESP відсутній/пошкоджений або коли ви видалили всі робочі ядра. Rescue‑носії — нормально, просто повільніше і легше зробити помилку, якщо практики бракує.

Висновок: наступні кроки, що дійсно знижують ризик

Якщо ваш Proxmox хост не завантажується після оновлення ядра, чистий шлях такий: використайте GRUB, щоб завантажити попереднє ядро, зафіксуйте його як дефолт, потім виправте нове ядро, усунувши проблеми з initramfs, DKMS‑модулями (особливо ZFS) і консистентністю EFI/ESP. Завантажуйтесь у нове ядро лише коли ви можете спостерігати консоль і прибрали очевидні міни, як‑от переповнений /boot.

Зробіть ці кроки, у порядку:

1. Тримайте відоме робоче ядро як дефолт, доки оновлення не підтверджене.
2. Зберіть помилки останнього проваленого запуску (journalctl -b -1) і вважайте їх дорожньою картою.
3. Зробіть /boot простим: достатньо місця, коректні точки монтування і правило збереження rollback‑ядер.
4. Для ZFS root: переконайтеся, що ZFS‑модулі встановлено для кожного нового ядра до перезавантаження.
5. Напишіть маленький внутрішній runbook з цього інциденту. Наступного разу це має займати хвилини, а не години.

Продакшен‑системи не вимагають досконалості. Вони вимагають відтворюваного відновлення. Відкат через GRUB — це ваше відтворюване відновлення — використовуйте його свідомо.