Linux: /etc/fstab и emergency mode (rescue) — как быстро поднять систему после ошибки монтирования

Что происходит: почему /etc/fstab может «уронить» загрузку

Файл /etc/fstab описывает, какие файловые системы и с какими опциями нужно смонтировать при старте. В системах с systemd каждая строка fstab превращается в mount-unit (например, home.mount, var-lib.mount и т. п.). Если обязательное монтирование не удалось, systemd может остановить загрузку и перевести систему в emergency.target (emergency mode) или rescue mode.

Классический «boot failure из-за fstab» чаще всего случается после замены/миграции дисков, клонирования VM, изменения порядка устройств, добавления сетевых томов или из-за банальной опечатки в строке.

• Сменился UUID/PARTUUID после переразметки или пересоздания ФС.
• Подключили NFS/CIFS без зависимостей от сети и таймаутов.
• Точка монтирования не существует или указан неверный тип ФС.
• Файловая система повреждена и требует проверки.

Ниже — практичный алгоритм: как быстро найти проблемную строку, починить её, проверить результат и не попасть в аварийный режим повторно.

Emergency mode vs rescue mode: в чём разница

Rescue mode — это «однопользовательский режим» с базовыми сервисами и root-shell. Обычно система пытается смонтировать корень в RW и поднять минимум окружения для ремонта.

Emergency mode (цель systemd emergency.target) — более ранний и строгий режим. Часто корень смонтирован только для чтения или часть монтирований не выполнена. Логика простая: лучше остановиться раньше, чем продолжать загрузку на неконсистентной базе.

Если видите запрос пароля root для обслуживания и сообщения о сбое монтирования, почти всегда виновата строка в /etc/fstab или состояние файловой системы, указанной в ней.

Быстрая диагностика прямо в emergency/rescue

1) Находим, какой mount-unit упал

Начните с просмотра упавших unit’ов и лога текущей загрузки:

systemctl --failed
journalctl -xb --no-pager

Типовые маркеры проблемы:

• Timed out waiting for device /dev/disk/by-uuid/...
• Dependency failed for /home
• Failed to mount /data

Если видите конкретный unit, раскройте детали именно по нему:

systemctl status home.mount --no-pager
journalctl -u home.mount -b --no-pager

2) Проверяем корень: смонтирован ли / и в каком режиме

Чтобы понять, можно ли сразу править /etc/fstab, проверьте состояние корневого монтирования:

findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS /
mount | head

Если / в RO, перемонтируйте в RW:

mount -o remount,rw /

3) Сверяем UUID/PARTUUID и устройства

Самая частая причина — в fstab указан UUID, которого больше нет (или он относится к другому разделу после миграции).

lsblk -f
blkid
ls -l /dev/disk/by-uuid
ls -l /dev/disk/by-partuuid

Дальше просто: найдите UUID из /etc/fstab и убедитесь, что он реально существует и соответствует нужной ФС.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Ремонт /etc/fstab: пошагово и безопасно

Шаг 1. Находим проблемную строку

Откройте /etc/fstab любым доступным редактором (в emergency/rescue обычно есть vi или nano):

cat /etc/fstab
nano /etc/fstab

Проверьте четыре вещи, которые чаще всего ломают загрузку:

• опечатки в UUID=/PARTUUID=;
• точка монтирования не существует (каталог не создан);
• указан неверный тип ФС (например, ext4 вместо xfs);
• опции несовместимы с типом ФС или устройством.

Шаг 2. Временно «смягчаем» монтирование, чтобы загрузиться

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

Опции, которые часто спасают от ухода в аварийный режим:

• nofail — ошибка монтирования не считается фатальной для загрузки;
• x-systemd.device-timeout=10s — не ждать устройство слишком долго;
• x-systemd.automount — монтировать «по обращению», а не на старте;
• _netdev — для сетевых ФС, чтобы systemd учитывал сеть как зависимость.

Пример (идея, не универсальный рецепт):

UUID=xxxx-xxxx  /data  ext4  defaults,nofail,x-systemd.device-timeout=10s  0  2

nofail уместен для бэкапов/архивов/вторичных данных. Для критичных разделов лучше чинить причину, а не скрывать симптом.

Шаг 3. Проверяем сразу, без перезагрузки

Ключевой приём, который экономит время: после правок прогоните ручную проверку монтирования.

mount -a

Если команда вернула ошибку — вы увидите её сразу и исправите, не попадая в emergency mode на следующем reboot.

Дополнительная валидация:

findmnt --verify

UUID или PARTUUID: что выбирать в fstab

UUID — идентификатор файловой системы. Он меняется при пересоздании ФС (например, после mkfs.ext4), но обычно стабилен в обычной эксплуатации.

PARTUUID — идентификатор раздела в таблице разделов (GPT/MBR). Он меняется при переразметке, но не зависит от пересоздания ФС внутри раздела.

• Для обычных ext4/xfs разделов чаще всего достаточно UUID=.
• Если ФС внутри раздела могут пересоздаваться, а сам раздел сохраняется, иногда удобнее PARTUUID=.
• Для LVM/MD RAID обычно используют устройства /dev/mapper/... или /dev/md... и корректные зависимости, а не /dev/sdX.

Как быстро посмотреть значения:

blkid
lsblk -o NAME,FSTYPE,UUID,PARTUUID,MOUNTPOINTS

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

Когда виновата не строка, а файловая система: fsck и типовые ошибки

Если в логах видны I/O ошибки, сообщения вроде needs cleaning или UNEXPECTED INCONSISTENCY, то fstab может быть корректным, но монтирование падает из-за проблем ФС.

Ext4: fsck (только на отмонтированном разделе)

Проверку запускайте на размонтированном разделе (в rescue/initramfs это делать проще):

umount /dev/sdb1
fsck -f /dev/sdb1

Автоматическое исправление (применяйте осознанно):

fsck -fy /dev/sdb1

XFS: xfs_repair

Для XFS используется отдельный инструмент:

umount /dev/sdb1
xfs_repair /dev/sdb1

Если проблема на корневом разделе, чаще всего проще зайти через rescue-консоль провайдера или initramfs, чтобы ФС не была занята.

По теме различий и практики обслуживания ext4 и XFS может помочь отдельный материал: ext4 vs XFS на сервере: что выбрать и как тюнить.

Случай «initramfs drop to shell»: чем отличается и что делать

Иногда система не доходит до systemd и падает ещё раньше — в initramfs, с приглашением вида «initramfs» shell. Обычно это значит, что не найден корневой раздел (root), либо нет драйвера/модуля для диска или контроллера.

Минимальный набор проверок в initramfs:

cat /proc/cmdline
ls /dev/disk/by-uuid
blkid

Если root=UUID=... в параметрах ядра не совпадает с реальностью (часто после клонирования), правится конфигурация загрузчика. Если root находится и монтируется, а падает уже позже — возвращайтесь к диагностике /etc/fstab и mount-unit’ов.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Типовые «мины» в fstab, которые регулярно приводят к аварийному режиму

1) /dev/sdX вместо UUID

/dev/sda1 и друзья могут поменяться местами после миграции, подключения дисков или изменения контроллера. На сервере почти всегда используйте UUID= или PARTUUID=, а не «сырые» имена устройств.

2) Сетевые монтирования без правильных опций

NFS/CIFS в fstab без _netdev и таймаутов — частая причина зависаний или ухода в emergency/rescue, если сеть и DNS не готовы рано при старте. Обычно помогает _netdev, x-systemd.device-timeout=, а также перевод в x-systemd.automount.

3) Каталог точки монтирования не существует

Проверьте наличие каталога до mount -a:

ls -ld /data
mkdir -p /data

4) Ошибка в шестом поле (pass) и порядок fsck

Последние два поля — dump и pass. Для ext4 типовой порядок такой:

• для / — 1;
• для остальных локальных ext4 — 2;
• для того, что не надо проверять — 0.

Неверный pass не всегда «роняет» загрузку напрямую, но может приводить к неожиданным проверкам на старте и таймаутам.

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

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

• Ещё раз выполните mount -a и убедитесь, что ошибок нет.
• Проверьте реальные монтирования: findmnt.
• Посмотрите, нет ли скрытых таймаутов и деградаций: journalctl -b и systemd-analyze blame.
• Если были ошибки ФС или I/O, проверьте логи ядра и состояние диска.

findmnt
systemctl --failed
journalctl -b -p warning --no-pager
systemd-analyze blame

Если проблема была вызвана изменением размера диска/раздела (часто после апгрейда), пригодится инструкция: как безопасно увеличить раздел и файловую систему (growpart/resize).

Мини-чеклист: самый быстрый путь из emergency mode из-за fstab

1. Зайти в root-shell (emergency/rescue).
2. Если нужно редактировать: mount -o remount,rw /.
3. systemctl --failed и journalctl -xb — найти проблемный mount.
4. blkid и lsblk -f — сверить UUID/PARTUUID.
5. Исправить /etc/fstab (временно закомментировать строку или добавить nofail для некритичного).
6. Запустить mount -a до перезагрузки.
7. Если ошибки ФС — выполнить fsck (ext4) или xfs_repair (xfs) на отмонтированном разделе.
8. Перезагрузиться и проверить лог загрузки.

И на будущее: держите доступ к консоли и rescue-режиму под рукой. Ошибки в /etc/fstab случаются нечасто, но всегда «в самый неподходящий момент».