UUID и PARTUUID в Linux: fstab, initramfs и systemd mount units без сюрпризов

Инструкции
11 янв, 2026
Время на чтение: ~12 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Админы чаще всего вспоминают про UUID/PARTUUID не тогда, когда «настраивают красиво», а когда сервер внезапно грузится в emergency mode с чем-то вроде Timed out waiting for device, Dependency failed for /data или «disk not found». В большинстве случаев причина одна: идентификатор диска или раздела изменился, а система продолжает ждать старый.

Ниже — практичная шпаргалка: чем отличается UUID от PARTUUID, как безопасно прописывать монтирования в /etc/fstab, когда реально нужна пересборка initramfs, и в каких случаях удобнее перейти на systemd mount units.

UUID vs PARTUUID: что именно идентифицируем

UUID обычно относится к файловой системе (ext4/xfs/btrfs и т. д.) и хранится в её метаданных. Переформатировали раздел — почти наверняка получили новый UUID.

PARTUUID — это идентификатор раздела в таблице разделов (чаще GPT, иногда MBR). Его меняют операции, связанные с пересозданием раздела (удалили/создали заново), конвертация схемы разметки, некоторые сценарии «клонирования и доведения до ума».

Также в Linux есть стабильные «пути» в /dev/disk: by-id (по серийному номеру/идентификатору устройства) и by-path (по пути в шине). Они могут быть полезнее UUID/PARTUUID в ряде кейсов, но в виртуализации/облаках идентификаторы тоже могут быть не вечными (смена контроллера, образа, типа диска).

Практическое правило выбора

Типовой сервер, стабильные ФС: используйте UUID в /etc/fstab.
ФС часто пересоздаётся, но разметка стабильна: рассмотрите PARTUUID.
Для корня (/) важна согласованность сразу в трёх местах: параметры загрузчика (например, root=…), содержимое initramfs и фактически существующие устройства.

Самая частая авария после миграций/клонирования/ресайза: в fstab остался старый идентификатор. Результат — задержка на загрузке или уход в emergency mode.

Как посмотреть UUID и PARTUUID и не перепутать

Начните с lsblk: он показывает сразу и файловую систему, и идентификаторы, и текущие точки монтирования. Для «контрольного выстрела» используйте blkid.

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,PARTUUID,MOUNTPOINTS

blkid

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

ls -la /dev/disk/by-uuid

ls -la /dev/disk/by-partuuid

ls -la /dev/disk/by-id

Нюанс про LVM/RAID/LUKS

Если у вас LVM, mdraid или dm-crypt, «реальный» источник монтирования может быть не /dev/sda2, а, например, /dev/mapper/vg0-data или /dev/md0. Сверяйте идентификаторы именно того уровня, который вы используете в fstab или mount unit.

Если вы как раз выполняете перенос/увеличение диска на виртуалке, пригодится чек-лист из статьи про расширение диска: как безопасно увеличить раздел и ФС на VDS.

Вывод lsblk и blkid для проверки UUID и PARTUUID перед правками fstab

fstab: безопасные записи с UUID/PARTUUID и анти-кирпич опции

Самый распространённый формат — через UUID=:

UUID=7b2b2a2e-3a2d-4e7a-9b6e-2f2c3d4e5f60 /data ext4 defaults,noatime 0 2

Через PARTUUID= похоже:

PARTUUID=1a2b3c4d-05 /data ext4 defaults,noatime 0 2

Как не уронить загрузку из-за второстепенного диска

Если это не корень и не критичный раздел, добавляйте nofail и ограничивайте ожидание устройства. Тогда при проблеме с диском система продолжит загрузку, а вы исправите конфиг по SSH/через консоль.

UUID=7b2b2a2e-3a2d-4e7a-9b6e-2f2c3d4e5f60 /data ext4 defaults,noatime,nofail,x-systemd.device-timeout=10s 0 2

Если монтирование зависит от сети (например, iSCSI или что-то, что появляется «позже»), можно подсказать systemd зависимости прямо из fstab:

UUID=7b2b2a2e-3a2d-4e7a-9b6e-2f2c3d4e5f60 /data ext4 defaults,nofail,x-systemd.requires=network-online.target,x-systemd.after=network-online.target 0 2

Перед перезагрузкой: короткий чек-лист

Точка монтирования существует: mkdir -p /data.
Нет опечаток в UUID/PARTUUID и в типе ФС (ext4/xfs и т. п.).
Тест без ребута: mount -a и затем findmnt.
Для критичных разделов не добавляйте nofail «на автомате»: можно загрузиться, но получить полурабочие сервисы и тихую порчу данных из-за отсутствующего хранилища.

mount -a

findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS

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

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

Подробнее

Когда нужен update initramfs (и когда нет)

initramfs — ранняя «мини-система», которая стартует до основного rootfs и занимается тем, что должно заработать до монтирования корня: поиск root-устройства, расшифровка LUKS, сборка RAID, активация LVM и т. д. Если именно на этом этапе устройство ищется по идентификатору, то смена UUID/PARTUUID без обновления конфигурации приведёт к тому, что ядро и initramfs будут ждать «старый» диск.

Пересборка initramfs обычно обязательна, если

менялся идентификатор корневого раздела (/) или /boot//boot/efi и вы меняли способ его поиска;
менялась цепочка LUKS/LVM/mdraid для root (ключи, UUID маппингов, состав массивов);
вы правили параметры командной строки ядра (например, root=UUID=...).

Команды пересборки

Debian/Ubuntu:

update-initramfs -u

update-initramfs -u -k all

RHEL/CentOS/Alma/Rocky:

dracut -f

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

cat /proc/cmdline

Если корень задан как root=UUID=..., а вы поменяли UUID файловой системы (например, форматированием или восстановлением из образа), без обновления параметров загрузки и пересборки initramfs вы почти гарантированно получите emergency mode.

systemd *.mount unit: когда лучше, чем fstab

systemd позволяет описывать монтирование отдельным unit-файлом *.mount. Это удобно, когда нужны понятные зависимости, условия запуска, таймауты и управляемость (включить/выключить монтирование как сервис).

Как формируется имя unit

Имя берётся из точки монтирования. Примеры:

/data → data.mount
/var/lib/postgresql → var-lib-postgresql.mount

Пример mount unit для UUID

Создайте файл /etc/systemd/system/data.mount:

[Unit]
Description=Mount /data
After=local-fs-pre.target
Wants=local-fs-pre.target

[Mount]
What=/dev/disk/by-uuid/7b2b2a2e-3a2d-4e7a-9b6e-2f2c3d4e5f60
Where=/data
Type=ext4
Options=defaults,noatime
TimeoutSec=10

[Install]
WantedBy=multi-user.target

Применение:

systemctl daemon-reload

systemctl enable --now data.mount

systemctl status data.mount

findmnt /data

Как сделать «не валим загрузку, если диска нет»

Один из рабочих подходов — условие наличия ожидаемого пути устройства. Тогда unit просто не стартует, если симлинка нет.

[Unit]
ConditionPathExists=/dev/disk/by-uuid/7b2b2a2e-3a2d-4e7a-9b6e-2f2c3d4e5f60

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

Диагностика: emergency mode, timed out waiting for device, disk not found

В аварийной загрузке важно быстро ответить на два вопроса: «какой unit упал?» и «почему нужного устройства нет/не монтируется?». Дальше идём по цепочке: unit → устройство → идентификаторы → порядок появления/зависимости.

1) Найти, что именно упало

systemctl --failed

systemctl status local-fs.target

2) Посмотреть логи текущей загрузки

journalctl -xb

journalctl -b -u data.mount

3) Сверить: устройство существует и идентификатор тот

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

blkid

ls -la /dev/disk/by-uuid

ls -la /dev/disk/by-partuuid

4) Проверить /etc/fstab на синтаксис и логику

cat /etc/fstab

Ошибки в типе ФС или в опциях монтирования иногда маскируются под «устройство не найдено»: девайс есть, но не монтируется, и systemd в итоге сообщает о провале зависимости.

Диагностика emergency mode: failed units systemd и журнал загрузки journalctl

Сценарии, когда идентификаторы меняются (и что делать)

Клонирование диска поблочно → конфликт UUID

Если подключить к одной системе оригинал и клон, UUID файловых систем могут совпасть. Тогда путь /dev/disk/by-uuid/... становится неоднозначным. Правильный выход: не держать одинаковые UUID в одной системе (отключить клон, поменять UUID на одном из томов) или использовать иной способ адресации на время миграции.

Пересоздание файловой системы

Форматирование (mkfs.ext4, mkfs.xfs) почти всегда создаёт новый UUID. Если вы использовали UUID в fstab — обновите запись и проверьте через mount -a.

Пересоздание раздела или смена схемы разметки

При пересоздании раздела меняется PARTUUID. Если root-цепочка завязана на PARTUUID (в параметрах загрузки или initramfs) — обновляйте конфигурации и пересобирайте initramfs.

Мини-FAQ

Что лучше: UUID или PARTUUID?

Зависит от того, что у вас меняется чаще. Форматируете/пересоздаёте ФС — UUID будет меняться. Часто пересоздаёте разделы — PARTUUID тоже не спасёт. В типовой эксплуатации UUID файловой системы — самый понятный и распространённый вариант.

Почему systemd ругается, хотя запись в fstab «правильная»?

Часто дело не в идентификаторе, а в тайминге появления устройства или зависимостях. Для второстепенных дисков используйте x-systemd.device-timeout и nofail. Для сложной логики (сеть, порядок старта сервисов) лучше вынести монтирование в *.mount и явно задать After=/Wants=/ConditionPathExists=.

Нужно ли всегда пересобирать initramfs после правки fstab?

Обычно нет, если речь про дополнительные разделы, которые монтируются уже после старта системы. Но если менялась ранняя загрузка (root, boot, шифрование, RAID/LVM для root) — пересборка initramfs почти обязательна.

Итого

UUID и PARTUUID — это точка стабильности на этапе загрузки и монтирования. Понимание, где живёт идентификатор (ФС или раздел), плюс дисциплина «проверить до ребута» (mount -a, findmnt, cmdline/initramfs для root) превращают emergency mode из лотереи в понятную диагностику по шагам.

Поделиться статьей