Debian/Ubuntu: A start job is running for /dev/disk/by-uuid — как исправить зависание загрузки из-за fstab

Сообщение A start job is running for /dev/disk/by-uuid/... при загрузке Debian или Ubuntu почти всегда связано с монтированием файловых систем из /etc/fstab. Система пытается дождаться устройства, но оно не появляется, UUID уже не существует, раздел повреждён или подключается слишком поздно.

На практике это одна из самых частых причин медленной загрузки, перехода в emergency mode и долгих таймаутов systemd. Выглядит как серьёзная поломка Linux, но обычно проблема куда проще: удалили старый диск, перенесли виртуальную машину, пересоздали файловую систему, ошиблись при ручном редактировании fstab.

Ключевая мысль простая: тормозит не сама загрузка, а конкретный mount-юнит, который ждёт блочное устройство до истечения таймаута. Поэтому чинить нужно не «systemd вообще», а точную запись в fstab или поведение устройства.

Ниже разберём безопасный порядок действий: как найти проблемную строку, как сверить UUID, когда уместно использовать nofail, в каких случаях нужен x-systemd.device-timeout, а когда запись лучше просто убрать.

Что означает это сообщение при старте системы

Путь /dev/disk/by-uuid/... — это символьная ссылка на блочное устройство по UUID файловой системы. Именно UUID обычно используют в fstab, потому что имена вроде /dev/sda1 или /dev/vdb1 могут меняться после миграции, изменения схемы дисков или перезагрузки.

Во время старта systemd читает /etc/fstab, создаёт mount-юниты и пытается смонтировать всё, что там перечислено. Если UUID не найден или устройство недоступно в нужный момент, система начинает ждать. Пока ожидание не завершится, загрузка может выглядеть как зависание.

Важно: сообщение A start job is running for /dev/disk/by-uuid ещё не означает поломку диска. Оно говорит только о том, что запись в fstab не удалось обработать вовремя.

Чаще всего причина одна из этих:

• в fstab остался UUID старого раздела;
• файловую систему пересоздали, и UUID изменился;
• дополнительный диск больше не подключён;
• внешний или сетевой том оформлен как обязательный для загрузки;
• в UUID есть опечатка;
• раздел существует, но сама файловая система не монтируется;
• точка монтирования указана неверно.

С чего начать и как не усугубить ситуацию

Если система всё же загружается, даже медленно, сначала соберите информацию и только потом правьте fstab. Если загрузка заканчивается переходом в emergency mode, используйте root-консоль, rescue-режим или консоль провайдера.

Главная задача на первом этапе — понять, какая именно строка вызывает ожидание. Не редактируйте файл наугад, особенно если на сервере несколько дисков, отдельный /boot, LVM или нестандартная разметка.

Минимальный набор команд для диагностики:

lsblk -f
blkid
findmnt
cat /etc/fstab
systemctl --failed
journalctl -b -p warning
journalctl -b | grep -iE 'uuid|mount|timed out|dependency failed'

Смотрите на три вещи: есть ли нужный UUID в системе, совпадает ли он с записью в fstab, и что именно пишет журнал о неудачном монтировании.

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

Как быстро найти проблемную запись в fstab

Откройте /etc/fstab и сопоставьте каждую строку с выводом lsblk -f и blkid. Типичный проблемный пример:

UUID=11111111-2222-3333-4444-555555555555 /data ext4 defaults 0 2

Если такого UUID в системе нет, причина найдена. Обычно это происходит после клонирования, форматирования заново, удаления диска или переноса сервера в другое окружение.

Для быстрой сверки удобно выполнить:

grep -n 'UUID=' /etc/fstab
blkid | sort

Если UUID из fstab отсутствует в выводе blkid, строка устарела или содержит ошибку. Если UUID есть, но загрузка всё равно ждёт слишком долго, проблема уже в доступности устройства или в состоянии файловой системы.

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

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

Подробнее

Когда проблема не в UUID, а в долгом ожидании

Иногда UUID корректный, но устройство появляется с задержкой. Такое бывает с дополнительными виртуальными дисками, LUKS, LVM, RAID, некоторыми cloud-init сценариями и томами, которые не должны блокировать старт всей системы.

В этом случае systemd ждёт появления устройства до таймаута. Для проверки полезны команды:

systemd-analyze blame
systemd-analyze critical-chain
journalctl -b | grep -i 'A start job is running for'
systemctl status local-fs.target

Если долго ждётся не критичный раздел вроде /data, /backup или /mnt/archive, не делайте его обязательным для старта. Для вторичных томов лучше настроить поведение честно, чем каждый раз терять время на ожидание.

Если раздел смонтирован, но работает нестабильно или даёт ошибки по файловой системе, пригодится отдельная проверка параметров и состояния тома. По теме ext4 и XFS может быть полезен материал про настройку ext4 и XFS на сервере.

Безопасный алгоритм исправления

Чтобы не получить повторный уход в emergency mode, действуйте по шагам:

1. Сделайте резервную копию /etc/fstab.
2. Проверьте, существует ли UUID и соответствует ли он нужному разделу.
3. Убедитесь, что точка монтирования существует.
4. Если раздел необязателен, добавьте nofail или настройте таймаут.
5. Если запись больше не нужна, сначала закомментируйте её.
6. Проверьте всё через mount -a без перезагрузки.
7. Только после этого перезагружайте сервер.

Резервная копия:

cp /etc/fstab /etc/fstab.bak-$(date +%F-%H%M%S)

Проверка после изменений:

mount -a
findmnt
systemctl daemon-reload

Если mount -a возвращает ошибку, не перезагружайтесь. Сначала исправьте конфигурацию, иначе можно снова попасть в аварийный режим.

Когда использовать nofail

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

Пример:

UUID=11111111-2222-3333-4444-555555555555 /data ext4 defaults,nofail 0 2

nofail не лечит поломку, а меняет важность ресурса для загрузки. Для корневого раздела, /boot и /boot/efi применять эту опцию обычно не стоит.

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

Когда нужен x-systemd.device-timeout

Если устройство действительно появляется, но медленно, можно управлять ожиданием через x-systemd.device-timeout. Это удобно, когда вы хотите сократить бессмысленное ожидание для вторичного тома.

Пример:

UUID=11111111-2222-3333-4444-555555555555 /data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

Так система быстро продолжит загрузку, если диск не появился. Но если том обязателен для работы сервиса, уменьшение таймаута только быстрее покажет ошибку, а не решит её.

Что делать в emergency mode

Если система уже ушла в emergency mode, обычно помогает минимальная диагностика и временное отключение проблемной строки в fstab.

1. Определите, какая запись вызывает ошибку.
2. Проверьте наличие устройства через lsblk -f и blkid.
3. Откройте /etc/fstab и закомментируйте подозрительную строку.
4. Повторите проверку через mount -a.
5. После этого продолжайте загрузку или перезагружайте систему.

lsblk -f
blkid
cat /etc/fstab
mount -a

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

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

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

Подробнее

Как понять, что проблема уже в файловой системе

Если UUID существует, но монтирование не проходит, смотрите на состояние самой файловой системы. В журнале могут быть ошибки суперблока, журнала ext4, XFS recovery или сообщения об I/O ошибках.

Проверьте журнал:

journalctl -b -p err
dmesg | grep -iE 'ext4|xfs|btrfs|i/o error|superblock|journal'

Если раздел не является корневым и точно отмонтирован, для ext4-подобных ФС часто применяют:

fsck -f /dev/vdb1

Но действовать здесь нужно аккуратно. Для XFS и других ФС используются свои инструменты, а корневой раздел нельзя бездумно проверять и исправлять из уже запущенной системы.

Частые ошибки в fstab

• скопировали UUID не того раздела;
• указали UUID swap вместо data-раздела;
• после форматирования забыли обновить запись;
• точка монтирования не существует;
• временный диск сделали обязательным;
• оставили старую строку после миграции;
• задали несовместимые опции монтирования.

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

Практический пример: зависание из-за старого /data

Допустим, раньше на сервере был дополнительный диск под /data. Потом диск удалили, но запись в fstab осталась. После каждой перезагрузки система ждёт устройство, которого больше нет.

Было:

UUID=11111111-2222-3333-4444-555555555555 /data ext4 defaults 0 2

Исправить можно тремя способами:

• закомментировать строку, если раздел больше не нужен;
• подставить новый UUID, если диск заменили;
• добавить nofail и таймаут, если раздел вторичный.

Например:

# UUID=11111111-2222-3333-4444-555555555555 /data ext4 defaults 0 2

Или так:

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

После изменений проверьте:

mount -a
findmnt /data

Проверка после исправления

После правки fstab не ограничивайтесь одной командой. Нормальный короткий чек-лист выглядит так:

mount -a
findmnt
systemctl --failed
journalctl -b -p warning

Если это production-сервер, вносить такие изменения лучше через консоль с гарантированным доступом, а не только по SSH. Это особенно важно, если правки касаются критичных точек монтирования.

Итог

Сообщение A start job is running for /dev/disk/by-uuid в Debian и Ubuntu почти всегда упирается в одну из трёх причин: UUID не существует, устройство недоступно к моменту старта или раздел не должен был быть обязательным для загрузки.

Рабочий алгоритм такой: проверить lsblk, blkid, findmnt, сопоставить всё с /etc/fstab, сделать резервную копию, исправить запись и протестировать через mount -a. Для необязательных томов использовать nofail, для контроля ожидания — x-systemd.device-timeout.

Если не редактировать fstab вслепую и сначала понять, какой именно раздел ждёт systemd, эта проблема обычно устраняется быстро и без последствий.