Сервер перезагрузился после обновления или отключения питания, и вместо приглашения для входа на консоли появляется сообщение, которое начинается словами «Вы находитесь в аварийном режиме» Сайты не работают, база данных недоступна, а самые очевидные дальнейшие действия — перезагрузиться ещё раз или вставить найденную в интернете команду ремонта — как раз и могут ухудшить ситуацию. Аварийный режим Linux сам по себе не диагноз. Это systemd сообщает вам, что не поднялось нечто необходимое для загрузки системы, обычно диск или файловая система. В руководстве объясняются частые причины, что проверить в первую очередь и когда остановиться и защитить данные.

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

В дистрибутивах на основе systemd, таких как Debian, Ubuntu, AlmaLinux и Rocky Linux, загрузка останавливается на аварийной цели (emergency target), когда не удаётся выполнить обязательный шаг. Чаще всего это монтирование файловой системы из /etc/fstab или проверка файловой системы, в которой человеку нужно принять решение. Затем система предлагает минимальную оболочку root; корневая файловая система часто смонтирована только для чтения, и почти никакие службы не запущены. Сообщение (здесь в переводе) выглядит так:

Вы находитесь в аварийном режиме. После входа введите «journalctl -xb» для просмотра системных журналов, «systemctl reboot» для перезагрузки, «systemctl default» или «exit» для загрузки в обычном режиме.

Режим восстановления (rescue mode) — более мягкий родственник: он монтирует локальные файловые системы и запускает несколько базовых служб. Аварийный режим делает минимум, и именно поэтому появляется, когда есть сомнения в состоянии хранилища.

Частые причины, от безобидных до серьёзных

  • Ошибка fstab. Строка в /etc/fstab указывает на диск, которого больше нет: отключённый USB-накопитель для резервных копий, заменённый диск с новым UUID или опечатка после недавней правки. Это самая частая и наименее опасная причина.
  • Файловая система, которой нужна ручная проверка. После некорректного выключения автоматическая проверка находит несоответствия, которые сама не исправит, и просит запустить fsck вручную.
  • Массив RAID или том LVM, который не собрался. Деградировавший массив RAID, который не запускается, или отсутствующий физический том делают недоступной файловую систему поверх него.
  • Умирающий диск. Ошибки чтения при монтировании или файловая система, которую ядро уже перевело в режим только для чтения, чтобы защитить её.

Первые три — проблемы конфигурации или согласованности. Четвёртая — аппаратная проблема, которая на экране выглядит так же, и если относиться к ней как к остальным, можно потерять восстановимые данные. Поэтому в нашей работе по восстановлению серверов Linux данные всегда защищаются до любой попытки ремонта.

Что проверить в первую очередь, ничего не меняя

  1. Прочитайте журнал. Выполните journalctl -xb и найдите красные строки. Сбой юнита монтирования, сообщение о тайм-ауте ожидания устройства или о сбое зависимости с указанием точки монтирования подскажут, какая файловая система вызывает проблему.
  2. Сравните диски с fstab. Команды lsblk -f и blkid показывают диски и UUID, которые видит система. Если fstab ожидает UUID, которого нет в списке, диск отсутствует или был заменён.
  3. Поищите аппаратные ошибки. Если dmesg показывает ошибки ввода-вывода или smartctl -H сообщает об умирающем диске, план меняется: скопируйте данные до любого ремонта.
  4. Проверьте состояние RAID. cat /proc/mdstat показывает, активны ли программные массивы RAID, деградировали или неактивны.

Сфотографируйте экран или сохраните вывод, прежде чем двигаться дальше. Эти записи — первое, что спросит любой, кто вам поможет.

Безопасные способы исправления и те, которых нужно избегать

Хороший ремонт системы Linux — это в основном диагностика, а само исправление нередко сводится к одной строке. Если журнал указывает на второстепенный диск, например отключённый накопитель для резервных копий, перемонтируйте корневую файловую систему для записи командой mount -o remount,rw /, закомментируйте эту строку или добавьте параметр nofail, чтобы загрузка больше не зависела от диска, и перезагрузитесь. Параметр nofail стоит добавлять для каждого диска, без которого сервер может обойтись.

Если файловой системе нужна проверка, а диск исправен, запускайте fsck на размонтированной файловой системе, но никогда на смонтированной. Чего следует избегать:

  • Многократный запуск fsck -y на умирающем диске. Каждый проход может переместить или отбросить данные, которые диск с трудом читает. Сначала снимите образ диска, например с помощью GNU ddrescue, и ремонтируйте копию.
  • Принудительный возврат файловой системы из режима только для чтения в режим записи. Когда ядро перемонтирует файловую систему только для чтения после ошибок, оно её защищает. Выясните причину, прежде чем снова писать на неё.
  • Переустановка, чтобы проблема исчезла. Переустановка на те же диски может перезаписать то, что ещё можно было восстановить.
  • Многократные перезагрузки в надежде, что всё вернётся. Каждая попытка нагружает диск, который, возможно, уже умирает.

Когда учётная запись root заблокирована или нет консоли

В Ubuntu и некоторых других системах у учётной записи root по умолчанию нет пароля, поэтому аварийный режим заканчивается сообщением о том, что доступ к консоли невозможен, потому что учётная запись root заблокирована, и оболочки нет вовсе. Тогда выход — система восстановления: режим восстановления провайдера или консоль KVM для размещённого сервера, либо загрузочная флешка для машины в вашем офисе. Оттуда можно осмотреть диски, скопировать данные и исправить конфигурацию. Тот же путь используется, когда повреждён сам загрузчик, чему посвящена наша страница о восстановлении загрузки GRUB и MBR.

Для оборудования в серверной внеполосный доступ, например IPMI, iDRAC или iLO, избавляет от поездки, поэтому настройте его и запишите учётные данные, пока всё работает.

Часто задаваемые вопросы: аварийный режим Linux

Безопасно ли нажать Control-D или ввести exit, чтобы продолжить загрузку?

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

Чем аварийный режим отличается от режима восстановления?

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

Почему сервер перевёл диск в режим только для чтения?

Файловые системы вроде ext4 обычно настроены так, чтобы перемонтироваться только для чтения при обнаружении ошибок, чтобы повреждение не распространялось. Причиной может быть некорректное выключение, но часто это умирающий диск или контроллер, поэтому прежде всего проверьте dmesg и данные SMART диска.

Сервер застрял на аварийном приглашении? Наша услуга восстановления и ремонта системы Linux начинается с диагностики и защиты данных, затем устраняются сбои загрузки, файловых систем, RAID и служб, а в конце вы получаете короткий письменный отчёт. Для ремонта Linux в Лонг-Бич и районе Лос-Анджелеса или для размещённого сервера в любом месте США свяжитесь с нами, указав дистрибутив, место размещения сервера и фотографию последнего экрана.