Linux-сервер не загружается: сначала консоль гипервизора, не fsck вслепую

Короткий ответ

Не запускайте fsck и не жмите «repair disk» в панели гипервизора, пока не зафиксировали, на каком этапе остановилась загрузка: прошивка, GRUB, initramfs, emergency.target или уже multi-user, но нет сети/SSH. Данные обычно целы; ломают их повторные «чинки» суперблока и запись в том, который гипервизор открыл дважды.

Рабочая последовательность на Ubuntu 22.04 LTS и Ubuntu 24.04 LTS: консоль BMC/гипервизора → меню GRUB → journalctl -xb в emergency/rescue → blkid и /etc/fstab → только потом ремонт ФС на размонтированном томе с копией критичных данных. Цель — вернуть загрузку, сохранив данные на дисках, а не получить «чистую» ФС ценой потерянных inode.

Узел в примере: host.example, адрес 10.0.20.10, локальный администратор admin. Подставьте свои имена.

Симптомы и как отличить

Типичная картина «сервер не загружается»:

• ping на 10.0.20.10 молчит, SSH admin@host.example не открывается, а в консоли гипервизора крутится текст ядра или приглашение GRUB;
• после логотипа прошивки — Gave up waiting for root file system и (initramfs);
• Welcome to emergency mode и запрос пароля root для maintenance;
• цикл reboot каждые 10–30 секунд (watchdog гипервизора или Restart= у критичного unit).

Отличия:

Возможные причины

От более частых к редким:

1. После клонирования VM или замены диска UUID в /etc/fstab и root= в GRUB не совпадают с фактическим blkid.
2. Дополнительный диск из fstab недоступен (iSCSI/NFS/LVM не собрался) — systemd ждёт local-fs.target и уходит в emergency.
3. Повреждён initramfs: нет нужного модуля virtio/nvme, после смены типа диска в гипервизоре корень не находится.
4. Заполнен / или /boot — GRUB не записывает, ядро не распаковывает initrd, либо emergency из‑за невозможности писать журналы.
5. Неудачный update-grub / смена GRUB_CMDLINE_LINUX (удалили console=, повесили quiet splash на headless).
6. Редко: мёртвый диск, read-only LUN, сломанный RAID1 без второго плеча. Тогда цель — снимок и копия, не «ещё один fsck».

Диагностика

Работайте с консоли гипервизора или IPMI. SSH на этом этапе обычно мёртв.

1. Зафиксируйте экран и не перезагружайте пачкой

Сфотографируйте или скопируйте последние 30 строк. Нужны буквальные строки: UUID=... does not exist, Timeout waiting for device, Cannot open access to console, номер kernel panic. Перезагрузка стирает кольцевой буфер, если нет persistent journal на отдельном /var.

2. Меню GRUB

На Ubuntu Server меню часто скрыто. На экраке GRUB держите Shift (BIOS) или Esc (UEFI). Выберите «Advanced options» → строку с recovery или обычное ядро, но нажмите e и посмотрите root=.

Ожидание: root=UUID=<тот же UUID, что у корневого раздела>. Если там /dev/sda2, а в новой VM диск стал /dev/vda, ядро не найдёт корень.

Временный параметр для диагностики (только текущая загрузка, не пишется на диск):

# в редакторе GRUB добавьте в конец строки linux:
systemd.unit=rescue.target

3. initramfs: нет корневого устройства

Если видите (initramfs):

cat /proc/cmdline
blkid
ls /dev/disk/by-uuid
ls /dev/mapper
lvm vgchange -ay

Сравните UUID из cat /proc/cmdline с blkid. Если том LVM не активен — сначала vgchange, не fsck. Если диск вообще не виден в /dev — проблема гипервизора/HBA, не Ubuntu.

4. emergency / rescue

После пароля root (на многих облачных образах root заблокирован — грузитесь с live ISO или через GRUB init=/bin/bash):

hostnamectl
systemctl list-units --failed
journalctl -xb -p err --no-pager | tail -n 80
findmnt --verify --verbose
cat /etc/fstab
blkid
df -h
df -i

findmnt --verify на Ubuntu 22.04/24.04 прямо указывает на битый UUID и на опции, которые systemd не может выполнить. df -h на корне, смонтированном ro, всё равно покажет заполненность: 100% на / объясняет обрыв обновления ядра.

Связь с сервисами: если машина доходит до multi-user, но «не загружается» с точки зрения мониторинга — это уже systemd-сервис не запускается, не этот сценарий.

5. Live ISO, если корень не монтируется

Загрузите Ubuntu 22.04/24.04 live (той же major, что сервер), не устанавливайте систему.

lsblk -o NAME,UUID,FSTYPE,SIZE,MOUNTPOINT
mkdir -p /mnt/root
mount /dev/vda2 /mnt/root
mount /dev/vda1 /mnt/root/boot
# UEFI:
mount /dev/vda15 /mnt/root/boot/efi
chroot /mnt/root

Перед chroot смонтируйте /proc /sys /dev. Снимайте копию /etc/fstab, /boot/grub/grub.cfg, вывод blkid в заявку.

Решение

Сценарий A. Неверный UUID в fstab или GRUB

С live или из rescue сравните:

blkid
grep -v '^#' /etc/fstab
grep -E 'linux\s' /boot/grub/grub.cfg | head

Исправьте /etc/fstab на UUID из blkid. Для дисков, без которых сервер должен грузиться (бэкап, архив), добавьте nofail,x-systemd.device-timeout=10. Затем:

update-grub
update-initramfs -u -k all

На 24.04 update-initramfs тот же. Не меняйте GRUB_DISABLE_OS_PROBER ради «ускорения», если это не ваша цель.

Сценарий B. Initramfs без virtio/nvme

После смены типа диска в Proxmox/VMware:

lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'virtio|nvme|ahci'

Если модулей нет — в chroot update-initramfs -u. Проверьте /etc/initramfs-tools/modules.

Сценарий C. Корень заполнен, GRUB/apt оборвались

Освободите место без удаления /home и баз:

du -xhd1 / | sort -h
journalctl --disk-usage
journalctl --vacuum-size=200M
apt-get clean

Подробнее: закончился диск. После появления свободных гигабайт завершите оборванный linux-image через dpkg --configure -a уже после успешной загрузки.

Сценарий D. Подозрение на повреждение ФС

Только если journal показывает EXT4-fs error / I/O error и том размонтирован:

Полный разбор — в ошибках ext4. Здесь достаточно: не чините суперблок с форума по смещению «наугад».

Сценарий E. Ядро паникует сразу

Выберите в GRUB предыдущий linux-image. На Ubuntu ядра копятся, пока не сработает autoremove. Если в GRUB одно ядро — не ставьте новое с полуживого chroot без сети и зеркала; сначала сеть в live.

Как проверить, что проблема устранена

С консоли после reboot:

systemctl is-system-running
systemctl list-jobs
findmnt /
cat /proc/cmdline
ip -br addr
ss -tlnp | grep -E ':22|:22 '
timedatectl

Ожидание: running или degraded с понятным списком failed unit, не initializing. Корень rw. SSH слушает — тогда с рабочей станции:

ssh -o ConnectTimeout=8 admin@10.0.20.10 'uptime; findmnt -n -o OPTIONS /'

Функциональный тест сервиса, ради которого живёт узел (nginx, postgres, доменный клиент), обязателен. Зелёный is-system-running без приложения ничего не доказывает.

Если не помогло

• Консоль гипервизора чёрная до GRUB: проверьте boot order UEFI, Secure Boot vs самоподписанный grub, не тот диск в VM.
• Диск не виден в live: storage, thin pool, LUN mapping — не ОС.
• Emergency каждый раз из‑за NFS в fstab: перенесите в _netdev или systemd .mount с After=network-online.target.
• После «успешного» fsck приложения не стартуют: смотрите systemd-сервис и permission denied.
• Цикл OOM на раннем старте: OOM Killer.

Профилактика

• В fstab только UUID; некорневые тома — nofail или отдельный mount unit.
• Два ядра в GRUB, мониторинг свободного места / и /boot.
• Консоль гипервизора и serial console=ttyS0 в GRUB_CMDLINE_LINUX, не только SSH.
• Снимок VM до dist-upgrade ядра; снимок не заменяет backup данных.
• После смены типа диска в гипервизоре — обязательный update-initramfs -u на ещё живой системе.

FAQ

Можно ли просто нажать «repair» в панели VMware/Proxmox?

Нет. Мастер часто запускает fsck без вашего контроля и без копии. Сначала снимок и чтение journal.

Нужен ли пароль root в emergency, если вхожу как admin?

На Ubuntu recovery цель sulogin. Если root заблокирован (passwd -l root), задайте его с live через chroot и passwd, либо используйте rw init=/bin/bash один раз.

update-grub безопасен на полуживом корне?

В chroot с правильно примонтированными /boot и EFI — да. Без /boot вы запишете конфиг не туда.

Почему ping есть, а «сервер не загрузился» по мониторингу?

Ядро подняло сеть из initramfs или cloud-init, а default.target не достигнут. Смотрите systemctl list-jobs.

Стоит ли удалять старые ядра, чтобы точно загрузилось одно?

Нет. Оставьте минимум два. Чистите только после подтверждённой загрузки нового.