Сервер не грузится — single mode, rescue, chroot, fsck

3 утра. Pager. Production-сервер не грузится после обновления. Что делать? Спокойствие и набор стандартных техник восстановления: single user mode, systemd rescue.target, emergency.target, загрузка с LiveUSB и chroot в систему, fsck на повреждённые ФС. Это hands-on урок, который вытащит вас из 90% boot-инцидентов.

Прежде чем читать — убедитесь что у вас есть LiveUSB (Ubuntu Desktop, SystemRescue, или distro installer в Try mode). Без него на bare-metal вы беспомощны. Современные облака обычно дают rescue-режим через панель управления.

Decision tree: что делать в зависимости от симптома

Метод 1: Single user mode / rescue.target через GRUB

Самый быстрый метод — если GRUB ещё работает. На GRUB меню выбрать kernel, нажать e, отредактировать строку с linux ...:

linux /boot/vmlinuz-6.5.0-21-generic root=UUID=... ro quiet splash
                                                                  ^
                                                  Добавить здесь:
                                                  systemd.unit=rescue.target

Ctrl-X или F10 — загрузка с правкой.

Альтернативы (в порядке от меньшего к большему изоляции):

• single или systemd.unit=rescue.target — rescue.target. Базовые mount готовы, есть root shell. Можно запустить systemctl, посмотреть failed services.
• systemd.unit=emergency.target — ещё более минимально. Только / смонтирован, readonly. Нет network, других mount. Запасной вариант если rescue не работает.
• init=/bin/bash — пропустить systemd вообще. Запустится прямо bash как PID 1. Опасно: нет других сервисов, sigterm не работает.

После rescue/single:

# Mounted readonly -- сделать read-write для правок:
mount -o remount,rw /

# Посмотреть failed services:
systemctl --failed

# Узнать почему сервис fail:
journalctl -u problematic.service

# Отключить проблемный сервис:
systemctl disable problematic.service
systemctl mask problematic.service     # ещё надёжнее

# Проверить системные mounts:
mount

# Пометить fstab-ошибки:
cat /etc/fstab    # проверить корректность UUID

# Reboot:
systemctl reboot

Метод 2: Загрузиться с LiveUSB

Когда GRUB не работает или нужны более серьёзные правки. Готовый Linux USB-stick (Ubuntu Desktop ISO, SystemRescue, GParted Live) — обязательная вещь для админа.

Шаги:

1. Загрузиться с USB (через BIOS/UEFI boot menu — F12 или F8 при POST).
2. Выбрать “Try Ubuntu” / live-режим.
3. Открыть terminal.

В live-режиме у вас рабочий Linux в RAM, ваши диски не смонтированы. Можно безопасно править файлы, переустанавливать bootloader, делать fsck.

Метод 3: chroot в установленную систему

После загрузки LiveUSB — chroot позволяет работать “как будто внутри установленной системы”. Все команды (grub-install, update-grub, apt, passwd) увидят файлы вашей системы.

# Шаг 1. Найти root-раздел установленной системы:
sudo fdisk -l                # или lsblk -f
# Видим: /dev/nvme0n1p2 -- наш root

# Шаг 2. Смонтировать его:
sudo mount /dev/nvme0n1p2 /mnt

# Шаг 3. Если есть отдельный /boot -- смонтировать туда же:
sudo mount /dev/nvme0n1p1 /mnt/boot/efi    # для UEFI ESP
# или:
sudo mount /dev/nvme0n1p1 /mnt/boot         # для отдельного /boot

# Шаг 4. Привязать системные псевдо-ФС:
sudo mount --bind /dev /mnt/dev
sudo mount --bind /sys /mnt/sys
sudo mount --bind /proc /mnt/proc
sudo mount --bind /run /mnt/run             # важно для systemd-команд

# Шаг 5. Войти в chroot:
sudo chroot /mnt /bin/bash

# Теперь вы внутри установленной системы. uname, hostname -- ваши обычные.
# Можно делать:
update-grub
grub-install /dev/nvme0n1                   # BIOS
grub-install --target=x86_64-efi \
    --efi-directory=/boot/efi \
    --bootloader-id=ubuntu                  # UEFI

# Пересобрать initramfs:
update-initramfs -u -k all

# Установить отсутствующий пакет:
apt update && apt install -y package

# Сбросить пароль:
passwd root

# Выйти из chroot:
exit

# Отмонтировать (в обратном порядке):
sudo umount /mnt/run
sudo umount /mnt/proc
sudo umount /mnt/sys
sudo umount /mnt/dev
sudo umount /mnt/boot/efi    # или /mnt/boot
sudo umount /mnt

# Reboot из обычной системы:
sudo reboot

Метод 4: fsck — проверка и ремонт ФС

После hard reboot, power loss, или kernel-panic файловая система может быть в inconsistent state. Журналируемые ФС (ext4, xfs, btrfs) обычно восстанавливаются автоматически при mount (через журнал). Но если повреждение серьёзнее — mount фейлит, и нужен fsck.

# Проверить ФС (READONLY, на смонтированной можно):
sudo fsck -n /dev/sdaX

# Активный fsck -- ТОЛЬКО на ОТМОНТИРОВАННОЙ:
sudo umount /dev/sdaX
sudo fsck -y /dev/sdaX        # -y = yes на все вопросы
# Или для ext4 конкретно:
sudo e2fsck -fy /dev/sdaX

Ключевой момент: нельзя fsck на смонтированной ФС с правками — это разрушит ФС. На root-диске значит:

1. Загрузить LiveUSB.
2. НЕ монтировать root.
3. fsck /dev/sdaX напрямую.
4. После fsck успешно — reboot.

Альтернатива: forced fsck при следующем boot. Создать /forcefsck:

sudo touch /forcefsck
sudo reboot

systemd увидит этот файл и принудительно прогонит fsck до mount.

Что fsck может найти:

• Wrong block count — bitmap inconsistency.
• Inode without nlink — orphan inodes, перемещаются в /lost+found.
• Cross-linked blocks — два файла указывают на один блок (раздельный disaster).
• Bad superblock — основной superblock corrupt. e2fsck автоматически попробует backup superblocks.

# Узнать, где backup superblocks для ext4:
sudo dumpe2fs /dev/sdaX 2>/dev/null | grep -i superblock
# Backup superblock at 32768, Group descriptors at 32769-32769
# Backup superblock at 98304, Group descriptors at 98305-98305
# ...

# Использовать backup superblock:
sudo e2fsck -b 32768 /dev/sdaX

XFS немного другая:

# XFS check (read-only -- safe to attempt before unmount):
sudo xfs_repair -n /dev/sdaX

# XFS repair (после unmount):
sudo umount /dev/sdaX
sudo xfs_repair /dev/sdaX

Метод 5: Magic SysRq (последний шанс если система висит, но не упала)

Linux имеет hidden API в kernel — Magic SysRq Key. Когда система висит, но kernel ещё жив — можно через клавиатуру (физическую!) делать команды. На большинстве клавиатур это Alt+PrtScr+key.

# Включить (если отключено):
echo 1 > /proc/sys/kernel/sysrq
# Или постоянно в /etc/sysctl.d/99-sysrq.conf:
kernel.sysrq = 1

# Использование (физическая клавиатура):
Alt + SysRq + s      # sync -- сбросить грязные страницы на диск
Alt + SysRq + u      # umount-readonly -- переключить все mounts в RO
Alt + SysRq + b      # reBoot -- немедленный reboot

Известная мнемоника REISUB для безопасной перезагрузки висящей машины (в порядке):

• R — raw keyboard (вернуть к kernel)
• E — terminate (SIGTERM всем процессам)
• I — kill (SIGKILL всем)
• S — sync (записать буферы на диск)
• U — umount (replant ФС в RO)
• B — reboot

Это спасает от потери данных при висящей системе по сравнению с hard power-off.

Метод 6: Сетевой recovery (для удалённых серверов)

Если сервер удалённый и SSH не работает — нужен out-of-band доступ:

• IPMI/iDRAC/iLO (Dell, HP, Supermicro) — виртуальная KVM через web. Можно работать как с физическим терминалом, монтировать virtual media (.iso образы).
• Cloud rescue mode — AWS, GCP, Azure имеют rescue/recovery в Console. Загружают вашу VM в minimal-режиме с доступом по SSH к новому root, оригинальная rootfs смонтирована как secondary disk.
• Console через serial — если в kernel cmdline было console=ttyS0,115200, через провайдер виден serial console. На AWS это aws ec2 get-console-output.

Real-world recovery scenarios

Сценарий 1: “/etc/fstab сломан, mount фейлит, emergency mode”.

# В emergency mode:
mount -o remount,rw /
vim /etc/fstab               # закомментировать проблемную строку
exit                         # выйти из emergency, продолжить boot

Сценарий 2: “Сбросить root password”.

# В GRUB добавить: init=/bin/bash
# Загрузиться. Будет shell с /, смонтированным readonly.
mount -o remount,rw /
passwd root                  # ввести новый пароль
mount -o remount,ro /
exec /sbin/init              # или reboot -f

Сценарий 3: “Удалил критичный пакет через apt, система не грузится”.

# LiveUSB chroot:
sudo mount /dev/sdaX /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /sys /mnt/sys
sudo mount --bind /proc /mnt/proc
sudo chroot /mnt
apt install --reinstall <package>
exit
sudo umount -R /mnt
sudo reboot

Сценарий 4: “Sudo сломан, root password не помню”.

# В GRUB добавить: init=/bin/bash
mount -o remount,rw /
usermod -aG sudo myuser
# или прямо:
echo 'myuser ALL=(ALL) NOPASSWD: ALL' > /etc/sudoers.d/recovery
chmod 0440 /etc/sudoers.d/recovery
mount -o remount,ro /
exec /sbin/init

Профилактика: что подготовить ЗАРАНЕЕ

1. LiveUSB всегда под рукой. Ubuntu Desktop + SystemRescue на одной флешке (через Ventoy).
2. Снапшоты VM перед kernel-upgrade. На bare-metal — хотя бы /boot бэкап.
3. GRUB_TIMEOUT >= 5s. В /etc/default/grub. Чтобы успеть нажать Esc/Shift.
4. Persistent journal. Для analysis после reboot (что говорил kernel в момент failure).
5. Тестовый дebrowse rescue. Раз в полгода — попробуйте chroot в свою систему, restoring GRUB. Не паникуйте впервые в 3 утра.
6. Документировать UUID и mount points. lsblk -f > ~/system-layout.txt — сохранить где-то вне сервера.

Попробуй сам (на VM, НЕ на production!)

# Безопасная тренировка через VM:

# 1. Создать VM с Ubuntu, snapshot. Сломать /etc/fstab:
#    sudo sed -i 's|UUID=|UUID=bogus_|' /etc/fstab
#    sudo reboot
# Восстанавливать через rescue.target.

# 2. После rescue:
mount -o remount,rw /
vim /etc/fstab     # вернуть правильно
# или восстановить из бэкапа:
cp /etc/fstab.bak /etc/fstab
exit               # выйти из rescue

# 3. Тренировка chroot через LiveUSB:
# Загрузиться с Ubuntu LiveUSB
# Открыть terminal
# Выполнить полную процедуру chroot (как выше)
# update-grub внутри chroot
# Это безопасная rehearsal без последствий

# 4. systemd-analyze для понимания, что грузится:
systemd-analyze
systemd-analyze blame | head
systemd-analyze critical-chain | head -20

# 5. Test fsck без unmount (только проверка):
sudo fsck -n /     # readonly check current root