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

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

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

По-перше: Чи досягає машина взагалі підказки для входу?

• Ні, застрягла до завантаження ядра (підказка GRUB / EFI shell): це зона завантажувача/ESP. Перейдіть до Виправлення GRUB та EFI.
• Ні, ядро панікує або не може змонтувати root: найімовірніше initramfs, відсутній драйвер сховища або невірний UUID root. Перейдіть до Initramfs та Сховища.
• Так, але сервіси не працюють (pvedaemon, pveproxy, кластер): розглядайте це як подію «завантаження пройшло, стек Proxmox впав». Перейдіть до Практичних завдань і Відновлення кластера.

По-друге: Чи видимі та імпортуються сховища?

• ZFS root або ZFS-дискове сховище відсутні: перевірте імпорт пулу, hostid, cachefile і імена пристроїв. ZFS зазвичай говорить правду прямо.
• LVM-thin відсутній: перевірте активацію PV/VG, очікування udev та чи має initramfs потрібні модулі для вашого HBA/NVMe.

По-третє: Чи безпечно повторно приєднувати вузол до кластера?

• Один вузол у кластері й він впав: не «виправляйте» кворум видаленням файлів випадковим чином. Підтвердіть, який вузол авторитетний для стану кластера.
• Два вузли впали: припустіть ризик split-brain. Зупиніться, виберіть джерело істини і дійте обережно.

І так, ви цілком можете витратити дві години на «налагодження мережі», коли справжня проблема — що коренева файлова система змонтована тільки для читання після відтворення журналу. Бачив. Пройшов.

Цікаві факти та контекст (чому це повторюється)

• Proxmox VE базується на складових Debian. Коли ви оновлюєте Proxmox, ви оновлюєте Debian-підсистему плюс відбірковий стек: ядро(а), QEMU, LXC, ZFS та служби управління.
• Наявність кількох ядер — це функція, а не мотлох. Пакування в стилі Debian зазвичай зберігає старіші ядра, щоб можна було завантажитися в відоме робоче. Видаляти всі, крім одного — як продавати запасне колесо заради економії ваги.
• initramfs придумали, щоб вирішувати проблеми “драйвери занадто рано”. Сучасним системам потрібні модулі сховища й крипто ще до появи «справжнього» root; initramfs — це ранній користувацький простір для цього.
• UEFI змінив режими відмов. Старі відмови BIOS+MBR часто були «GRUB помер». З UEFI у вас може бути ідеальна ОС, але зламаний EFI System Partition (ESP), запис NVRAM або ланцюжок shim.
• ZFS консервативний за замовчуванням, але вимогливий до ідентичності. Невідповідність hostid або застарілий cachefile можуть перешкодити автоімпорту при завантаженні, особливо після клонування дисків або переміщення пулів між машинами.
• Corosync навмисно жорсткий щодо кворуму. Він спроектований, щоб не дозволяти працювати кластеру в split-brain ситуації, навіть якщо ви продуктивні в цей день.
• Веб-інтерфейс Proxmox — лише клієнт. Коли вузол «виглядає мертвим» в браузері, можливо просто впав pveproxy, тоді як ВМ під ним працюють.
• Оновлення ядра можуть ламати out-of-tree модулі. NVIDIA, деякі HBA з драйверами постачальника та модулі DKMS можуть не зібратися, і ви залишитесь без потрібних драйверів при завантаженні.

Одна корисна ідея для монітора: надія — не стратегія — часто повторюють в операційних колах, коли команди замінюють відкат планом «можливо пощастить».

Правила безпеки перед тим, як щось чіпати

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

Правила, яких я дотримуюся насправді

• Віддавайте перевагу зворотним змінам. Завантаження в старіше ядро — зворотне. Перевстановлення GRUB зазвичай зворотне. «Стерти й перевстановити Proxmox» — це не план відновлення; це сповідь.
• Записуйте, що ви змінюєте. Нотатки з часовими мітками краще за героїчну пам’ять щоразу.
• Не приєднуйте вузол до кластера, поки він не стане стабільним. Членство в кластері множить помилки.
• Припускайте, що ваше сховище невинне, поки не доведено протилежне. Проблеми із завантаженням часто виглядають як проблеми з диском. Не починайте «випалювати» пули тільки тому, що initramfs не бачить HBA.
• Отримайте консольний доступ. IPMI/iKVM/фізична консоль. SSH — чудово, поки раптом не стає неможливим.

Жарт №1: Єдина річ більш постійна, ніж тимчасове тимчасове обхідне рішення — це тимчасове обхідне рішення, зроблене під тиском.

Сценарії відмов після оновлення Proxmox

«Не працює після оновлення» зазвичай означає одну з цих категорій:

1. Поломка завантажувача/EFI: відсутнє меню GRUB, втрачені записи UEFI, ESP не змонтована або initrd не знайдено.
2. Ядро завантажується, але root не монтується: відсутній драйвер сховища, невірний UUID root, пошкоджене initramfs, не вдається розшифрувати зашифрований root.
3. Система завантажується, але стек Proxmox падає: служби pve не стартують, файлові системи кластера зависли, проблеми corosync, сертифікатні чи правові помилки.
4. Система завантажується, мережа зламана: мости не піднімаються, режим бонда не співпадає після оновлення драйвера, невідповідності MTU, зміни імен інтерфейсів.
5. Система завантажується, сховище відсутнє: ZFS-пули не імпортуються, томи LVM не активуються, multipath-плутанина, деградовані масиви викликають таймаути.

Трюк — швидко категоризувати відмову. Потім обрати найменш інвазивне виправлення, яке відновить сервіс.

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

Нижче — практичні завдання, які можна запускати на зламаному вузлі або з rescue-режиму/chroot. Кожне включає, що означає вивід і яке рішення приймати далі.

Завдання 1: Визначте, яке ядро ви завантажили (або намагалися)

cr0x@server:~$ uname -a
Linux pve01 6.8.12-4-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-4 (2025-02-10T12:00Z) x86_64 GNU/Linux

Значення: Підтверджує версію запущеного ядра. Якщо запущено найновіше ядро й щось не працює, відкат — перший крок.

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

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

cr0x@server:~$ dpkg -l | egrep 'pve-kernel|linux-image' | awk '{print $1,$2,$3}'
ii pve-kernel-6.5.13-5-pve 6.5.13-5
ii pve-kernel-6.8.12-4-pve 6.8.12-4
ii proxmox-kernel-helper 8.1.1

Значення: Маєте принаймні одне старіше ядро. Це рятівне коло.

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

Завдання 3: Перевірити, чи система перейшла в emergency mode і чому

cr0x@server:~$ systemctl --failed
UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
pve-cluster.service          loaded failed failed The Proxmox VE cluster filesystem
corosync.service             loaded failed failed Corosync Cluster Engine

Значення: ОС запущена, але кластерні сервіси впали. Це може блокувати управління Proxmox і навіть операції ВМ, які залежать від FS кластера.

Рішення: Не перезавантажуйте наосліп. Подивіться логи для невдалого юніта й вирішіть, чи ізолювати вузол (локальний режим), чи лагодити corosync.

Завдання 4: Переглянути журнал для першої реальної помилки

cr0x@server:~$ journalctl -b -p err --no-pager | head -n 30
Feb 12 09:14:51 pve01 systemd[1]: Failed to start The Proxmox VE cluster filesystem.
Feb 12 09:14:51 pve01 pmxcfs[1203]: [main] unable to open cluster database (Connection refused)
Feb 12 09:14:51 pve01 corosync[1188]: [TOTEM ] Failed to bind to multicast address
Feb 12 09:14:51 pve01 corosync[1188]: [MAIN  ] Corosync Cluster Engine exiting with status '2'

Значення: Це не «Proxmox зламався», а проблема зв’язку corosync, часто мережева (імена інтерфейсів, зміни IP, MTU, firewall).

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

Завдання 5: Підтвердити, що імена інтерфейсів не змінились під вами

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
enp4s0           UP             3c:ec:ef:12:34:56
enp5s0           DOWN           3c:ec:ef:12:34:57
vmbr0            DOWN           3c:ec:ef:12:34:56

Значення: Міст DOWN. Це може бути так просто, як NIC, що впав, або конфігурація моста, яка не застосувалася.

Рішення: Перевірте /etc/network/interfaces і спробуйте контрольований рестарт мережі (або підніміть міст вручну) перед тим, як звинувачувати corosync.

Завдання 6: Перевірити, чи Proxmox змонтував /etc/pve (pmxcfs)

cr0x@server:~$ mount | grep /etc/pve

Значення: Відсутній вивід означає, що pmxcfs не змонтовано; файлової системи кластера немає.

Рішення: Якщо потрібне локальне відновлення, можна тимчасово запускати Proxmox у «no cluster» стані (розглядається далі). Якщо це мультивузлове середовище — лагодьте corosync спочатку.

Завдання 7: Перевірити видимість дисків та стан драйверів ядра

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda     1.8T disk
├─sda1  512M part vfat   /boot/efi
├─sda2    1G part ext4   /boot
└─sda3  1.8T part
  └─pve-root  96G lvm    /
nvme0n1 1.7T disk zfs_member
nvme1n1 1.7T disk zfs_member

Значення: Диски присутні; EFI і /boot змонтовані; ZFS-члени видимі. Це знижує ймовірність «залізо зникло».

Рішення: Якщо пристрої відсутні — підозрюйте ядро/HBA модуль/initramfs. Якщо присутні, але пули/томи відсутні — зосередьтесь на імпорті/активації.

Завдання 8: Перевірити статус імпорту ZFS пулу (якщо ви використовуєте ZFS)

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

        tank           ONLINE
          mirror-0     ONLINE
            nvme0n1    ONLINE
            nvme1n1    ONLINE

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

Рішення: Імпортуйте в режимі запису лише якщо впевнені, що цей вузол — правильний власник. Якщо сумніваєтесь (спільне сховище, переміщення дисків) — спочатку імпортуйте в режимі read-only.

Завдання 9: Обережно імпортувати ZFS пул і встановити cachefile для майбутніх завантажень

cr0x@server:~$ zpool import -o cachefile=/etc/zfs/zpool.cache tank
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            nvme0n1   ONLINE       0     0     0
            nvme1n1   ONLINE       0     0     0

errors: No known data errors

Значення: Пул імпортовано й здоровий. Встановлення cachefile допомагає initramfs/послідовності завантаження надійніше знаходити пули.

Рішення: Якщо імпорт не вдається через hostid, вирішіть проблему з hostid замість примусових імпортів.

Завдання 10: Перевірити стан LVM (якщо ви використовуєте LVM-thin)

cr0x@server:~$ pvs
  PV         VG  Fmt  Attr PSize  PFree
  /dev/sda3  pve lvm2 a--  <1.82t 0
cr0x@server:~$ vgs
  VG  #PV #LV #SN Attr   VSize  VFree
  pve   1   3   0 wz--n- <1.82t 0
cr0x@server:~$ lvs -a
  LV   VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data pve twi-aotz-- <1.60t             72.11  2.40
  root pve -wi-ao----  96.00g
  swap pve -wi-ao----   8.00g

Значення: PV/VG/LV існують і активні (ao). Якщо VG відсутні або неактивні — проблема з активацією сховища.

Рішення: Якщо неактивні, спробуйте vgchange -ay і перевірте dmesg на помилки пристрою перед примусовим ремонтом.

Завдання 11: Перевірити вільне місце в /boot та ESP (оновлення тихо падають, коли /boot заповнений)

cr0x@server:~$ df -h /boot /boot/efi
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2      1007M  983M   24M  98% /boot
/dev/sda1       511M   12M  500M   3% /boot/efi

Значення: /boot практично повний. Це може призводити до неповних інсталяцій initramfs/kernel і дивної поведінки при завантаженні.

Рішення: Видаляйте старі ядра коректно (після того, як у вас є відоме робоче завантаження) або розширіть /boot. Не видаляйте випадкові файли в /boot.

Завдання 12: Перевірити помилки збірки DKMS/модулів, що ламають драйвери

cr0x@server:~$ journalctl -b --no-pager | grep -E 'dkms|module|firmware' | tail -n 20
Feb 12 09:10:22 pve01 kernel: i915 0000:00:02.0: firmware: failed to load i915/skl_dmc_ver1_27.bin (-2)
Feb 12 09:10:25 pve01 dkms[842]: Error! Bad return status for module build on kernel: 6.8.12-4-pve (x86_64)
Feb 12 09:10:25 pve01 dkms[842]: Consult /var/lib/dkms/.../build/make.log for more information.

Значення: DKMS-модуль не зібрався. Якщо цей модуль потрібний для сховища або мережі, завантаження може пройти, але пристрої не працюватимуть.

Рішення: Виконайте відкат ядра або виправте збірку DKMS. Якщо це не критично (наприклад GPU на хості без консолі), заглушіть шум, але не ігноруйте помилки DKMS, пов’язані зі сховищем.

Завдання 13: Підтвердити здоров’я сервісів Proxmox (коли ОС завантажується, але UI мертвий)

cr0x@server:~$ systemctl status pveproxy pvedaemon pvestatd --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Wed 2025-02-12 09:18:02 UTC; 2min ago
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Wed 2025-02-12 09:18:00 UTC; 2min ago
● pvestatd.service - PVE Status Daemon
     Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled)
     Active: active (running) since Wed 2025-02-12 09:18:01 UTC; 2min ago

Значення: Основні служби працюють. Якщо веб-інтерфейс все ще не доступний — підозрівайте firewall, проблеми з сертифікатами або кеш клієнта.

Рішення: Якщо сервіси впали, перевірте залежності: монтування /etc/pve, вирішення DNS/hostname, синхронізацію часу, заповнення диска.

Завдання 14: Перевірити статус кластера і кворум без здогадок

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   43
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Wed Feb 12 09:21:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2
Quorate:          Yes

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

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

Відкат ядра: найменш драматичне рішення

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

Завантажитись зі старішим ядром через GRUB

Під час завантаження оберіть Advanced options і виберіть попереднє pve-kernel. Якщо не вдається потрапити в GRUB через швидкий екран, утримуйте Shift на BIOS-системах або натисніть Esc на багатьох UEFI-системах під час завантаження.

Закріпити відоме робоче ядро (тимчасово)

Після завантаження в робоче ядро — не дозволяйте системі «допоміжно» переключитися назад при наступному перезавантаженні.

cr0x@server:~$ proxmox-boot-tool kernel list
Manually selected kernels:
None.

Automatically selected kernels:
6.8.12-4-pve
6.5.13-5-pve

Pinned kernel:
None.

Значення: Нема закріпленого ядра; за замовчуванням може бути вибране найновіше.

Рішення: Закріпіть робоче ядро, поки не завершіть розслідування.

cr0x@server:~$ proxmox-boot-tool kernel pin 6.5.13-5-pve
Pinned kernel version '6.5.13-5-pve'

Якщо у вас не proxmox-boot-tool-керована система, ви також можете керувати за замовчуванням GRUB, але закріплення через інструменти Proxmox зазвичай чистіше.

Перегенерувати initramfs і оновити GRUB після відкату

Навіть якщо старе ядро завантажується, оновіть артефакти завантаження, щоб не натикатися на напівзаписані initramfs-файли.

cr0x@server:~$ update-initramfs -u -k 6.5.13-5-pve
update-initramfs: Generating /boot/initrd.img-6.5.13-5-pve

Значення: initramfs перегенеровано для обраного ядра.

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

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

Значення: GRUB бачить обидва ядра та initrd.

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

Виправлення GRUB та проблем з EFI

Якщо ви опинилися в підказці GRUB, EFI shell або «no bootable device», ви вже не налагоджуєте Proxmox — ви налагоджуєте ланцюжок завантаження. Трактуйте це як хірургічне втручання: перевірте диски, перевірте розділи, змонтуйте правильно, а потім перевстановіть завантажувач.

Визначити: BIOS/MBR чи UEFI?

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

Значення: Цей хост завантажений в UEFI-режимі (або має бути).

Рішення: Сфокусуйтеся на EFI System Partition у /boot/efi та записах NVRAM.

Перевірити, що ESP присутня і змонтована

cr0x@server:~$ lsblk -f | grep -E 'vfat|EFI|/boot/efi'
sda1 vfat   FAT32  7A3B-1C2D                            /boot/efi

Значення: ESP існує і змонтована. Якщо її немає або не змонтована — ви не зможете надійно перевстановити GRUB.

Рішення: Якщо не змонтована — змонтуйте. Якщо монтування не вдається — виконайте перевірку файлової системи з rescue-режиму.

Перевірити записи завантаження UEFI

cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* UEFI OS       HD(1,GPT,...)File(\EFI\BOOT\BOOTX64.EFI)
Boot0002* proxmox       HD(1,GPT,...)File(\EFI\proxmox\grubx64.efi)

Значення: Запис завантаження існує і вказує на Proxmox GRUB EFI-бінарник. Якщо він вказує в нікуди — ви потрапите в EFI shell.

Рішення: Якщо відсутній — перевстановіть GRUB на ESP і відтворіть запис завантаження.

Перевстановити GRUB для UEFI

cr0x@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.

Рішення: Виконайте update-grub і перевірте запис через efibootmgr.

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

Якщо потрібен rescue-режим + chroot (поширено)

Коли вузол зовсім не завантажується, завантажтеся з rescue ISO, змонтуйте кореневу файл. систему і виконайте chroot. Конкретні кроки залежать від того, чи root на LVM або ZFS. Нижче приклад для LVM-root.

cr0x@server:~$ vgscan
  Found volume group "pve" using metadata type lvm2
cr0x@server:~$ vgchange -ay
  3 logical volume(s) in volume group "pve" now active
cr0x@server:~$ mount /dev/pve/root /mnt
cr0x@server:~$ mount /dev/sda2 /mnt/boot
cr0x@server:~$ mount /dev/sda1 /mnt/boot/efi
cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do mount --bind $i /mnt$i; done
cr0x@server:~$ chroot /mnt /bin/bash

Значення: Тепер ви працюєте всередині встановленої ОС, де інструменти для GRUB і initramfs очікують запуску.

Рішення: Перевстановіть kernel/initramfs/GRUB зсередини chroot; потім вийдіть, коректно відмонтуйте і перезавантажтеся.

Initramfs, відсутні модулі та драйвери сховища

Класичний «після оновлення» brick: ядро завантажується, а потім не знаходить кореневу файлову систему. Ви бачите повідомлення на кшталт «waiting for root device», «unable to mount root fs» або потрапляєте в initramfs shell.

Це часто одна з наступних причин:

• initramfs згенеровано некоректно (місце в /boot закінчилось, оновлення перервано).
• Не включено потрібні модулі для вашого контролера сховища.
• UUID root змінився (клонування, заміна диска), але конфіг завантаження не оновився.
• ZFS root: пул не імпортувався через hostid/cache проблеми.

Перевірити, що ядро вважає вашим root-пристроєм

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=/dev/mapper/pve-root ro quiet

Значення: Root вказує на LVM mapper-пристрій. Якщо цей mapper ніколи не з’явиться — монтування root зазнає невдачі.

Рішення: Перевірте активацію LVM в initramfs (або перегенеруйте initramfs з LVM-реалізацією) і підтвердіть, що підлягаючий PV видимий рано під час завантаження.

Подивитися, чи завантажився драйвер сховища

cr0x@server:~$ lsmod | egrep 'nvme|ahci|megaraid|mpt3sas|vfio' | head
nvme                   61440  2
ahci                   45056  0

Значення: У запущеній системі присутні модулі NVMe і AHCI. У сценаріях відмов вони можуть бути відсутні в initramfs, але присутні в повній ОС.

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

Перегенерувати initramfs для всіх встановлених ядер

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.5.13-5-pve
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve

Значення: Обидва initrd перегенеровані. Це вирішує велику кількість «напіввстановлених ядро» проблем із завантаженням.

Рішення: Якщо вихідна помилка «No space left on device» — виправте /boot перед продовженням.

Переконайтеся, що /etc/initramfs-tools/modules містить потрібні драйвери

Більшість систем цього не потребують. Деякі потребують. Особливо якщо ви завантажуєтесь з екзотичних HBA або iSCSI або маєте жорсткі проблеми з порядком завантаження. Приклад, що можна додати:

cr0x@server:~$ sed -n '1,120p' /etc/initramfs-tools/modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
nvme
ahci

Значення: Ці модулі будуть примусово додані в initramfs.

Рішення: Додавайте лише ті модулі, які розумієте. Набивання initramfs усім підряд призведе до повільних завантажень і нових режимів відмов.

Відновлення сховища: ZFS та LVM-thin

Сховище — це місце, де «просто» стає «інцидент». Помилитися тут — означає створити реальну корупцію. Зробити правильно — виглядатиме як фокус. Різниця — в дисципліні.

ZFS: пули не імпортуються після оновлення

Поширені причини:

• Невідповідність hostid після перевстановлення, клонування або випадкової зміни /etc/hostid.
• cachefile відсутній/застарілий; initramfs не може надійно знайти пули.
• Зміни в іменах пристроїв (наприклад порядок SATA) і ви використовували сирі /dev/sdX замість by-id.
• Пул зайнятий або імпортований в іншому місці (в сценаріях із спільними дисками — це тривожний сигнал).

Перевірити hostid та очікування ZFS

cr0x@server:~$ hostid
1a2b3c4d
cr0x@server:~$ ls -l /etc/hostid
-rw-r--r-- 1 root root 4 Feb 12 09:00 /etc/hostid

Значення: hostid існує. Якщо він недавно змінився — ZFS може відмовитись від автоімпорту або поводитися інакше.

Рішення: Якщо пули переміщувалися з іншого хоста — свідомо встановіть hostid і документуйте це. Не робіть «на око» примусові імпорти.

Перевірити стан пулу після імпорту

cr0x@server:~$ zpool status -x
all pools are healthy

Значення: Відомих проблем ZFS немає.

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

LVM-thin: Відсутні ВМ, сховище “неактивне” або помилки thin pool

LVM-thin зазвичай ламається через проблеми з порядком активації або таймаути підлягаючих пристроїв. Рідше — метадані thin заповнюються.

Активувати групи томів і перевірити використання метаданих thin

cr0x@server:~$ vgchange -ay
  3 logical volume(s) in volume group "pve" now active
cr0x@server:~$ lvs -o lv_name,vg_name,attr,lv_size,data_percent,metadata_percent
  LV   VG  Attr       LSize   Data%  Meta%
  data pve twi-aotz-- <1.60t  72.11  2.40
  root pve -wi-ao----  96.00g
  swap pve -wi-ao----   8.00g

Значення: Метадані thin-пулу використані тільки на 2.40%. Це нормально.

Рішення: Якщо метадані майже 100% — зупиніться. Розширення/ремонт метаданих thin делікатний; не перезапускайте десятки ВМ і не погіршуйте ситуацію.

Перевірити помилки файлової системи, якщо root став доступний лише для читання

cr0x@server:~$ mount | grep ' / '
/dev/mapper/pve-root on / type ext4 (ro,relatime,errors=remount-ro)

Значення: Root змонтовано в режимі read-only. Це зламає менеджмент пакетів, кластер FS, логи — все.

Рішення: Перезавантажтесь у rescue і виконайте fsck. Не «просто перемонтуйте в rw» і надійтесь; ви часто погіршите метадані.

Відновлення кластера: кворум, corosync та безпечне повторне приєднання

Відновлення кластера — місце, де інженери з добрими намірами спричиняють погані тижні. Corosync вибагливий за дизайном. Поважайте це.

Визначте, з чим маєте справу:

• Один зламаний вузол при здоровому решті кластера.
• Втрата кворуму через кілька впалих вузлів або мережевий розрив.
• Ризик split-brain (дві сторони кожна вважає себе первинною).

Перевірити статус corosync та кластера

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: failed (Result: exit-code) since Wed 2025-02-12 09:14:51 UTC; 8min ago
     Process: 1188 ExecStart=/usr/sbin/corosync -f $COROSYNCOPTIONS (code=exited, status=2)

Значення: corosync не стартував. Причина — у логах; не гадати.

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

cr0x@server:~$ journalctl -u corosync --no-pager | tail -n 40
Feb 12 09:14:51 pve01 corosync[1188]: [KNET  ] host: 1 link: 0 is down
Feb 12 09:14:51 pve01 corosync[1188]: [KNET  ] failed to bind to interface 'vmbr0'
Feb 12 09:14:51 pve01 corosync[1188]: [MAIN  ] Corosync Cluster Engine exiting with status '2'

Значення: Corosync хоче прив’язатися до vmbr0, але він down або відсутній. Полагодьте мережеву конфігурацію перед зміною конфігу кластера.

Рішення: Підніміть міст/інтерфейс, потім повторіть запуск corosync.

Тимчасовий локальний режим (використовуйте помірковано)

Іноді потрібно привести вузол в робочий стан (наприклад, щоб евакуювати ВМ через доступ до сховища), хоча corosync не може сформуватися. Proxmox підтримує роботу без кластерних комунікацій, але треба розуміти компроміси.

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

cr0x@server:~$ systemctl stop pve-cluster corosync
cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: inactive (dead)

Значення: Кластерна FS зупинена; ви більше не записуєте стан кластера.

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

Жарт №2: Split-brain — це коли обидві половини вашого кластера стають дуже впевнені й дуже невірні.

Стратегія повторного приєднання

Після того як вузол чисто завантажився, мережа стабілізована і сховище коректне, увімкніть corosync і pmxcfs і підтвердіть кворум. Не «фіксуйте» невідповідності версій конфігу копіюванням випадкових файлів; вирівняйте вузол до джерела істини кластера.

Відновлення мережі: мости, бонди та «чому vmbr0 не піднявся?»

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

Переглянути конфіг мережі

cr0x@server:~$ sed -n '1,200p' /etc/network/interfaces
auto lo
iface lo inet loopback

auto enp4s0
iface enp4s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1
        bridge-ports enp4s0
        bridge-stp off
        bridge-fd 0

Значення: vmbr0 залежить від enp4s0. Якщо enp4s0 перейменовано (наприклад на enp3s0), vmbr0 не підніметься.

Рішення: Порівняйте з ip -br link і виправте імена інтерфейсів. Потім підніміть мережу обережно.

Підняти міст вручну, щоб підтвердити, що проблема в конфігу, а не в залізі

cr0x@server:~$ ip link set enp4s0 up
cr0x@server:~$ ifup vmbr0
Internet Systems Consortium DHCP Client 4.4.3-P1
ifup: interface vmbr0 already configured

Значення: Або він вже налаштований, або ifupdown2 вважає його налаштованим. Якщо він залишається DOWN — перевірте ip addr і логи.

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

Переконатися, що інтерфейс, до якого прив’язується corosync, існує й має очікуваний IP

cr0x@server:~$ ip -br addr show vmbr0
vmbr0            UP             10.10.10.11/24

Значення: Corosync тепер може прив’язатися. Часто це і є повним вирішенням «кластер впав після оновлення».

Рішення: Перезапустіть corosync, потім pve-cluster у такому порядку і перевірте pvecm status.

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

План A: Вузол не завантажується після оновлення (найпоширеніший)

1. Отримайте консольний доступ (IPMI/iKVM). Зафіксуйте першу помилку на екрані.
2. Спробуйте в опціях GRUB: завантажте попереднє ядро Proxmox.
3. Якщо завантаження пройшло — закріпіть робоче ядро і перегенеруйте initramfs для всіх ядер.
4. Перевірте вільний простір у /boot; якщо майже повний — видаліть старі ядра лише після підтвердження стабільного завантаження.
5. Перевірте сховище: ZFS-пули імпортовані, LVM активований, коренева ФС змонтована в режимі rw.
6. Підтвердіть сервіси Proxmox: pveproxy/pvedaemon/pvestatd, потім кластерні сервіси, якщо застосовно.
7. Перезавантажтеся раз, щоб перевірити, що виправлення збереглося.

План B: Відмова GRUB/UEFI (ви навіть не можете дістатися до ядра)

1. Завантажте rescue ISO у тому ж режимі (UEFI vs BIOS), в якому система використовувалася.
2. Змонтуйте root, /boot і /boot/efi; зробіть bind-mount для /dev,/proc,/sys,/run; виконайте chroot.
3. Перевстановіть GRUB в ESP (UEFI) або на диск (BIOS) і запустіть update-grub.
4. Перегенеруйте initramfs для відомого робочого ядра.
5. Перевірте записи efibootmgr; перезавантажтесь і протестуйте.

План C: ОС завантажується, стек Proxmox зламаний (UI недоступний, кластер розлючений)

1. Спочатку перевірте заповнення диска, чи root змонтований read-only і зсув часу.
2. Перегляньте невдалі юніти через systemctl --failed.
3. Підтвердіть стан монтування /etc/pve; проблеми з кластерною FS зламають управління.
4. При помилках corosync перевірте мережевий інтерфейс і MTU, потім перезапустіть corosync і pve-cluster.
5. Тільки якщо необхідно — тимчасово працюйте в локальному режимі, щоб відновити ВМ або сховище, потім коректно приєднайтесь назад.

План D: Сховище відсутнє після оновлення

1. Підтвердіть, що ядро бачить диски (lsblk, dmesg).
2. Для ZFS: запустіть zpool import, імпортуйте обережно, встановіть cachefile, перевірте hostid.
3. Для LVM: запустіть vgscan, vgchange -ay, перевірте використання thin-метаданих.
4. Не примушуйте імпорт/ремонт, поки не розумієте, чи диски були переміщені або спільні.

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

1) Симптом: «Завантажується в initramfs shell, не знаходить root-пристрій»

Корінь проблеми: initramfs не містить драйверів сховища або LVM-скриптів; або оновлення залишило неповний initrd через заповнений /boot.

Виправлення: Завантажте старіше ядро; у rescue/chroot перегенеруйте initramfs (update-initramfs -u -k all), звільніть місце в /boot, переконайтеся, що потрібні модулі включені.

2) Симптом: «Підказка GRUB» або «no bootable device» після оновлення

Корінь проблеми: зламане монтування ESP, відсутній запис EFI, grub-install не завершився або ESP пошкоджено.

Виправлення: Змонтуйте ESP, перевстановіть GRUB для UEFI, запустіть update-grub, перевірте efibootmgr.

3) Симптом: «Вузол завантажується, але веб UI мертвий»

Корінь проблеми: pveproxy або pvedaemon не працюють; /etc/pve не змонтовано; root read-only; заповнений диск.

Виправлення: Перевірте systemctl status для сервісів pve, підтвердіть mount | grep /etc/pve, виправте стан ФС, очистіть місце на диску.

4) Симптом: «Кластер показує вузол офлайн; помилки pmxcfs»

Корінь проблеми: corosync не може прив’язатися, бо ім’я інтерфейсу змінилося або міст down.

Виправлення: Виправте /etc/network/interfaces відповідно до реальних імен NIC, підніміть vmbr0, перезапустіть corosync, потім pve-cluster.

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

Корінь проблеми: невідповідність hostid або застарілий/відсутній zpool cachefile; зміни шляхів пристроїв.

Виправлення: Імпортуйте з опцією cachefile, підтвердіть стабільність hostid, віддавайте перевагу by-id іменам пристроїв, перегенеруйте initramfs, якщо root на ZFS.

6) Симптом: «Оновлення пройшло, але після перезавантаження мережа дивна»

Корінь проблеми: зміна драйвера NIC, перейменування інтерфейсів або невідповідність режиму бонду після оновлення модулів.

Виправлення: Переконайтесь у виводі ip -br link і підкорегуйте конфіг мосту/бонда; перевірте dmesg на помилки драйверів; зробіть відкат ядра, якщо потрібно.

7) Симптом: «Все виглядає нормально, але пакети не можна встановити/відкотити»

Корінь проблеми: root змонтовано read-only або /var заповнений; dpkg залишив пакети в напівналаштованому стані після перерваного оновлення.

Виправлення: Вирішіть стан ФС, потім запустіть dpkg --configure -a та apt -f install з коректного завантаження.

8) Симптом: «Диски ВМ відсутні у вигляді сховища»

Корінь проблеми: бекенд сховища неактивний (ZFS пул не імпортовано, VG не активовано), або pmxcfs не змонтовано і конфіг сховища не завантажено.

Виправлення: Відновіть спочатку сховище (імпорт/активація), потім переконайтеся, що кластерна FS змонтована і сервіси pve здорові.

Три міні-історії з корпоративного життя (біль, урок і одна нудна перемога)

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

Середня компанія мала три вузли Proxmox з Ceph для дисків ВМ і кілька локальних ZFS-пулів для бекапів. Під час вікенду оновлень один вузол не повернувся. Інженер черговий побачив «ZFS pool not imported» і вирішив, що безпечно виконати force import, бо «воно локальне».

Неправильне припущення: «локальний» пул не був суто локальним. Місяць тому команда апаратного забезпечення переміщала диски між вузлами під час заміни шасі. Ніхто не оновив нотатки про активи. Пул був імпортований на іншому вузлі під час переміщення, і історія hostid + cachefile стала хаотичною. Примусовий імпорт на зламаному вузлі зробив його видимим, але він не був авторитетною копією.

Вони не відразу корумпували пул, але зробили майже таку ж дорогу помилку: відновили бекапи з неправильних snapshot-ів. Кілька ВМ повернулись зі застарілими даними, що здавалося консистентним. Інцидент перестав бути «вузол впав», він став «питання коректності даних», що призвело до великих зборів у календарі.

Виправлення виявилося переважно процесним. Вони задокументували, де фізично лежить кожен пул, забезпечили імпорти через стабільні by-id шляхи і трактували «force import» як екстрену дію, що потребує другої думки. Технічно правильний план відновлення був би: імпорт у read-only, перевірка timestamps датасетів і тільки потім рішення. Соціально — не вважайте щось «локальним», якщо не можете показати стійку полицю.

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

Інша організація мала ініціативу зменшити час завантаження і вікна патчінгу на віртуалізаційних хостах. Хтось вирішив агресивно очищувати старі ядра, щоб звільнити місце в /boot і зменшити керування. Налаштували автоматизацію, що лишає тільки найновіше ядро.

Працювало — поки не перестало. Нове ядро принесло регресію для їхньої комбінації RAID-контролера і прошивки. Хост перезавантажився в нове ядро і не побачив кореневий диск. Оскільки старіше ядро видалили, опція «просто завантажити попереднє» зникла. Довелося танцювати з rescue ISO під час вже перевищеного вікна технічного обслуговування.

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

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

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

Команда з фінансових сервісів мала Proxmox-кластер для CI і кількох latency-sensitive сервісів. Їх практика патчінгу була нудною: один вузол за раз, евакуація ВМ, оновлення, перезавантаження, валідація, і лише потім наступний вузол. Вони також регулярно тестували iKVM/IPMI і знімали конфіг завантаження (список ядер, grub defaults, /etc/network/interfaces) перед обслуговуванням.

Під час одного оновлення вузол перезавантажився і отримав неправильно налаштовану мережу через перейменування інтерфейсу. Corosync впав. Вузол з точки зору кластера «впав». Але команда вже евакуювала навантаження. Тож клієнтів це не зачепило, лише самолюбство інженера.

Вони використали консоль, порівняли імена інтерфейсів, виправили порти моста, перезапустили corosync і коректно приєдналися. Постмортем був майже нудним: «зміна імені інтерфейсу; ми перевірили до/після; немає впливу на робочі навантаження.» Нудність — це мета. Драма — не KPI.

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

FAQ

1) Чи робити відкат ядра чи перевстановлювати Proxmox?

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

2) Чи безпечно видаляти зламаний пакет ядра?

Так, але лише після того, як ви підтвердили стабільне завантаження з іншим ядром і маєте достатньо місця в /boot. Використовуйте пакетні інструменти, а не видалення файлів у /boot вручну. Залишайте принаймні одне запасне ядро.

3) Мій вузол завантажується, але UI Proxmox недоступний. Чи мертві мої ВМ?

Не обов’язково. Перевірте systemctl status pveproxy і також перевірте процеси ВМ через qm list (якщо доступно) або ps. UI — це сервіс; він може впасти, тоді як QEMU продовжує працювати.

4) ZFS-пул не імпортується автоматично після перезавантаження. Яка найпоширеніша причина?

Проблеми з hostid/cachefile і зміни імен пристроїв. Імпортуйте пул явно, встановіть cachefile і переконайтеся, що hostid стабільний і свідомий.

5) Чи безпечно force-import ZFS-пул?

Іноді. Але це також чудовий спосіб перетворити невизначеність у наслідки. Якщо є будь-яка ймовірність, що пул імпортовано в іншому місці або його переміщали, імпортуйте спочатку read-only і перевірте.

6) Як зрозуміти, чи повний /boot спричинив мою відмову?

Перевірте df -h /boot. Якщо понад ~90% і ви нещодавно встановлювали ядра — ймовірно є напівзаписані initramfs або невдалі postinst скрипти. Перегенеруйте initramfs після звільнення місця.

7) Який безпечний порядок піднімати кластерні служби?

Спочатку мережа (інтерфейс, до якого прив’язується corosync, повинен бути UP), потім старт corosync, далі pve-cluster, підтвердження монтування /etc/pve, і лише потім перевірка сервісів pve.

8) Чи можу я запустити вузол Proxmox «standalone», якщо кластер зламався?

Тимчасово — так, зупинивши кластерні сервіси. Але ви відмовляєтесь від кластерно-керованої конфігурації й захисних механізмів. Використовуйте для відновлення даних або стабілізації вузла, потім коректно приєднайтесь назад.

9) Чому оновлення ядра зламало мережу?

Регрес у драйвері, взаємодія з прошивкою або перейменування інтерфейсів. Ядро — це контракт із залізом. Коли цей контракт змінюється, ваші налаштування мостів/бондiв можуть несподівано перестати працювати.

10) Якщо я виправлю завантаження, як запобігти цьому наступного разу?

Оновлюйте по одному вузлу за раз, тримайте запасні ядра, моніторте місце в /boot, перевіряйте генерацію initramfs і тестуйте консольний доступ до iKVM перед кризою.

Висновок: наступні реальні кроки

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

Наступні кроки, що окупаються:

• Тримайте принаймні два робочих ядра й залишайте місце в /boot.
• Тестуйте iKVM/IPMI щоквартально, а не під час кризи.
• Документуйте власність сховища (які пули де фізично) і віддавайте перевагу стабільним by-id шляхам пристроїв.
• Приймайте практику оновлення «один вузол за раз» з евакуацією ВМ і реальним чеклістом перевірки.

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