Как исправить ошибку загрузки /etc/fstab с помощью journalctl

Уровень: Начинающий / Средний
Примерное время: ~15 минут
Цель: Проанализировать системные журналы с помощью journalctl для выявления и исправления ошибки в /etc/fstab, которая предотвращает загрузку системы.

Введение

Простая синтаксическая ошибка в /etc/fstab может предотвратить загрузку сервера, переведя вас в оболочку аварийного обслуживания (emergency maintenance shell). Восстановление требует анализа системных журналов, чтобы точно определить место сбоя. В этом руководстве мы будем использовать journalctl для отправки запроса к журналу systemd и просмотра системных журналов, которые Linux генерирует во время запуска. Понимание журналов systemd является критически важным навыком для управления журналами Linux, обеспечивая быстрое восстановление и высокую доступность ваших сервисов. Знакомство с базовыми командами journalctl необходимо для поиска точки монтирования, вызвавшей сбой.

Управление журналами Linux и стек логирования

Прежде чем переходить к восстановлению, важно понять задействованные компоненты. Systemd (система инициализации и диспетчер служб для Linux) использует Systemd-journald (системную службу, которая собирает и хранит данные логирования). Эта служба собирает каждый Log (запись событий, происходящих в системе) в Journal (двоичные данные журнала, хранящиеся Systemd-journald). Сюда входят системные журналы (записи общесистемных событий и изменений состояния), журналы загрузки (записи процесса запуска системы) и журналы ядра (сообщения, генерируемые ядром операционной системы).

В зависимости от вашей конфигурации, это могут быть энергозависимые журналы (volatile logs) (журналы, хранящиеся в оперативной памяти и теряемые при перезагрузке) или постоянные журналы (persistent logs) (журналы, сохраняющиеся после перезагрузки системы, как правило, на диске). Журнал постоянно растет, поэтому ротация журналов (процесс архивирования и управления старыми файлами журналов для экономии места на диске) автоматически обрабатывается systemd.

Предварительные требования

Перед началом работы убедитесь, что выполнены следующие условия:

• Операционная система: Протестировано на Ubuntu 22.04/24.04 LTS, Debian 12/13, AlmaLinux/Rocky 9/10
• Доступ: Прямой доступ к консоли (IPMI, VNC или физическая консоль) для входа в аварийную оболочку
• Необходимые знания: Уверенное использование командной строки Linux и базовое редактирование текста

Шаг 1: Определение сбоя загрузки

Синтаксическая ошибка, опечатка или отсутствующее устройство в /etc/fstab вызовет аварийный режим (emergency mode), останавливая процесс загрузки и выводя сообщение вроде:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Введите пароль пользователя root для доступа к командной строке. На этом этапе некоторые файловые системы могут быть не смонтированы или смонтированы только для чтения.

Шаг 2: Использование journalctl для просмотра и анализа системных журналов, генерируемых Linux

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

Выполните следующую команду:

sudo journalctl -xb

Здесь мы используем Journalctl (утилиту командной строки для запросов к журналу systemd). Это одна из самых важных команд journalctl. Она дает указание инструменту показать журналы для текущей загрузки (-b) и включить дополнительный пояснительный текст (-x).

Этот вывод может быть огромным. Нам нужно выполнить фильтрацию журналов (процесс сужения вывода журнала на основе определенных критериев), чтобы найти ошибку.

Чтобы выполнить поиск внутри пейджера (который использует less), введите /fstab или /mount и нажмите Enter.

Ожидаемый фрагмент вывода:

-- Subject: A start job for unit mnt-data.mount has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit mnt-data.mount has finished with a failure.
--
-- The job identifier is 123 and the job result is failed.

Это указывает на то, что юнит (Unit) (конфигурационный файл, описывающий, как управлять ресурсом в systemd), отвечающий за монтирование /mnt/data, завершился с ошибкой. В частности, юнит службы (service unit) монтирования (конфигурационный файл юнита, кодирующий информацию о процессе, управляемом systemd) не смог запуститься.

Шаг 3: Фильтрация журналов systemd для поиска конкретных ошибок

Если прокручивать весь журнал загрузки слишком медленно, мы можем анализировать журналы с помощью journalctl, используя специальные фильтры.

Выполните следующую команду, чтобы увидеть только ошибки с высоким приоритетом:

sudo journalctl -p err -b

Ожидаемый вывод:

May 23 10:00:01 server systemd[1]: Failed to mount mnt-data.mount - /mnt/data.
May 23 10:00:01 server systemd[1]: Dependency failed for Local File Systems.

Путем фильтрации журналов journalctl по приоритету (-p err) мы отбрасываем информационные сообщения.

Мы также можем проверить журналы службы напрямую, если знаем точный юнит, в котором произошел сбой. Выполните:

sudo journalctl -u mnt-data.mount

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

Шаг 4: Исправление ошибки в /etc/fstab

Теперь, когда журнал systemd подтвердил, что проблема заключается в точке монтирования /mnt/data, нам нужно исправить конфигурационный файл.

Сначала попытайтесь отредактировать файл. Если при сохранении вы столкнулись с ошибкой Read-only file system (файловая система доступна только для чтения), вам необходимо перемонтировать корневую файловую систему для чтения и записи, поскольку аварийный режим часто монтирует ее только для чтения:

sudo mount -o remount,rw /

Далее, создайте резервную копию конфигурационного файла перед внесением изменений:

sudo cp /etc/fstab /etc/fstab.bak

Затем откройте файл (в системах на базе RPM, таких как AlmaLinux, Rocky или RHEL, nano может быть не установлен по умолчанию, поэтому сначала установите его с помощью sudo dnf install -y nano):

sudo nano /etc/fstab

Найдите строку, ссылающуюся на /mnt/data (вы можете найти правильный UUID с помощью blkid):

UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defualts 0 2

Обратите внимание на опечатку: defualts вместо defaults. Исправьте опечатку:

UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defaults 0 2

Сохраните и закройте файл. Затем перезагрузите конфигурацию диспетчера systemd, чтобы убедиться, что systemd знает об изменениях, внесенных в /etc/fstab:

sudo systemctl daemon-reload

Проверка

Перед перезагрузкой проверьте синтаксис вашего /etc/fstab с помощью findmnt:

findmnt --verify

Если он не сообщает об ошибках, перейдите к проверке работоспособности точки монтирования:

Выполните:

sudo mount -a

Если команда не возвращает вывод, синтаксис верен, и монтирование прошло успешно. Если у вас все еще есть ошибка, команда выведет сообщение об ошибке. Сообщение может указывать точную причину в Debian 13 и AlmaLinux 10 (например, Unknown parameter 'defualts'), но в Ubuntu 24.04 вывод часто является общим (wrong fs type, bad option). В Ubuntu выполните sudo dmesg | tail для получения подробной информации.

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

sudo systemctl reboot

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

sudo journalctl -u mnt-data.mount -b

Устранение неполадок

• Аварийная оболочка недоступна: Если учетная запись root заблокирована и вы не можете получить доступ к аварийной оболочке, вам необходимо загрузить сервер с помощью Live USB или среды восстановления, смонтировать корневой раздел и отредактировать /etc/fstab непосредственно оттуда.
• UUID изменился: Если вы отформатировали раздел или заменили диск, UUID изменится. Используйте sudo blkid, чтобы найти новый UUID, и соответственно обновите /etc/fstab.
• Предотвращение сбоев загрузки для некритичных дисков: Для некорневых, несистемных томов (таких как диски для резервных копий или данных) добавьте параметр монтирования nofail в запись /etc/fstab (например, ext4 defaults,nofail 0 2). Это скажет systemd продолжать загрузку, даже если устройство не удалось смонтировать.

Откат изменений

Если сервер успешно загрузился, но измененная строка /mnt/data вызывает неожиданное поведение приложения, вы можете отменить монтирование, закомментировав строку в /etc/fstab:

sudo sed -i 's|^UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|#UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|' /etc/fstab

Затем отмонтируйте том, чтобы восстановить предыдущее состояние:

sudo umount /mnt/data

Заключение

Эффективное управление журналами Linux в значительной степени опирается на знания о том, как ориентироваться в журналах systemd. Используя journalctl, вы можете просматривать системные журналы, создаваемые Linux, чтобы эффективно анализировать системные журналы и восстанавливаться после критических сбоев загрузки, таких как неправильная конфигурация /etc/fstab. Владение этими инструментами гарантирует, что вы сможете поддерживать время безотказной работы (uptime) и диагностировать сложные проблемы в вашей инфраструктуре.

Версия документа: 1.0
Последнее обновление: Май 2026
Владелец: Команда технической документации