Загрузка Ubuntu Server в аварийный режим: пошаговое руководство по восстановлению.

Показательный сценарий: Кейси обслуживает гипотетическую виртуальную машину Ubuntu Server, которая после перезагрузки переходит в аварийный режим вскоре после добавления дополнительного монтирования тома данных /etc/fstab. У Кейси есть доступ к консоли, но нет SSH-сессии. Изменение монтирования — это лишь зацепка, а не доказанная причина: аварийный режим может возникать после нескольких сбоев загрузки, поэтому Кейси проверяет журналы текущей машины, прежде чем что-либо менять. Приведенные ниже панели терминала показывают примерные схемы и заглушки вывода, а не реальный ремонт или тестирование.

Что означает аварийный режим

В Ubuntu Server, использующей systemd, emergency.targetзапускается минимальная оболочка на главной консоли. Она более ограничена, чем rescue.target, которая запускает базовую систему и системные монтирования только с необходимыми службами. В зависимости от пути в аварийный режим, корневая файловая система может быть уже смонтирована только для чтения или для чтения и записи. Проверьте это, вместо того чтобы предполагать какое-либо из состояний. См. документацию по специальной цели systemd в исходном коде .

Сначала определите приглашение командной строки. В аварийной оболочке systemd обычно отображается сообщение «Добро пожаловать в аварийный режим!» и может запрашиваться пароль root для обслуживания. Приглашение BusyBox, например, (initramfs)означает, что загрузка еще не переключилась на установленную корневую файловую систему; приглашение grub>или grub rescue>указывает на проблему с загрузчиком. Для восстановления требуются разные пути. Если учетная запись root заблокирована или сервер удаленный, используйте последовательную/VNC-консоль или среду восстановления хостинг-провайдера; SSH обычно недоступен на этом этапе. Не нажимайте Ctrl+D для продолжения, пока не поймете и не устраните обнаруженную ошибку.

Пошаговое спасение

1. Сохраните доступ к консоли и зафиксируйте точную причину сбоя.

Оставайтесь в аварийной консоли. Запишите последнее неудачное монтирование или имя службы, а также любой путь к устройству или UUID, отображаемые над приглашением командной строки. fstabСтоит проверить недавние правки Кейси, но не комментируйте каждую строку, вызвавшую ошибку, и не запускайте команду восстановления, основываясь только на слове «аварийный». Если система является виртуальной машиной, держите консоль поставщика открытой во время восстановления и следующей перезагрузки.

2. Прочитайте текущий журнал загрузки и информацию о неисправных устройствах.

В аварийной оболочке выполните:

journalctl -xb -p err --no-pager
systemctl --failed --no-pager

-bОграничивает запрос журнала только этой загрузкой и -p errфильтрует по приоритету ошибок и выше. Ищите первую релевантную ошибку, а не просто последнюю серию сообщений «сбой зависимости». Если монтирование не удалось, запишите его экранированное имя монтирования и целевой путь; если служба не сработала, определите, является ли это причиной или лишь следствием отсутствия монтирования. journalctl(1)В руководстве Ubuntu описана фильтрация загрузок и монтирования монтированных модулей.

3. Проверьте корневой каталог и доступное пространство.

Перед редактированием файлов или попыткой восстановления проверьте, как смонтирована корневая файловая система и не закончились ли в системе блоки или иноды:

findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /

В findmntвыводе roозначает режим только для чтения, а rwозначает режим чтения и записи. Режим только для чтения корневого каталога может быть преднамеренным на этапе восстановления или свидетельствовать о проблемах с файловой системой. Не следует сразу же принудительно перемонтировать каталог в режиме чтения и записи, если в журналах ядра сообщается об ошибках ввода-вывода или файловой системы. Переполненная файловая система или исчерпанная таблица inode также могут привести к сбоям в работе несвязанных служб и монтировании. В findmnt(8)руководстве Ubuntu описано, как проверять смонтированные файловые системы.

4. Проверка /etc/fstabи подтверждение идентификаторов устройства.

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

findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify --verboseПроверяет записи в fstab на наличие проблем с разбором и удобством использования. Сравнивает каждую запись UUID=в подозрительной строке с UUID, отображаемым lsblk -fили blkid. Также проверяет точку монтирования, тип файловой системы и параметры. Скопированный UUID с другого диска, неподключенного устройства или недопустимый параметр могут помешать завершению необходимого монтирования. Не пытайтесь угадать раздел, например /dev/sda1; имена устройств могут меняться между загрузками.

5. Исправьте только подтвержденную проблему с креплением.

Если корневая файловая система доступна для записи и проверка fstab выявляет некорректную строку, сделайте резервную копию перед редактированием:

cp -a /etc/fstab /etc/fstab.before-rescue
nano /etc/fstab

Исправляйте UUID или другое поле только после подтверждения нужного устройства. Если монтирование действительно необязательно, и сервер должен загружаться даже при отсутствии этого тома, можно использовать строку fstab, поддерживающую systemd, nofailи ожидание с ограниченным временем ожидания устройства, например:

UUID=VERIFIED-UUID /srv/archive ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

Замените заполнитель на реальный UUID и используйте фактический тип файловой системы. Не добавляйте nofailв корневую, загрузочную или другие файловые системы, необходимые для корректной работы машины или ее приложений. При использовании этой опции nofailзагрузка продолжится, даже если монтирование не удастся, поэтому зависимые службы могут потребовать внимания. В руководстве по команде `systemd mount-unit` в Ubuntu описаны эти параметры fstab.

После редактирования еще раз проверьте данные, прежде чем пытаться выполнить монтирование:

findmnt --verify --verbose
systemctl daemon-reload
mount /srv/archive

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

6. Расследуйте сбой в работе сервиса только в том случае, если журнал указывает на него.

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

systemctl status example.service --no-pager
journalctl -u example.service -b --no-pager

Замените example.serviceна точное имя юнита. Проверьте, не отсутствует ли его конфигурационный файл, исполняемый файл, учетные данные или необходимый монтирование. Если сбой связан с отсутствующим томом данных Casey, сначала исправьте это монтирование, а затем повторно оцените работу службы. Отключение важной службы может скрыть симптом, оставив сервер непригодным для использования.

7. Рассматривайте ошибки файловой системы как задачу восстановления в автономном режиме.

Если в журнале ядра сообщается о повреждении файловой системы или ошибках ввода-вывода хранилища, по возможности прекратите запись и сохраните резервную копию или снимок поставщика перед восстановлением. Подтвердите точное устройство и файловую систему с помощью команды ` lsblk -f.`. Для корневой файловой системы загрузитесь в систему восстановления поставщика или на носитель восстановления/загрузочный носитель Ubuntu, убедитесь, что целевой раздел отмонтирован, и используйте средство проверки, подходящее для этой файловой системы. Для ext2/3/4 таким инструментом является e2fsck`; для XFS, Btrfs и других форматов действуют другие процедуры.

Никогда не запускайте fsckпроверку e2fsckфайловой системы, которая смонтирована, включая смонтированный корневой каталог только для чтения. В e2fsck(8)руководстве Ubuntu предупреждается, что проверка смонтированной файловой системы, как правило, небезопасна, а результаты недействительны. Если диск сообщает о повторяющихся ошибках ввода-вывода, отдайте приоритет восстановлению данных или обращению к поставщику услуг хранения, а не многократным попыткам восстановления.

8. Вернитесь к обычной загрузке и проверьте результат.

После устранения подтвержденной причины перезагрузите систему с консоли:

systemctl reboot

После запуска Ubuntu проверьте настроенный целевой объект по умолчанию, текущее состояние системы, неисправные модули и новую загрузку:

systemctl get-default
systemctl is-system-running
systemctl --failed --no-pager
journalctl -b -p err --no-pager
findmnt --verify --verbose

Если вы намеренно продолжаете загрузку в текущем режиме, systemctl defaultсистема запрашивает у systemd запуск настроенного целевого объекта по умолчанию. Используйте его только после устранения блокирующей ошибки; он не восстанавливает некорректное монтирование или поврежденную файловую систему. systemctl get-defaultОтображает настроенный целевой объект по умолчанию; systemctl is-system-runningсообщает, считает ли systemd текущее состояние работающим, ухудшенным или иным. Чистое восстановление означает, что ожидаемые файловые системы смонтированы, необходимые службы активны, и та же аварийная ситуация не повторяется после перезагрузки.

Если подсказка (initramfs)вместо этого

Не следует слепо применять шаги аварийной оболочки systemd в BusyBox initramfs. На этапе initramfs происходит попытка найти и смонтировать реальную корневую файловую систему, прежде чем передать управление установленной системе. Запишите точную ошибку, проверьте, отображается ли ожидаемое устройство в /devи /dev/disk/by-uuid, и сравните значение командной строки загрузки root=с фактическим UUID корневого каталога. Если диск или зашифрованный/LVM-том отсутствуют, используйте инструменты хранения и восстановления провайдера для их исследования. Пересборка initramfs или изменение параметров GRUB без идентификации отсутствующего устройства может затруднить восстановление загрузки.

Для гипотетической виртуальной машины Кейси полезным результатом является подтвержденная причина и узконаправленное исправление: восстановить ожидаемый необязательный том, исправить его подтвержденный идентификатор или настроить его как необязательный только в том случае, если рабочая нагрузка действительно это позволяет. Затем проверить следующую загрузку с консоли, прежде чем закрыть сеанс восстановления.