VPS не завантажується після оновлення ядра: що робити

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

VPS, який не завантажується після оновлення ядра, зазвичай можна відновити за кілька хвилин, оскільки оновлення не видалило ядро, яке працювало вчора. Ubuntu встановлює нове ядро поруч зі старим і змінює лише запис, який GRUB запускає за замовчуванням. Тому спочатку не потрібно нічого виправляти. Виберіть попереднє ядро в меню завантаження, дочекайтеся запрошення для входу, а потім діагностуйте проблему в запущеній системі.

Виправлення цієї проблеми на сервері відрізняється від виправлення на ноутбуці, оскільки до сервера не підключено клавіатуру, а монітор не показує повідомлення про kernel panic. SSH також не відповідатиме, оскільки система не дійшла до етапу запуску sshd. Усе описане нижче виконується через консоль вашого провайдера.

Перед будь-якими змінами прочитайте текст у власній консолі. Він визначає клас несправності. Два сервери, які обидва «не завантажуються», можуть потребувати протилежних виправлень.

Як отримати доступ до консолі, якщо SSH не працює?

Відкрийте панель керування свого провайдера та знайдіть консоль. Найпоширеніші назви: VNC console, web console, noVNC і serial console. Якщо доступні обидва варіанти, надайте перевагу serial console, оскільки вона показує справжній текст, який можна прокручувати й копіювати. VNC відображає лише зображення екрана. Знайдіть цей елемент керування заздалегідь, поки машина працює, і перевірте, що консоль відкривається. Пошук під час аварії забирає час і заважає спокійно діяти. Ця перевірка має бути частиною перших десяти хвилин після створення нового VPS, разом із правилами firewall і SSH keys.

Більшість панелей також мають rescue mode або recovery image. Вони запускають невелику систему з мережі провайдера та підключають ваш диск як додатковий пристрій, тому жоден процес із цього диска не запускається. Rescue mode є резервним варіантом, якщо зламано сам GRUB. Також його використовують, щоб скопіювати дані із сервера, який ви вирішили не відновлювати.

Зазвичай для переходу до boot menu потрібен hard reset із панелі, оскільки на машині, до якої неможливо увійти, не можна виконати sudo reboot. Hard reset еквівалентний вимкненню живлення. Файлові системи завершать роботу некоректно, тому під час наступного запуску очікуйте перевірку файлової системи.

Як вибрати старіше ядро в меню GRUB?

Спостерігайте за консоллю відразу після натискання кнопки скидання. У перші секунди кілька разів натискайте Esc або утримуйте Shift на комп’ютері, який завантажується в режимі legacy BIOS. Часове вікно коротке, а засобу перегляду консолі часто потрібна секунда для підключення, тому починайте натискати завчасно й не припиняйте.

Коли з’явиться меню, виберіть «Advanced options for Ubuntu». У цьому підменю перелічено всі встановлені ядра, починаючи з найновішого. Для кожного ядра також є пункт режиму відновлення. Виберіть другий звичайний пункт — ядро, яке є попереднім за версією до найновішого, — і натисніть Enter. Режим відновлення — це інший режим: система завантажується в мінімальне однокористувацьке середовище. Він призначений для відновлення, а не для повернення сервісів до роботи.

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

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

Вивід dpkg — це список встановлених ядер. Якщо в ньому лише один рядок, резервного варіанта немає. Саме це потрібно виправити насамперед.

Меню GRUB не з’являється. Що робити?

Хмарні образи містять конфігурацію, яка приховує меню. В образах Ubuntu тайм-аут часто встановлено в значення 0 у файлі в каталозі /etc/default/grub.d/, тому найновіше ядро запускається одразу, і натискати клавіші немає коли.

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

Виправте обидві проблеми, поки система працює. Відредагуйте /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

Потім застосуйте зміни та перевірте, що вони збереглися, оскільки файли в /etc/default/grub.d/ читаються після /etc/default/grub і можуть перевизначити ваші налаштування.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" виводить меню на графічну консоль і послідовний порт, тому воно відображається в будь-якому засобі перегляду, який надає ваша панель. Аргументи ядра console= так само виводять наступні повідомлення про завантаження. Десять секунд затримки під час кожного запуску — невелика плата за меню, до якого можна отримати доступ о 2:00 ночі.

Який клас збою виник?

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

GRUB не може знайти власні файли. Ви бачите запрошення grub rescue> або повідомлення про відсутній розділ чи файл, і повідомлення ядра взагалі не з’являються. Ядро ще не почало виконуватися. Такий збій зазвичай виникає після зміни диска або розділів чи запису завантажувача не на той пристрій, а не через сам пакет ядра.

Ядро запускається, але не може змонтувати root. Повідомлення ядра прокручуються, після чого ви потрапляєте в shell busybox із запрошенням (initramfs), або завантаження завершується panic через неможливість змонтувати root filesystem. Ядро завантажилося. initramfs, тобто невеликий тимчасовий root, який знаходить і монтує фактичний root filesystem, не знайшов диск. В Ubuntu цьому shell зазвичай передує повідомлення про припинення очікування root device із зазначенням потрібного UUID. Скопіюйте цей UUID і пізніше порівняйте його з виводом blkid.

Логічний том не з’являється. Це попередній клас збою з конкретною причиною. У запрошенні (initramfs) виконайте ls /dev/mapper. Якщо єдиним записом є control, жоден том LVM (logical volume manager) не активовано, тому root device ще не існує. Активуйте групи томів вручну:

lvm vgchange -ay
ls /dev/mapper
exit

exit передає керування назад скрипту initramfs, який повторює спробу монтування. Якщо після цього система завантажується, у новому initramfs відсутні компоненти LVM. Потрібно перебудувати цей образ, а не змінювати ядро.

Від Linux немає жодних повідомлень. Консоль показує текст firmware, shell UEFI (unified extensible firmware interface), порожній екран без виводу ядра або цикл перезавантажень. Збій відбувається до запуску Linux. Коли сервер знову запрацює, перевірте, який режим він фактично використовує, оскільки багато VPS працюють у режимі legacy BIOS і не використовують шлях EFI:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

Незмонтований /boot/efi під час оновлення є поширеною причиною на машинах з UEFI, оскільки пакети, які обслуговують EFI system partition, у такому разі записують дані до звичайного порожнього каталогу. Firmware продовжує запускати старий boot entry, доки цей запис не перестане відповідати вмісту диска.

Є ще один сценарій, який взагалі не є збоєм завантаження. Якщо ви потрапили в root shell із повідомленням, що система перебуває в emergency mode, ядро завантажилося, а userspace зупинився. Зазвичай причиною є неправильний рядок у /etc/fstab або filesystem, який не пройшов перевірку. Виконайте journalctl -xb у цьому shell і прочитайте назву unit, запуск якого завершився помилкою.

Пошкоджено пакет ядра чи initramfs?

На консолі ці проблеми виглядають однаково, але потребують різних способів виправлення. Завантажте старе ядро та порівняйте файли.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

Для кожної встановленої версії має бути один vmlinuz- і один відповідний initrd.img-, причому кожен файл повинен мати правдоподібний розмір. Відсутній initrd або файл, значно менший за сусідні, означає, що генерація initramfs завершилася помилкою. Зазвичай це спричиняє заповнений /boot. Підтвердження міститься в журналах пакетного менеджера:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log також точно показує, які пакети було встановлено під час останніх запусків і коли це сталося. Це усуває неоднозначність щодо внесених змін.

Якщо /boot заповнений, спочатку звільніть місце. Потім перебудуйте образ для потрібної версії та оновіть меню. Візьміть рядок версії з власного виводу ls, оскільки наведений нижче заповнювач не є реальною версією:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

Остання команда ls виконує перевірку. Файл нормального розміру означає, що образ тепер існує. Якщо пошкоджено сам образ ядра або dpkg -l показує для пакета будь-який стан, крім ii, перевстановіть пакет:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

Відновлення з rescue mode, якщо жодне ядро не завантажується

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

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

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

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

Задайте GRUB_DEFAULT=saved у /etc/default/grub, виконайте sudo update-grub, а потім виведіть назви записів, щоб указати одну з них точно:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list має вивести вибрану назву як saved_entry. Це підтверджує, що механізм працює, оскільки для збереження потрібен доступний для запису /boot/grub/grubenv, а в деяких конфігураціях це непомітно не так. Запис 0 — верхній пункт меню, тобто найновіше ядро. Тут безпечніше використовувати назви, а не номери, оскільки номери змінюються щоразу після встановлення або видалення ядра.

Чому autoremove небезпечний на headless-сервері

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

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

Цей файл генерується повторно щоразу, коли змінюються пакети ядра. Він захищає запущене ядро та найновіші ядра. Ризик пов’язаний із моментом виконання. Якщо запустити sudo apt autoremove --purge одразу після перезавантаження з новим ядром, захищений список уже оновлено. Старіше ядро, на яке ви розраховували, більше не захищене. На машині з клавіатурою це незручність. На headless-сервері це означає, що замість вибору пункту меню доведеться монтувати диск із rescue image.

Залишайте щонайменше два ядра. Якщо /boot має достатньо місця, залишайте три. Видаляйте старі ядра за іменем після перевірки uname -r. Так ви не зможете видалити ядро, під яким працює система:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

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

Створіть snapshot перед оновленням

Snapshot, створений перед apt upgrade, — це єдиний варіант відновлення, який не залежить від завантаження будь-чого. Після відновлення диск повертається до стану, у якому старе ядро було типовим, і ви можете повторити оновлення, не закриваючи консоль. Snapshot запущеної машини забезпечує crash consistency. Це означає, що диск зберігається в стані, ніби живлення було вимкнено. Тому спочатку вимкніть сервер, якщо ваш провайдер підтримує snapshot в offline-режимі. Snapshot також не є backup, оскільки зазвичай зберігається в тій самій інфраструктурі, що й том, копію якого він містить. Розуміння різниці між snapshot VPS і справжніми backup визначає, який варіант допоможе, якщо проблема виявиться серйознішою за помилку ядра.

Це особливо важливо під час оновлення release, коли за один запуск змінюються ядро, інструменти initramfs, bootloader і конфігурація GRUB. Створіть snapshot безпосередньо перед початком оновлення Ubuntu з 24.04 до 26.04, а не напередодні ввечері. Тоді точка відновлення відповідатиме стану машини безпосередньо перед змінами.

Як unattended-upgrades обробляє пакети ядра

Ubuntu's unattended-upgrades встановлює оновлення безпеки без запиту підтвердження, а пакети ядра надходять із security pocket так само, як і всі інші пакети. Це має два наслідки.

По-перше, нове ядро встановлюється, але не запускається. Ядро починає діяти лише після завантаження системи. З’являється файл /var/run/reboot-required, а /var/run/reboot-required.pkgs вказує, який компонент запросив перезавантаження, але система не перезавантажується, якщо ви не ввімкнули Unattended-Upgrade::Automatic-Reboot у /etc/apt/apt.conf.d/50unattended-upgrades.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

По-друге, цей проміжок приховує причину проблеми. Сервер може встановити ядро в березні, а в червні перезавантажитися з зовсім іншої причини й після цього не запуститися. Зміна, яка спричинила збій завантаження, сталася три місяці тому, тому того дня ви не побачите пояснення проблеми. У /var/log/apt/history.log можна знайти запуск, під час якого було встановлено ядро, на якому система тепер не запускається.

Перезавантажуйте сервер навмисно, у вибраний вами день, коли консольне вікно вже відкрите. Ця проста звичка перетворює незрозумілий простій на вибір пункту в меню, що займає дві хвилини. Якщо потрібна автоматизація без несподіваного перезавантаження, залиште автоматичне встановлення ввімкненим, а автоматичне перезавантаження вимкненим. Точні параметри наведено в матеріалі як налаштувати unattended-upgrades в Ubuntu. Утримання пакетів ядра за допомогою sudo apt-mark hold linux-image-generic повністю блокує їхнє встановлення, а разом із ним — і оновлення безпеки ядра. Тому сприймайте це як усвідомлений компроміс, а не як засіб безпеки.

FAQ

Як завантажити старіше ядро на VPS без клавіатури?

Відкрийте консоль провайдера (VNC або serial) і виконайте жорстке перезавантаження в панелі керування, оскільки ви не можете увійти в систему, щоб коректно її перезавантажити. Під час перезапуску кілька разів натискайте Esc або утримуйте Shift під час завантаження через legacy BIOS, щоб відкрити меню GRUB. Виберіть "Advanced options for Ubuntu", а потім запис під найновішим ядром. Після появи запиту на вхід виконайте uname -r, щоб перевірити активне ядро, і dpkg -l 'linux-image-*', щоб переглянути інші встановлені ядра. Виконуйте діагностику лише після відновлення роботи системи.

Чому на моєму VPS взагалі не відображається меню GRUB?

У хмарних образах часто встановлено тайм-аут GRUB, що дорівнює 0, у файлі в каталозі /etc/default/grub.d/, тому найновіше ядро запускається без очікування натискання клавіші. Установіть GRUB_TIMEOUT=10 і GRUB_TIMEOUT_STYLE=menu у /etc/default/grub, додайте GRUB_TERMINAL="console serial", щоб меню також було доступне через serial console, а потім виконайте sudo update-grub. Перевірте результат за допомогою grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, оскільки файли в цьому каталозі читаються після основного файлу та можуть перевизначити ваші зміни.

Чи слід видалити старі ядра, щоб звільнити місце в /boot?

Видаліть найстаріші ядра та залиште щонайменше два. Переповнення /boot є окремою причиною збою, оскільки тоді не вдається створити initramfs, і ви залишаєтеся з ядром без робочого образу. Видаляйте пакети за точними іменами після перевірки uname -r, щоб активне ядро ніколи не стало кандидатом на видалення. Не використовуйте безумовний sudo apt autoremove --purge на машині без локальної клавіатури та екрана, оскільки список захищених ядер перебудовується після кожної зміни ядра, а невчасний запуск може залишити лише одне ядро без резервного запису в меню.

Чи можуть unattended-upgrades порушити завантаження системи?

Вони можуть встановити ядро, яке згодом не завантажиться, але не перезавантажують машину, якщо в /etc/apt/apt.conf.d/50unattended-upgrades не встановлено Unattended-Upgrade::Automatic-Reboot у значення true. Типовий сценарій — відкладений збій: ядро встановлюється під час автоматичного запуску, з’являється /var/run/reboot-required, а проблема виявляється лише під час наступного перезавантаження через кілька тижнів. Навмисно перезавантажуйте систему, заздалегідь відкривши консоль, і перегляньте /var/log/apt/history.log, щоб визначити, який запуск встановив ядро, з якого ви завантажуєтеся.