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

После обновления или отключения питания ваш Ubuntu Server перезагружается, а затем останавливается на сообщении «Вход в аварийный режим». SSH недоступен, службы отключены, и консоль запрашивает обслуживание. Обычно это означает, что systemd не смог выполнить необходимый этап загрузки, часто из-за сбоя проверки файловой системы или отсутствия необходимого места монтирования. Воспринимайте это сообщение как подсказку: определите неисправный модуль, прежде чем редактировать файлы или запускать команду восстановления.

Данное руководство относится к стандартным установкам Ubuntu Server с использованием systemd. Команды и меню загрузки могут отличаться в Ubuntu Core, зашифрованных системах, облачных образах и серверах, управляемых провайдером. В текущих справочных страницах Ubuntu emergency.target описывается как минимальная оболочка, которая не запускает обычные службы и не монтирует обычные файловые системы; в зависимости от способа доступа к корневой файловой системе, она может быть доступна только для чтения или для чтения и записи. Именно поэтому первыми шагами являются проверка и резервное копирование.

1. Прежде чем что-либо менять, ознакомьтесь с описанием неисправности.

При появлении запроса войдите в систему через локальную консоль или консоль провайдера. На физическом компьютере подключите клавиатуру и монитор; на виртуальном сервере используйте последовательную консоль или консоль восстановления провайдера. Сфотографируйте или скопируйте полное сообщение об ошибке, особенно имя юнита, например, systemd-fsck@dev-disk-by-uuid-....serviceили юнит монтирования, заканчивающийся на .mount. Отсутствие UUID, неудачная проверка файловой системы и неработающая служба требуют разных способов исправления.

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

systemctl --failed
journalctl -xb

Ищите первую значимую ошибку, а не только последнюю строку «dependency failed». Если в журнале указана точка монтирования, запишите её UUID и точку монтирования. Если указана служба, не связанная с хранилищем, не начинайте менять её /etc/fstabслучайным образом; проверьте конкретное устройство systemctl status unit-nameи его последние сообщения в журнале.

2. Проверьте, разрешает ли корневая файловая система редактирование.

Перед редактированием конфигурационного файла ознакомьтесь с тем, как смонтирована корневая файловая система:

findmnt /

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

mount -o remount,rw /

Повторите попытку findmnt /, чтобы подтвердить изменения. Если перемонтирование не удастся, остановите процесс и запишите ошибку. Корневой каталог только для чтения может быть защитной мерой на случай проблем с файловой системой; принудительная запись или многократные попытки монтирования могут затруднить восстановление. Используйте среду восстановления или обратитесь в службу поддержки провайдера, если корневой том выглядит поврежденным.

3. Проверьте диски и сравните их с файлом /etc/fstab.

Распространенная причина — устаревшая /etc/fstabзапись: диск был удален, UUID изменен или путь монтирования указан неверно. Первый список обнаруженных файловых систем и их идентификаторов:

lsblk -f
blkid

Затем прочтите конфигурацию таблицы монтирования:

cat /etc/fstab

Сопоставьте каждый настроенный UUID с выводом из lsblk -fили blkidи убедитесь, что точка монтирования и тип файловой системы указаны правильно. Не заменяйте имя устройства, например, /dev/sdb1только на его текущую букву; порядок устройств может измениться. UUID часто более стабильны, но они все равно должны соответствовать фактической файловой системе.

Этот /etc/fstabфайл преобразуется в единицы монтирования systemd при загрузке. Его поля и параметры имеют специфическое значение, поэтому, если какая-либо запись вам незнакома, обратитесь к официальному руководству Ubuntu по fstab .

4. Временно обойти отсутствие дополнительного крепления.

Если ошибка указывает на несущественный диск с данными, который намеренно отсутствует, сделайте резервную копию /etc/fstab, а затем закомментируйте только эту строку, добавив #в начало файла. Это позволит проверить, является ли отсутствующее монтирование блокировщиком загрузки. Не комментируйте корневую файловую систему, файл /bootили запись зашифрованного тома, если вы не понимаете структуру хранения данных в системе.

cp -a /etc/fstab /etc/fstab.before-emergency-fix
nano /etc/fstab

В качестве альтернативы, если диск должен быть необязательным в обычном режиме работы, рассмотрите nofailвозможность использования параметра монтирования после проверки предполагаемого поведения. Используйте его только для действительно необязательного монтирования: добавление его к обязательному системному тому может скрыть реальный сбой хранилища. Сетевым файловым системам могут потребоваться дополнительные параметры, специфичные для systemd, и сетевые зависимости; не копируйте параметры из несвязанной конфигурации.

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

systemctl daemon-reload
mount -a

Прочитайте весь вывод. Чистый результат не доказывает, что каждое приложение может использовать смонтированные данные, но сообщенный UUID, синтаксическая ошибка или ошибка монтирования укажут на то, что еще нужно исправить. В руководстве по systemd-fstab-generator объясняется, как systemd преобразует записи fstab в единицы монтирования.

5. Исправьте некорректный UUID, путь или параметр монтирования.

Если диск присутствует, но его UUID отличается, убедитесь, что вы определили правильную файловую систему, прежде чем обновлять UUID=...поле соответствия. Убедитесь, что каталог точки монтирования существует, тип файловой системы указан верно, и параметры действительны для этой файловой системы. Исправляйте по одной записи за раз, затем повторно запустите systemctl daemon-reloadи mount -a.

Для съемного или дополнительного диска данных, который является необязательным, установка соответствующей политики монтирования необязательного устройства может предотвратить блокировку загрузки из-за его отсутствия. Для критически важного тома исправьте устройство, кабель, сопоставление шифрования или идентификатор, вместо того чтобы маскировать неисправность. Если неисправное устройство имеет имя устройства LUKS или LVM, проверьте соответствующее сопоставление и состояние тома; не заменяйте его UUID разделом с аналогичным именем.

6. Проверку файловой системы следует выполнять только тогда, когда целевой объект отмонтирован.

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

Для разделов данных с файловыми системами ext2, ext3 или ext4 сначала убедитесь, что они не смонтированы findmnt. Если они смонтированы, отмонтируйте их перед проверкой. Типичная проверка ext4 в подходящей среде восстановления выглядит следующим образом:

sudo e2fsck -f /dev/DEVICE

Заменяйте /dev/DEVICEтолько после сопоставления правильного раздела из lsblk -f. Внимательно читайте вопросы и статус проверки; не добавляйте автоматический параметр «да на все», не понимая риска потери данных. Для корневой файловой системы, которую невозможно отмонтировать из работающей аварийной оболочки, загрузите среду восстановления Live или провайдера и проверьте ее в автономном режиме. Btrfs, XFS и другие файловые системы используют разные инструменты и процедуры восстановления. В частности, не рассматривайте универсальную fsckкоманду как доказательство того, что был восстановлен каждый тип файловой системы.

7. Используйте GRUB или внешнее восстановление только в том случае, если командная оболочка недоступна.

Если сервер так и не смог получить доступ к аварийной оболочке, откройте меню GRUB и попробуйте использовать пункт восстановления дистрибутива, когда он станет доступен. В стандартной установке Ubuntu доступ к меню часто осуществляется удерживанием клавиши Shift в системах с устаревшим BIOS или нажатием клавиши Esc в системах с UEFI, но виртуальные машины могут использовать другой способ доступа к консоли. Для однократной аварийной загрузки systemd администратор может отредактировать выбранную запись GRUB и добавить ее systemd.unit=emergency.targetв командную строку ядра Linux. Изменение применяется только к этой загрузке; удалите его перед следующей обычной загрузкой. См. официальный справочник по меню GNU GRUB .

Если загрузочный том не удается смонтировать, используйте загрузочную среду Ubuntu или систему восстановления облачного провайдера для его проверки. Разблокируйте зашифрованное хранилище и активируйте LVM только в том случае, если это соответствует установке. Монтирование корневой файловой системы сервера из режима восстановления сопряжено с дополнительными рисками; избегайте записи на нее, пока не будут идентифицированы диск и файловая система. Ubuntu Core использует собственный алгоритм восстановления и не восстанавливается путем слепого следования шагам GRUB для настольных компьютеров или стандартным шагам GRUB для Server.

8. Перезагрузите устройство и проверьте результат ремонта.

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

reboot

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

systemctl is-system-running
systemctl --failed
findmnt --target /

Проверьте ожидаемые точки монтирования данных с помощью команды `npm install` findmnt /path/to/mountи подтвердите критически важные службы с помощью команды `npm install` systemctl status service-name. Если аварийный режим возвращается, повторно проверьте первую ошибку загрузки, а не повторяйте ту же процедуру восстановления. Успешное восстановление означает, что сервер завершает обычную загрузку, и необходимые для него хранилища и службы становятся доступны; простого появления приглашения к входу в систему недостаточно.

Для получения информации о текущем поведении systemd см. руководство по специальным модулям Ubuntu . Версии пакетов и меню восстановления могут различаться в зависимости от версии Ubuntu и платформы, поэтому, если команда или модуль отличаются, используйте документацию для установленной версии.