Debian 13: помилка в fstab перешкоджає завантаженню — найшвидше виправлення в режимі rescue

Що саме зламалося, коли /etc/fstab порушує завантаження

/etc/fstab вводить в оману своєю простотою: один файл, що зіставляє «що монтувати» з «куди та як». Невеличка помилка може зупинити завантаження, бо ранній етап підготовки системи припускає, що основні файлові системи змонтуються правильно.

Що робить Debian 13 під капотом

Debian 13 завантажується з systemd, який формує mount-юнити на підставі fstab. Ці монтування входять до таргетів на кшталт local-fs.target (локальні файлові системи змонтовано) і multi-user.target (звичайні сервіси). Якщо потрібне монтування зазнає невдачі, systemd може:

• опустити вас в emergency mode (root-оболонка, мінімум сервісів),
• або в rescue mode (трохи більше сервісів),
• або зависнути в очікуванні пристрою, що ніколи не з’явиться, залежно від опцій типу nofail, x-systemd.device-timeout= та від того, чи марковано монтування як обов’язкове.

На практиці режими відмов звужуються до кількох причин:

• Несумісність ідентифікаторів: неправильний UUID/LABEL/PARTUUID, перейменування пристрою, заміна або клонування диска.
• Невідповідність точки монтування: опечатка в директорії монтування, невірний тип файлової системи, відсутня директорія.
• Ланцюжок залежностей: одне монтування потрібне для іншого (наприклад, /var перед сервісами) або для unit’ів systemd, що вважають його наявним.
• Проблеми з файловою системою: несправний журнал, пошкоджений суперблок або неакуратне завершення роботи, що вимагає строгого монтування.
• Мережеві монтування: запис NFS/CIFS без потрібного _netdev / залежностей systemd для мережі, що блокує раннє завантаження.

Ключовий практичний момент: не «виправляйте» fstab здогадками. Збирайте докази. Підтверджуйте ідентифікатори. Переконайтеся в типі ФС. Подивіться на погляд systemd. Потім відредагуйте один раз.

Короткий жарт як механізм копінгу: /etc/fstab — єдиний файл, де відсутній пробіл може повалити весь сервер і при цьому виглядати образливо.

Швидкий план діагностики (перевірити перше/друге/третє)

Це послідовність «у мене п’ять хвилин перед тим, як хтось оголосить інцидент». Оптимізовано для швидкості і високого сигналу.

Перше: ідентифікуйте точне проблемне монтування та чому systemd на ньому наполягає

• В аварійній оболонці зламаної системи знайдіть невдалі юніти: systemctl --failed.
• Перегляньте логи mount-юнита: journalctl -xb і шукайте «mount» / «Dependency failed» / «timed out».
• Розв’яжіть: це обов’язкове локальне монтування (блокує завантаження), чи побажання (має бути nofail)?

Друге: перевірте ідентичність пристрою, а не ім’я пристрою

• Перелічіть блочні пристрої з UUID і типами ФС: lsblk -f і blkid.
• Питання: чи посилається fstab на UUID, якого немає? Якщо так — виправте на правильний UUID або використайте LABEL, якщо керуєте мітками.

Третє: визначте, чи можна змонтувати ФС або потрібен ремонт

• Спробуйте змонтувати в режимі лише читання для перевірки: mount -o ro.
• Якщо помилка пов’язана з корупцією чи журналом: запустіть відповідний fsck для ext*, або перевірте семантику xfs/btrfs (xfs використовує xfs_repair).
• Рішення: чи можна змонтувати read-only і виправити конфіг, чи потрібен ремонт перед іншими діями?

Четверте (тільки за потреби): обійти блокування, щоб завантажитися і виправити з повного userspace

• Тимчасово додайте nofail і короткий таймаут для неважливих монтувань.
• Або закоментуйте проблемний рядок, щоб дістатися до multi-user режиму, а потім виправити коректно у повній системі.
• Рішення: чи потрібне це монтування для коректності, чи вам важливіше швидко повернути хост в онлайн?

Цікаві факти та історичний контекст (бо це допомагає)

Розуміння, чому все виглядає саме так, пришвидшує дебаг. Ось кілька конкретних контекстних моментів, що важливі, коли ви в аварійній оболонці.

1. fstab існує ще до Linux. Ідея статичної таблиці файлових систем походить з традиційного Unix, задовго до ери hotplug-пристроїв.
2. Імена пристроїв нестабільні. /dev/sda може стати /dev/sdb після змін контролера; UUID були введені насамперед тому, що адміністратори втомилися від цієї гри.
3. systemd перетворює рядки fstab на юніти. Кожен запис стає .mount-юнитом і бере участь у графі залежностей. Одне невдале монтування може блокувати таргети.
4. nofail змінив культуру. Старі скрипти завантаження часто йшли далі; systemd за замовчуванням суворіший, якщо його не попрохати інакше.
5. Initramfs — це маленька ОС. Коли ви опиняєтеся в initramfs, ви в мінімальному середовищі, де деяких інструментів може не вистачати, а драйвери обмежені тим, що вбудовано.
6. UUID зберігаються в метаданих ФС. Клонування дисків може дублювати UUID, створюючи «правдоподібні» але неправильні монтування, якщо обидва присутні.
7. Раніше мережеві монтування обробляли пізніше. Сучасна паралелізація завантаження означає, що NFS/CIFS у fstab потребують явних мережевих залежностей або вони змагатимуться з мережею.
8. /etc/fstab досі важливий разом з автомонтуванням. Навіть з udev і десктопними автомонтувальниками сервери покладаються на передбачувані монтування під час завантаження для сервісів і логів.
9. Опції монтування — це операційна політика. Такі речі як errors=remount-ro, noatime і таймаути systemd більше про надійність, ніж про дрібну продуктивність.

Одна цитата, і я коротко закінчу. Парафраз Gene Kim: Надійність приходить зі створення систем, що відмовляють передбачувано і відновлювано, а не через герояміку.

Найшвидше виправлення в режимі rescue (покроково з рішеннями)

Мета — редагувати реальний /etc/fstab, а не той, що в середовищі rescue. Це звучить очевидно, доки ви не відредагуєте неправильний файл і не підете шукати чому нічого не змінилося.

Крок 0: виберіть середовище rescue

Використайте те, що дає оболонку з базовими інструментами для роботи з дисками:

• GRUB «Advanced options» → recovery mode (часто достатньо).
• Initramfs emergency shell (працює, але інструментів може бракувати).
• Debian installer у rescue-режимі або live ISO (краще за всіма інструментами).

Якщо ви вже в аварійній оболонці системи, можливо, зовнішні носії не потрібні. Але якщо бракує інструментів типу lsblk або nano, не терпіть — завантажте rescue ISO.

Крок 1: ідентифікуйте кореневу файлову систему та змонтуйте її у передбачуване місце

В режимі rescue / може бути системою rescue, а не вашим диском. Знайдіть реальний корінь і змонтуйте його під /mnt.

Крок 2: якщо у вас окремі /boot, /boot/efi, /var — змонтуйте й їх

Змонтувати лише корінь часто достатньо для редагування fstab. Але якщо плануєте перебудувати initramfs або торкатися конфігурацій завантажувача, змонтуйте також /boot та EFI.

Крок 3: редагуйте fstab, наче розміновуєте бомбу

Конкретно:

• Виправте неправильний UUID/LABEL/PARTUUID.
• Підтвердіть тип файлової системи (ext4 vs xfs vs btrfs).
• Для неважливих монтувань (бекапи, scratch, NFS) додайте nofail і розумний таймаут пристрою.
• Не «виправляйте» перехід на /dev/sdX, якщо не любите рулетку.

Крок 4: перевірте зміни перед перезавантаженням

Протестуйте змонтування всього з кореня встановленої системи за допомогою mount -a у chroot або mount --fake якщо потрібно. Якщо є помилки — ви не готові.

Крок 5: перезавантажтеся один раз, спостерігайте і підтверджуйте

Після перезавантаження підтвердіть монтування через findmnt і перевірте, що завантаження досягло потрібного таргету.

Другий короткий жарт: Щоразу, коли ви перезавантажуєтеся «подивитися, чи допомогло», інженер збереження даних втрачає трохи віри в людство.

Практичні завдання: команди, виводи та ваші рішення

Це завдання рівня on-call, які я реально виконую. Кожне містить: команду, приклад виводу, що це означає і яке рішення ви приймаєте. Виконуйте їх по порядку або переходьте до того, що відповідає на ваше поточне питання.

Завдання 1: Подивіться, що systemd вважає невдалим (з аварійної/rescue оболонки)

cr0x@server:~$ systemctl --failed
  UNIT                       LOAD   ACTIVE SUB    DESCRIPTION
● mnt-data.mount             loaded failed failed  /mnt/data
● local-fs.target            loaded failed failed  Local File Systems

LOAD   = Reflects whether the unit definition was loaded properly.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

2 loaded units listed.

Що це означає: один mount-юнит зазнав невдачі і потягнув за собою local-fs.target. Саме тому завантаження зупинилося.

Рішення: перевірте mnt-data.mount і відповідний рядок у fstab. Визначте, чи має воно бути обов’язковим, чи опціональним (nofail).

Завдання 2: Витягніть точну помилку з журналу

cr0x@server:~$ journalctl -xb --no-pager | tail -n 30
Dec 29 09:18:12 server systemd[1]: Mounting /mnt/data...
Dec 29 09:18:12 server mount[512]: mount: /mnt/data: special device UUID=2b1c2c1a-9c43-4b4b-9d63-0a6b7c3d9999 does not exist.
Dec 29 09:18:12 server systemd[1]: mnt-data.mount: Mount process exited, code=exited, status=32/n/a
Dec 29 09:18:12 server systemd[1]: mnt-data.mount: Failed with result 'exit-code'.
Dec 29 09:18:12 server systemd[1]: Failed to mount /mnt/data.
Dec 29 09:18:12 server systemd[1]: Dependency failed for Local File Systems.
Dec 29 09:18:12 server systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.

Що це означає: UUID у fstab відсутній. Це не проблема корупції ФС, а проблема ідентичності.

Рішення: знайдіть правильний UUID (або вирішіть зробити монтування опціональним) і виправте fstab.

Завдання 3: Перелічіть усі блочні пристрої з метаданими ФС

cr0x@server:~$ lsblk -f
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32 EFI    7A1B-2C3D                             498M     1% /boot/efi
├─nvme0n1p2 ext4   1.0   boot   0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d  712M    18% /boot
└─nvme0n1p3 ext4   1.0   root   4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f   38G    42% /
sda
└─sda1      ext4   1.0   data   9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a

Що це означає: ви бачите реальний UUID для data-диска (9c2b8d...). Той, що в журналі (2b1c2c...), неправильний.

Рішення: оновіть /etc/fstab, щоб використовувати правильний UUID або мітку.

Завдання 4: Перевірка через blkid (іноді ясніше)

cr0x@server:~$ blkid
/dev/nvme0n1p1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="7A1B-2C3D" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="8f9d0b0a-01"
/dev/nvme0n1p2: LABEL="boot" UUID="0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8f9d0b0a-02"
/dev/nvme0n1p3: LABEL="root" UUID="4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8f9d0b0a-03"
/dev/sda1: LABEL="data" UUID="9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c2b9c3a1-01"

Що це означає: авторитетна відповідність пристрій → UUID/LABEL.

Рішення: віддавайте перевагу UUID= або LABEL= в fstab. Уникайте /dev/sda1, якщо ви не в контрольованому середовищі і не розумієте ризик.

Завдання 5: Змонтуйте корінь встановленої системи з rescue ISO

cr0x@server:~$ mount /dev/nvme0n1p3 /mnt
cr0x@server:~$ ls /mnt
bin  boot  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Що це означає: ви змонтували реальний корінь файлової системи в /mnt.

Рішення: редагуйте /mnt/etc/fstab, а не /etc/fstab середовища rescue.

Завдання 6: Перевірте проблемний рядок у fstab

cr0x@server:~$ sed -n '1,200p' /mnt/etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f /     ext4  defaults,errors=remount-ro 0 1
UUID=0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d /boot ext4  defaults                  0 2
UUID=7A1B-2C3D                            /boot/efi vfat umask=0077              0 1
UUID=2b1c2c1a-9c43-4b4b-9d63-0a6b7c3d9999 /mnt/data ext4 defaults                0 2

Що це означає: запис для data монтування посилається на UUID, якого немає на машині.

Рішення: замініть UUID на правильний або закоментуйте рядок і додайте безпечний варіант.

Завдання 7: Швидко і безпечно виправте fstab (користуйтесь редактором, але ось мінімальний патч)

cr0x@server:~$ cp -a /mnt/etc/fstab /mnt/etc/fstab.bak.$(date +%s)
cr0x@server:~$ sed -i 's/UUID=2b1c2c1a-9c43-4b4b-9d63-0a6b7c3d9999/UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a/' /mnt/etc/fstab
cr0x@server:~$ tail -n 5 /mnt/etc/fstab
UUID=4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f /     ext4  defaults,errors=remount-ro 0 1
UUID=0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d /boot ext4  defaults                  0 2
UUID=7A1B-2C3D                            /boot/efi vfat umask=0077              0 1
UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults                0 2

Що це означає: ви випатчили неправильний UUID на правильний і зробили бекап (добре).

Рішення: перевірте, спробувавши змонтувати перед перезавантаженням.

Завдання 8: Створіть точку монтування, якщо помилка була «директорія не існує»

cr0x@server:~$ mkdir -p /mnt/mnt/data
cr0x@server:~$ ls -ld /mnt/mnt/data
drwxr-xr-x 2 root root 4096 Dec 29 09:27 /mnt/mnt/data

Що це означає: точка монтування тепер існує всередині кореня встановленої системи.

Рішення: якщо єдина проблема була в відсутній директорії, це може виправити завантаження. Все одно перевірте монтування.

Завдання 9: Перевірте монтування проти встановленого fstab (без chroot)

cr0x@server:~$ mount -a -T /mnt/etc/fstab -R /mnt
cr0x@server:~$ findmnt -R /mnt | tail -n 8
/mnt                 /dev/nvme0n1p3 ext4   rw,relatime,errors=remount-ro
/mnt/boot            /dev/nvme0n1p2 ext4   rw,relatime
/mnt/boot/efi        /dev/nvme0n1p1 vfat   rw,relatime,fmask=0077,dmask=0077
/mnt/mnt/data        /dev/sda1      ext4   rw,relatime

Що це означає: усі файлові системи змонтувалися успішно під /mnt з використанням fstab встановленої системи.

Рішення: можете перезавантажуватися з високою впевненістю. Якщо цей крок не вдався — не перезавантажуйтеся, виправте помилку зараз.

Завдання 10: Якщо потрібен chroot (для перебудови initramfs або перевірки systemctl)

cr0x@server:~$ mount --bind /dev  /mnt/dev
cr0x@server:~$ mount --bind /proc /mnt/proc
cr0x@server:~$ mount --bind /sys  /mnt/sys
cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# systemctl --failed
0 loaded units listed.

Що це означає: ви працюєте всередині встановленої системи. Попередні невдачі юнітів повинні зникнути, якщо лише проблема була в монтуванні.

Рішення: якщо ви змінювали щось, що впливає на раннє завантаження (крипто, LVM, драйвери), перебудуйте initramfs. Якщо ні — тримайте все максимально простим.

Завдання 11: Перебудова initramfs (тільки коли це дійсно релевантно)

cr0x@server:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Що це означає: initramfs згенеровано. Це важливо, якщо змінились механізми пошуку кореня, crypto-хуки або драйвери — не для простого опечатки у fstab, але інколи ви вирішуєте кілька проблем одразу.

Рішення: якщо торкалися конфігурацій стеку дисків — зробіть це. Якщо виправили лише опціональне монтування, можна пропустити, щоб зменшити ризик.

Завдання 12: Перевірте синтаксис fstab і виявляйте проблеми з табуляцією/пробілами перед перезавантаженням

cr0x@server:/# awk 'NF && $1 !~ /^#/ {print NR ": " $0}' /etc/fstab
2: UUID=4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f / ext4 defaults,errors=remount-ro 0 1
3: UUID=0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d /boot ext4 defaults 0 2
4: UUID=7A1B-2C3D /boot/efi vfat umask=0077 0 1
5: UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults 0 2

Що це означає: кожний активний рядок має поля; очевидних усічень немає. Це не виявить усіх семантичних помилок, але зловить «я випадково видалив половину рядка».

Рішення: якщо будь-який рядок виглядає пошкодженим — виправте його зараз. Синтаксично зламаний fstab — один із рідкісних способів перетворити дрібну проблему на неабияку пригоду.

Завдання 13: Якщо монтування не критичне — зробіть завантаження стійким

cr0x@server:/# cp -a /etc/fstab /etc/fstab.bak.$(date +%s)
cr0x@server:/# grep -n '/mnt/data' /etc/fstab
5: UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults 0 2
cr0x@server:/# sed -i 's|/mnt/data ext4 defaults|/mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10s|' /etc/fstab
cr0x@server:/# grep -n '/mnt/data' /etc/fstab
5: UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

Що це означає: якщо диск зникне згодом, завантаження не зависне назавжди. Це операційно розумно для монтувань, що не потрібні ОС для функціонування.

Рішення: робіть так для бекап-томів, scratch або «приємних» NFS. Не робіть цього для /, /var або всього, що потрібне сервісам — тихе пропущення таких монтувань породжує дивні відмови.

Завдання 14: Вийдіть, відмонтуйте чисто та перезавантажтеся

cr0x@server:/# exit
cr0x@server:~$ umount -R /mnt
cr0x@server:~$ reboot

Що це означає: ви залишаєте систему в консистентному стані. Відмонтування зменшує ризик брудного журналу від rescue-оточення.

Рішення: якщо umount -R каже, що щось зайняте — перевірте, чи немає шелів у /mnt і завершіть їх. Не відключайте живлення просто так, якщо не хочете додати fsck у свій день.

Типові помилки: симптом → корінна причина → виправлення

Цей розділ відвертий навмисно. Більшість збоїв через fstab — повторювані порушники.

1) Завантаження опускає в emergency mode: «special device UUID=… does not exist»

Симптом: журнал показує відсутній UUID; mount-юнит падає; local-fs.target не вдається.

Корінна причина: неправильний UUID у fstab (опечатка, диск замінено, клоновано або файлову систему відформатовано).

Виправлення: знайдіть правильний UUID за допомогою lsblk -f/blkid, оновіть /etc/fstab, перевірте через mount -a -T ... -R .... Якщо монтування опціональне — додайте nofail і короткий x-systemd.device-timeout.

2) Зависання на 90 секунд (або довше): «Timed out waiting for device»

Симптом: повільне завантаження, потім аварія; логи systemd показують таймаут пристрою.

Корінна причина: systemd чекав блочний пристрій, що не присутній або з’являється пізно (USB/SAN/iSCSI), а таймаут стоїть за замовчуванням і великий.

Виправлення: вирішіть, чи потрібне монтування. Якщо ні — використайте nofail,x-systemd.device-timeout=10s. Якщо потрібне — виправте виявлення пристрою (multipath, iSCSI порядок, драйвери, нехватка initramfs-хуків).

3) «Точка монтування не існує»

Симптом: монтування відпадає миттєво; журнал вказує на відсутню директорію.

Корінна причина: опечатка в шляху монтування або директорію видалили (часто через cleanup або помилкове rm -rf).

Виправлення: створіть директорію на корені файлової системи: mkdir -p /mnt/<mountpoint> (або в chroot). Перевірте права, якщо директорія використовується сервісами.

4) «невірний тип ФС, погана опція, поганий суперблок»

Симптом: mount повідомляє про проблеми зі суперблоком; може впасти в emergency.

Корінна причина: невірний тип ФС у fstab, або реальна корупція ФС, або спроба змонтувати не ту розділку у не те місце.

Виправлення: підтвердіть реальний тип через blkid. Якщо ext4: запустіть fsck -f з rescue (на незмонтованому). Якщо xfs: використайте xfs_repair з розумінням ризиків. Якщо btrfs: обережно користуйтеся btrfs check. Якщо ви вказали не той розділ — виправте запис у fstab на правильний UUID.

5) NFS/CIFS рядок блокує завантаження

Симптом: завантаження зупиняється або сильно затягується; логи згадують невдачі при монтуванні віддаленої ФС.

Корінна причина: мережа ще не готова, коли systemd намагається змонтувати; відсутній _netdev або підхід з автомонтуванням.

Виправлення: додайте _netdev,nofail,x-systemd.automount для неважливих шарів; або забезпечте правильні залежності systemd. Якщо це критично — потрібне явне впорядкування і таймаути, а не надія.

6) «Ви виправили fstab, але воно все одно не завантажується»

Симптом: та сама помилка після перезавантаження; ви впевнені, що редагували.

Корінна причина: ви відредагували /etc/fstab rescue-системи, а не встановленої; або змонтували не той корінь; або маєте кілька коренів (LVM, снапшоти).

Виправлення: перевірте, що змонтували встановлений корінь у /mnt і редагували /mnt/etc/fstab. Підтвердіть через cat /mnt/etc/debian_version і ls /mnt, де мають бути очікувані директорії та файли, специфічні для хоста.

Три корпоративні міні-історії з практики (анонімізовано)

Міні-історія 1: Інцидент від неправильної гіпотези

Вони переносили середній внутрішній сервіс на нове залізо: та ж Debian, той самий стек додатку, «лише швидші диски». План полягав у rsync кореня, прикріпленні другого диска для даних і відтворенні старого макету монтувань. Нічого складного. Тож хтось скопіював /etc/fstab зі старої машини як стартову точку.

Неправильна гіпотеза була тонкою: «UUID будуть іншими, але ми їх виправимо пізніше». Команда виправила очевидні речі: root і boot. Вони пропустили один рядок для /var/lib/app, який посилався на UUID з попереднього сервера. Така директорія існувала в корені теж, тож ніхто не помітив під час попередніх перевірок. Вона монтувалася неправильно — за ідентичністю старого сервера, якої на новому не було.

На першому завантаженні systemd спробував змонтувати, зазнав невдачі і опустив у emergency mode. Вікно міграції горіло. Люди почали обговорювати, чи зламався RAID-контролер. Хтось запропонував перевстановити образ. Класичний рух: трактувати конфігураційну проблему як апаратну, бо апарат відчувається «реальнішим».

Виправлення зайняло чотири хвилини, коли хтось припинив галас. У rescue-режимі вони запустили systemctl --failed, побачили юніт, виконали lsblk -f, знайшли реальний UUID і відредагували fstab. Потім додали x-systemd.device-timeout=10s, щоб майбутні тестові завантаження не зависали, коли storage-команда «тимчасово» вимикає LUN.

Урок нудний: не копіюйте fstab між машинами без явного кроку звірки. UUID — не декорація. Це істина, на якій базується завантаження.

Міні-історія 2: Оптимізація, що вдарила у відповідь

Інша компанія мала флот Debian-серверів, які писали багато логів і метрик. Хтось вирішив оптимізувати дисковий I/O, змонтувавши великий «scratch» том з агресивними опціями і виніс /var на окремий розділ. Ідея була порядна: ізолювати churn, не дати root заповнитися і зменшити розмір бекапів.

Провал стався через напівзавершений rollout. Додали нове монтування /var у fstab з шляхами /dev/disk/by-id/…, які були стабільні на тестовій машині. На проді ID дисків відрізнялися, бо закупили іншу модель у середині кварталу. Пристрій взагалі не існував на частині вузлів.

Ці вузли не падали «гарно». Деякі завантажувалися повільно через очікування systemd. Інші впадали в emergency, бо /var був потрібний і не маркований як nofail (і не мав ним бути). Тим часом команда скорочувала часи очікування для інших сервісів, щоб зменшити час завантаження. Дебаг став карнавалом часткових виправлень.

Вони відновилися швидко завдяки послідовному підходу: rescue ISO, змонтувати корінь, підтвердити пристрої lsblk -f, замінити by-id на UUID файлової системи, і потім протестувати mount -a під встановленим коренем перед перезавантаженням. Пізніше вони поліпшили rollout, присвоївши мітки файловим системам і використовуючи LABEL= для кількох критичних розділів.

Урок: «оптимізація», що підвищує варіативність між залізом — не оптимізація. Це борг у красивому обгортанні.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінансова компанія мала політику, яка здавалася надто суворою: будь-яка зміна /etc/fstab вимагала pre-check і post-check. Pre-check: підтвердити наявність цільового пристрою (blkid), переконатися, що точка монтування існує, і виконати dry-mount у maintenance-шеллі. Post-check: підтвердити через findmnt і переконатися, що таргети завантаження чисті.

Однієї ночі зміна в storage випадково видалила вторинний том з партії серверів через помилку зонування нагорі. Це не було злим наміром; це була втомлена людина з таблицею та довгим днем. Сервери перезавантажилися як частина планових патчів.

Без запобіжників ці машини застрягли б в emergency mode. Але вторинні монтування були навмисне марковані nofail з коротким x-systemd.device-timeout, бо вони використовувалися не критичними аналітичними джобами. Системи завантажилися, основні сервіси піднялися, і моніторинг сповістив про відсутню файлову систему як рівень application-warning, а не повний outage.

Що врятувало їх — не геній. Це була класифікація: критичні монтування — суворі; неважливі — стійкі. І процес змін мав достатньо тривації, щоб змусити інженера подумати: «Якщо цього диска не буде — чи має завантаження зупинитися?»

Урок: найкраща техніка надійності — це добре розташоване «це опціонально» разом з перевіркою, що воно дійсно опціональне.

Чеклісти / покрокові плани для стресових ситуацій

Чекліст A: Найшвидший шлях, якщо ви вже маєте emergency shell на хості

1. Запустіть systemctl --failed, щоб ідентифікувати ім’я mount-юнита.
2. Запустіть journalctl -xb і уважно прочитайте рядок про помилку монтування.
3. Запустіть lsblk -f і підтвердіть, що правильний UUID/LABEL існує.
4. Відредагуйте /etc/fstab (перед тим зробіть копію).
5. Якщо монтування не критичне: додайте nofail,x-systemd.device-timeout=10s.
6. Запустіть mount -a. Якщо є помилки — ви не завершили.
7. Запустіть systemctl daemon-reload (не завжди потрібно, але прибирає плутанину при ітераціях).
8. Перезавантажтеся один раз.

Чекліст B: Найбезпечніший шлях із rescue ISO (рекомендовано)

1. Завантажте rescue ISO / live-оточення.
2. lsblk -f, щоб ідентифікувати встановлений кореневий розділ.
3. mount /dev/<root> /mnt.
4. Якщо є окремі розділи: змонтуйте їх під /mnt (наприклад, /boot, /boot/efi).
5. Зробіть бекап /mnt/etc/fstab.
6. Відредагуйте /mnt/etc/fstab з правильними UUID і розумними опціями.
7. Перевірте через mount -a -T /mnt/etc/fstab -R /mnt.
8. Якщо потрібно: bind-mount /dev, /proc, /sys, потім chroot /mnt.
9. Вийдіть з chroot, umount -R /mnt, перезавантажтеся.

Чекліст C: Коли треба запустити систему негайно, а виправити пізніше (режим триажу)

1. В середовищі rescue закоментуйте невдалі рядки в fstab або зробіть їх nofail.
2. Переконайтеся, що обов’язкові монтування залишаються суворими (/, /var, /boot якщо потрібно).
3. Перевірте через mount -a.
4. Завантажтеся у multi-user і виправте коректно в рамках контролю змін: оновіть UUID, перевірте залежності додатку і заплануйте контрольований ремоунт/перезапуск.

Чекліст D: Післявідновна перевірка (не пропускайте)

1. findmnt і підтвердіть, що кожне потрібне монтування присутнє і правильне.
2. systemctl --failed порожній (або показує лише очікувані, некритичні невдачі).
3. journalctl -b -p warning не показує повторних спроб монтування або таймаутів.
4. Підтвердіть ідентичність дисків: lsblk -f відповідає fstab.
5. Якщо ви змінили поведінку опціональних монтувань, переконайтеся, що додаток коректно обробляє їхню відсутність (і що на це сигналізується моніторинг).

FAQ

1) Чи використовувати UUID, LABEL, PARTUUID чи /dev/sdX у fstab?

Для більшості файлових систем використовуйте UUID. Використовуйте LABEL, якщо у вас є сувора схема міток і ви хочете зручність для людей. Уникайте /dev/sdX для всього, що має значення; нумерація пристроїв змінюється після змін апаратного або прошивкового забезпечення. PARTUUID корисний, коли потрібно адресувати розділ ще до того, як створено ФС; для звичайних монтувань UUID — типовий вибір.

2) Система падає в initramfs. Це пов’язано з fstab?

Інколи. Якщо корінь не змонтувався, ви опинитесь в initramfs до запуску systemd. Зазвичай це не fstab (root контролюється командним рядком ядра і initramfs), але можуть бути й пізніші проблеми з fstab, що приведуть до emergency. Спочатку визначте, де ви: prompt initramfs чи emergency shell systemd.

3) Чи безпечно закоментувати проблемний рядок у fstab, щоб завантажитися?

Безпечно для неважливих монтувань. Небезпечно для монтувань, яких очікують додатки для коректності (БД, /var, персистентні черги). Якщо ви закоментуєте потрібне монтування, хост завантажиться в стані «працює, доки не зламається», коли сервіси почнуть писати дані в неправильне місце.

4) У чому різниця між rescue mode і emergency mode?

Emergency mode — це мінімальна root-оболонка з дуже малою кількістю сервісів; rescue mode піднімає більше системи (наприклад базові монтування і іноді мережу, залежно від конфігурації). Обидва призначені для відновлення, але emergency mode — це стан, коли systemd вважає звичайне завантаження небезпечним.

5) Чому systemd заблокував завантаження через монтування, яке не таке важливе?

Бо ви його так налаштували. За замовчуванням записи в fstab вважаються обов’язковими локальними файловими системами. Якщо монтування опціональне — додайте nofail і подумайте про x-systemd.device-timeout=. Для мережевих монтувань додайте _netdev і розгляньте x-systemd.automount, щоб уникнути блокування на старті.

6) Як перевірити fstab без перезавантаження?

На працюючій системі: mount -a спробує змонтувати все, що ще не змонтовано. З rescue ISO: змонтуйте встановлений корінь під /mnt і використайте mount -a -T /mnt/etc/fstab -R /mnt, щоб протестувати fstab встановленої системи без chroot.

7) Я змінив UUID при форматуванні ФС. Що тепер?

Оновіть fstab на новий UUID і перевірте через lsblk -f/blkid. Якщо це був data-том, який використовують додатки, перевірте власника/права і що точка монтування правильна — інакше сервіс може створити порожнє дерево директорій у корені і почати туди писати.

8) Монтування працює вручну, але падає при завантаженні. Чому?

Контекст при завантаженні відрізняється. Поширені причини: відсутня точка монтування на ранньому етапі, мережа ще не готова для NFS/CIFS, не вказані залежності (_netdev), зашифровані/LVM-томи не активуються рано, або таймаути systemd. Перегляньте journalctl -b для помилок при завантаженні і порівняйте з робочою командою mount.

9) Чи запускати fsck автоматично при падінні завантаження?

Лише коли лог вказує на корупцію ФС або нечищений журнал. Якщо лог каже «device does not exist», fsck марний. Якщо є «bad superblock» або «needs journal recovery» — так, запускайте відповідний інструмент, і тільки на незмонтованому диску.

10) Чи можна запобігти цьому класу відмов повністю?

Суттєво зменшити — можна: використовуйте стабільні ідентифікатори (UUID/LABEL), класифікуйте монтування як обов’язкові/опціональні, встановіть розумні таймаути і перевіряйте зміни fstab через mount -a перед перезавантаженням. Також не відправляйте правки fstab без плану відкату і доступу до консолі.

Висновок: наступні кроки, що запобігають повторенню

Виправлення збою завантаження через fstab рідко складне. Воно просто нещадне. Найшвидший шлях завжди однаковий: прочитайте помилку, підтвердіть ідентичність, відредагуйте правильний файл, протестуйте монтування, перезавантажтеся один раз.

Зробіть наступне:

• Класифікуйте монтування у вашому флоті: обов’язкові проти опціональних. Використовуйте nofail лише там, де відсутність дійсно прийнятна.
• Стандартизуйте ідентифікатори: UUID для більшості випадків, LABEL де людям потрібна читабельність і ви контролюєте іменування.
• Додайте стійкість часу монтування для опціональних пристроїв: короткі таймаути, уникнення блокування завантаження та оповіщення на рівні сервісів.
• Дисципліна змін: кожна правка fstab має починатися з cp -a бекапу, потім валідацією mount -a перед перезавантаженням.
• Тримайте план відновлення: IPMI/консольний доступ, перевірене rescue ISO і рукопис, що не передбачає наявності мережі, аби врятувати вас.

Якщо ставитися до /etc/fstab як до коду — переглянутого, перевіреного і впровадженого навмисно — воно припиняє бути лотереєю для завантаження і стає тим, чим завжди прагнуло бути: нудною таблицею монтувань.