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

Что делать в первую очередь, если VPS не загружается после обновления ядра

Если VPS не загружается после обновления ядра, проблему обычно можно устранить за несколько минут, так как обновление не удаляет ядро, которое работало вчера. Ubuntu устанавливает новое ядро параллельно со старым и меняет только запись, которую GRUB запускает по умолчанию. Поэтому первым действием будет не восстановление системы. Выберите предыдущее ядро в меню загрузки, получите доступ к приглашению входа в систему, а затем проводите диагностику из работающей ОС.

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

Прочитайте содержимое консоли перед тем, как что-либо менять. Текст на экране определяет тип сбоя, и два сервера, которые «не загружаются», могут потребовать противоположных действий для исправления.

Как получить доступ к консоли, если SSH недоступен?

Откройте панель управления вашего провайдера и найдите раздел консоли. Обычно она называется VNC console, web console, noVNC или serial console. Если доступны оба варианта, выбирайте serial console: она предоставляет текстовый вывод, который можно прокручивать и копировать, в то время как VNC — это лишь графическое изображение экрана. Найдите этот инструмент сейчас, пока сервер исправен, и убедитесь, что он работает. Поиск консоли во время аварии лишает вас спокойствия, необходимого для устранения неполадок. Эту проверку следует выполнять в первые десять минут работы с новым VPS, наряду с настройкой правил firewall и SSH-ключей.

Большинство панелей также предлагают режим восстановления (rescue mode) или recovery image. Он загружает минимальную систему из сети провайдера и подключает ваш диск как дополнительное устройство, поэтому данные на диске не запускаются. Режим восстановления — это крайняя мера, если поврежден GRUB, а также способ скопировать данные с сервера, который вы решили не восстанавливать.

Обычно для доступа к меню загрузки требуется принудительная перезагрузка (hard reset) через панель управления, так как вы не можете выполнить sudo reboot на машине, к которой нет доступа. Hard reset равносилен отключению питания. Файловые системы при этом завершают работу некорректно, поэтому при следующей загрузке ожидайте автоматическую проверку целостности файловой системы.

Как выбрать старую версию ядра в меню GRUB?

Следите за консолью с момента нажатия кнопки сброса. Нажимайте Esc несколько раз в течение первых секунд или удерживайте Shift на машине, загружающейся в режиме legacy BIOS. Окно загрузки короткое, а консоль часто подключается с задержкой, поэтому начинайте нажимать клавишу заранее и продолжайте это делать.

Когда появится меню, выберите "Advanced options for Ubuntu". В этом подменю перечислены все установленные ядра, начиная с самого нового, а также режим восстановления (recovery mode) для каждого из них. Выберите вторую обычную запись — это ядро, предшествующее самому новому, и нажмите Enter. Режим восстановления — это другое: он загружает минимальную однопользовательскую систему и предназначен для ремонтных работ, а не для возвращения сервисов в рабочий режим.

Если старое ядро загрузилось, сервер снова в строю. Убедитесь, какая версия сейчас активна, и запишите её номер.

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= делают то же самое для последующих сообщений загрузки. 10 секунд задержки при каждой загрузке — небольшая цена за возможность получить доступ к меню в 2 часа ночи.

К какому классу относится сбой?

Изучите последние двадцать строк лога перед тем, как вывод на консоль прекращается. Четыре шаблона охватывают большинство ситуаций, возникающих после обновления ядра.

GRUB не может найти свои файлы. Вы видите приглашение grub rescue> или ошибку о том, что раздел или файл не существует, при этом сообщения ядра не появляются. Ядро ещё не задействовано. Это происходит из-за изменений в дисках или разделах, либо из-за записи загрузчика не на то устройство, а не из-за самого пакета ядра.

Ядро запускается, но не может смонтировать корневую файловую систему. Сообщения ядра прокручиваются, после чего вы попадаете в оболочку busybox с приглашением (initramfs), либо загрузка завершается паникой из-за невозможности смонтировать корень. Ядро загрузилось. Initramfs — небольшая временная корневая система, которая находит и монтирует реальный корень — не обнаружила диск. В Ubuntu перед этим обычно выводится сообщение об ожидании корневого устройства с указанием нужного UUID. Скопируйте этот UUID и сравните его с выводом blkid позже.

Логический том не появляется. Это частный случай предыдущей проблемы с конкретной причиной. В приглашении (initramfs) выполните ls /dev/mapper. Если в списке только control, значит, тома LVM (logical volume manager) не были активированы, поэтому корневое устройство ещё не существует. Активируйте группы томов вручную:

lvm vgchange -ay
ls /dev/mapper
exit

exit возвращает управление скрипту initramfs, который повторно пытается выполнить монтирование. Если после этого система загружается, значит, в новом образе initramfs отсутствуют компоненты LVM. Решение заключается в пересборке образа, а не в изменении ядра.

Ничего не происходит. На консоли отображается текст прошивки, оболочка 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, в этом случае записывают данные в обычную пустую директорию. Прошивка продолжает использовать старую запись загрузки, пока она не перестанет соответствовать содержимому диска.

Ещё один сценарий вообще не является сбоем загрузки. Если вы попадаете в корневую оболочку с сообщением о переходе системы в аварийный режим (emergency mode), значит, ядро загрузилось, но пространство пользователя остановилось. Обычно это означает наличие ошибочной строки в /etc/fstab или сбой проверки файловой системы. Выполните 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, если ядро не загружается

Если ни один пункт меню не работает, загрузите образ rescue от провайдера и восстановите диск извне. Ваш диск будет представлен как несмонтированное устройство, поэтому никакие процессы на нем не запущены и не будут препятствовать работе.

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 опасна на сервере без монитора

APT хранит список пакетов ядер, которые нельзя удалять автоматически. Просмотрите свой список:

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

Этот файл пересоздается при каждом изменении пакетов ядра и защищает текущее ядро, а также самые последние версии. Опасность заключается в таймингах. Если запустить sudo apt autoremove --purge сразу после перезагрузки в новое ядро, список защищенных пакетов обновится, и старое ядро, на которое вы рассчитывали, перестанет быть защищенным. На компьютере с подключенной клавиатурой это доставит неудобства. На headless-сервере это разница между выбором пункта в меню загрузчика и необходимостью монтировать диск из rescue-образа.

Держите минимум два ядра, а если позволяет место — три, как указано в /boot. Удаляйте старые ядра по имени после проверки uname -r, чтобы гарантированно не удалить то, которое используется в данный момент:

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

После этого снова выполните последнюю команду. Если счетчик уменьшился с трех до двух — это штатная очистка. Если счетчик уменьшился до одного — это риск сбоя при следующей перезагрузке.

Создание снимка перед обновлением

Снимок, созданный перед apt upgrade, является единственным способом восстановления, не требующим загрузки системы. Его восстановление возвращает диск в состояние, когда старое ядро было основным, что позволяет повторить обновление с уже открытой консолью. Снимки работающей машины являются crash-consistent: они фиксируют состояние диска так, будто питание было внезапно отключено. Поэтому, если ваш провайдер поддерживает создание офлайн-снимков, сначала выключите сервер. Снимок не является полноценной резервной копией, так как обычно хранится на той же инфраструктуре, что и исходный том. Понимание разницы между снимками VPS и реальными резервными копиями определяет, что именно спасёт вас в случае сбоя, масштаб которого превышает проблемы с ядром.

Это особенно важно при обновлении релиза, когда за один проход меняются ядро, инструменты initramfs, загрузчик и конфигурация GRUB. Создавайте снимок непосредственно перед началом обновления Ubuntu 24.04 до 26.04, а не накануне, чтобы точка восстановления соответствовала состоянию машины, которую вы собираетесь изменить. Если обновление ещё не предлагается на вашем сервере, причина заключается в графике выпуска, а не в ошибке настройки, так как переход между LTS-версиями открывается только после выхода первого точечного релиза, 26.04.1.

Как unattended-upgrades обрабатывает пакеты ядра

Пакет unattended-upgrades в Ubuntu устанавливает обновления безопасности автоматически, и пакеты ядра поступают через репозиторий security, как и все остальные обновления. Из этого следуют два последствия.

Во-первых, новое ядро устанавливается, но не запускается. Ядро начинает действовать только после загрузки системы. Появляется файл /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 или последовательный порт) и выполните принудительную перезагрузку через панель управления, так как корректно завершить работу системы невозможно. Во время запуска машины нажимайте 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", чтобы меню также выводилось в последовательную консоль, а затем выполните 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, чтобы определить, какой именно сеанс обновления установил ядро, с которым возникли проблемы.