VPS не завантажується після оновлення kernel

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

VPS, який не завантажується після оновлення kernel, зазвичай можна відновити за кілька хвилин, оскільки оновлення не видалило kernel, який працював учора. Ubuntu встановлює новий kernel поруч зі старим і змінює лише запис, який 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". Це підменю містить усі встановлені ядра, починаючи з найновішого, а також запис recovery mode для кожного ядра. Виберіть другий звичайний запис — ядро, яке передує найновішому, — і натисніть Enter. Recovery mode — це інший режим: система завантажується в мінімальне однокористувацьке середовище. Він призначений для відновлення, а не для повернення сервісів до роботи.

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

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

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

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

Хмарні образи містять конфігурацію, яка приховує меню. В образах Ubuntu зазвичай встановлено значення timeout 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-й ночі.

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

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

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

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

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

lvm vgchange -ay
ls /dev/mapper
exit

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

У Linux взагалі немає повідомлень. На консолі відображається текст firmware, оболонка 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 у цій оболонці та прочитайте назву 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-consistent. Це означає, що він фіксує диск так, ніби живлення було вимкнено. Тому спочатку вимкніть сервер, якщо ваш провайдер підтримує offline snapshot. Snapshot також не є backup, оскільки зазвичай зберігається в тій самій інфраструктурі, що й том, копією якого він є. Розуміння різниці між snapshot VPS і справжніми backup визначає, який варіант допоможе, якщо проблема виявиться серйознішою за збій ядра.

Це особливо важливо під час оновлення release, коли ядро, інструменти initramfs, bootloader і конфігурація GRUB змінюються за один запуск. Зробіть snapshot безпосередньо перед початком оновлення Ubuntu з 24.04 до 26.04, а не напередодні ввечері, щоб точка відновлення відповідала машині, яку ви збираєтеся змінити. Якщо це оновлення ще не доступне на вашому сервері, причина полягає в графіку доступності, а не в несправній конфігурації, оскільки перехід з однієї LTS-версії на іншу відкривається лише на першому point release, 26.04.1.

Як 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 порушити завантаження системи?

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