Як виправити помилку завантаження /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
Власник: Команда технічної документації