Skip to content
VDS · Вирішення проблем

Ядро впало: kernel panic і що далі

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

Оновлено 23 серпня 2026 р.

Kernel panic — це стан, коли ядро зупинилося й не може продовжити роботу. Машина не відповідає ні через SSH, ні по мережі, але досі відображається як запущена. Усе потрібне для діагностики доступне з панелі: консоль показує повний екран, а диск відновлення дає доступ до системних файлів.

Крок 1. Прочитайте повідомлення

Відкрийте /hosting/vds/m/<id>, вкладку «Консоль», подання «Екран» (VNC). Текстова консоль також показує вивід ядра, але паніку часто малює графічний буфер, і надійніше її видно саме на «Екрані». Важливий не перший рядок, а найнижчий змістовний, зазвичай один із:

  • VFS: Unable to mount root fs on unknown-block(0,0) — ядро не знайшло кореневий розділ;
  • Kernel panic - not syncing: Attempted to kill init — процес номер один загинув, найчастіше через пошкоджений /sbin/init після невдалого оновлення;
  • Kernel panic - not syncing: No working init found — та сама проблема;
  • помилка драйвера зі стеком викликів — зазвичай після встановлення стороннього модуля ядра.

Сфотографуйте або відразу скопіюйте текст: після перезавантаження екран очиститься.

Крок 2. Спробуйте попереднє ядро

Якщо паніка з'явилася відразу після оновлення, у GRUB залишилося старе ядро. Перезавантажте машину з панелі та встигніть натиснути в меню на «Екрані»: натисніть Shift або Esc у перші секунди, далі «Advanced options» і попередню версію.

Завантажившись зі старим ядром, зафіксуйте робочий стан і розберіться з новим пакетом:

uname -r
dpkg -l | grep linux-image
apt install --reinstall linux-image-amd64

Крок 3. Диск відновлення

Якщо меню завантажувача не з'являється або старе ядро теж падає, увімкніть режим завантаження «Диск відновлення SystemRescue» на вкладці «Доступ» і перезавантажте машину. Увійдіть як root без пароля; диск машини з'явиться як /dev/sda.

lsblk
mount /dev/sda1 /mnt
ls /mnt

Перевірте файлову систему, якщо підозрюєте пошкодження:

umount /mnt
fsck -f /dev/sda1

Типова причина паніки після ручних правок — помилка в /etc/fstab: рядок із неіснуючим розділом або неправильний UUID зупиняє завантаження. Перевірте його:

blkid /dev/sda1
cat /mnt/etc/fstab

Щоб працювати всередині системи (перевстановити ядро, відредагувати завантажувач), увійдіть до неї через chroot:

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

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

Крок 4. Коли перевстановлення простіше

Автоматичних резервних копій машин і знімків стану в нас немає, тож рішення за вами. Якщо на диску є цінні дані, спершу скопіюйте їх із SystemRescue через scp на власну машину, і лише потім запускайте перевстановлення ОС із вкладки «Доступ» — воно повністю стирає диск.

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

Як не повторити це

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