Debian 13 застряг у initramfs: що це означає і як повернути систему в робочий стан

November 26, 2025 • February 3, 2026 • Читання: 7 хв • Views: 5

Було корисно?

Ви перезавантажилися після оновлення ядра або звичайної зміни сховища, і замість підказки для входу отримали крихітну оболонку ніби зі славних часів доткомів: (initramfs). Немає мережі. Немає сервісів. Лише ви та файловa система, яку не вдається змонтувати.

Це не означає, що «Linux зламався». Це означає, що Linux сказав правду: в ланцюжку завантаження виникла критична залежність (зазвичай повʼязана зі сховищем), і система відмовилася робити вигляд, що все гаразд. Ваше завдання — зʼясувати, яка залежність не спрацювала, виправити її з мінімальними втручаннями, а потім перебудувати артефакти завантаження, щоб не зустріти цю оболонку при наступному перезавантаженні.

Що таке «initramfs» насправді (і чого це не означає)

Коли Debian опускає вас у (initramfs), ви ще не «в Debian». Ви перебуваєте в невеликому тимчасовому середовищі виконання, завантаженому в ОЗП ядром. Його завдання — виконати ранню роботу при завантаженні: виявити сховище, завантажити модулі ядра, зібрати RAID/LVM, розблокувати шифрування і змонтувати реальний корінь файлової системи. Після успіху switch_root (або еквівалент) передає керування реальному користувацькому простору.

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

Зазвичай «застряг у initramfs» означає одне з наступного:

Ядро не бачить пристрій, який має бути кореневим (відсутній драйвер/модуль, змінилася назва пристрою, диск вийшов з ладу).
Пристрій існує, але ідентифікатор не відповідає (неправильний UUID/PARTUUID у GRUB або /etc/fstab).
Корінь має шари (LUKS, LVM, mdadm RAID, multipath), і ці шари не зібралися в initramfs.
Файлова система пошкоджена настільки, що mount не проходить, і initramfs відмовляється продовжувати.

Сухий факт: оболонка initramfs — це не кара. Це протипожежні двері. Ви можете використовувати її методично або панічно гортати випадкові команди, поки не зробите гірше. Оберіть методично.

Жарт №1: Оболонка initramfs схожа на чергу в аеропорті: це не те місце, де ви хотіли опинитися, але саме там помічають відсутні речі.

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

Це послідовність «зупинити кровотечу». Не починайте з перевстановлення GRUB. Не починайте з редагування випадкових UUID. Почніть з доказів: що існує, що повинно існувати, і чому вони відрізняються.

Спочатку: бачимо диски і потрібні модулі ядра?

Перевірте, які блочні пристрої існують (lsblk).
Перевірте, чи завантажений очікуваний модуль контролера (lsmod).
Пошукайте «timed out» або «unknown-block» у журналі ядра (dmesg).

По-друге: чи можна однозначно ідентифікувати пристрій для кореня?

Перелічіть UUID/PARTUUID файлових систем (blkid).
Перевірте, що використовує командний рядок ядра (cat /proc/cmdline).
Підтвердіть, чи корінь на простому розділі, LVM, mdadm RAID або LUKS.

По-третє: чи можемо зібрати шари і змонтувати корінь лише для читання?

Якщо RAID: mdadm --assemble --scan, потім перевірте /proc/mdstat.
Якщо LVM: vgscan, vgchange -ay, потім lvs.
Якщо LUKS: cryptsetup luksOpen, потім змонтуйте відображений пристрій.
Змонтируйте корінь у режимі readonly і перевірте логи/конфіг: mount -o ro … /mnt.

Коли ви змогли змонтувати корінь, можна ремонтувати конфіг і перебудувати initramfs/GRUB з chroot. Це переломний момент: зі «загадки» ви переходите до «контрольованого ремонту».

Цікаві факти та історія (що пояснює сучасні помилки)

Сучасна поведінка завантаження Debian — це сукупність рішень, прийнятих за два десятиліття. Помилки, які ви бачите в initramfs, по суті — ті шви між цими рішеннями. Трохи контексту допоможе діагностувати швидше.

initrd передував initramfs. Ранній Linux використовував initial ramdisk (образ блочного пристрою). initramfs пізніше перейшов на архів cpio, що розпаковується в tmpfs. Оболонка «initramfs», яку ви бачите, є нащадком цього переходу.
UUID стали популярними, бо імена пристроїв брехливі. /dev/sda може стати /dev/sdb залежно від порядку контролерів, часу підключення або особливостей прошивки. Стабільні ідентифікатори (UUID/PARTUUID) зменшили випадкові монтування невірного диска.
Проблеми з таймінгом udev реальні. Багато «root не знайдено» — це просто «root знайдено занадто пізно». Ось чому існують параметри rootdelay= і повідомлення initramfs «waiting for root device».
Збирання mdadm RAID перемістили раніше в завантаженні не випадково. Якщо ваш корінь на RAID1, без складання масиву не запустити користувацький простір. Ось чому в initramfs є хук для mdadm.
LVM — це дві проблеми: виявлення метаданих і активація. Initramfs має містити і інструменти, і конфіг для пошуку VG, а потім активації LV, щоб вони зʼявилися як блочні пристрої.
LUKS зробив «запит пароля під час завантаження» функцією завантаження. Заєнений корінь означає, що initramfs потребує cryptsetup і правил для ключового матеріалу. Якщо ці хуки відсутні, система навіть не зможе коректно попросити фразу-пароль.
Secure Boot змінив очікування щодо драйверів/модулів. Підписані ядра/модулі і суворіший ланцюжок завантаження означають, що відсутній або невідповідний модуль може бути фатальним раніше, ніж раніше.
Перевірки файлових систем стали більш консервативними. Ext4 і XFS поводяться по-різному при корупції; initramfs-скрипти часто відмовляються монтувати fs, якщо вважають її неконсистентною, бо продовження може призвести до ще гіршого пошкодження.
GRUB — це не все завантаження. GRUB завантажує ядро і initramfs; після цього GRUB в основному виходить з історії. Люди все ще звинувачують його, бо це останнє, що вони памʼятають побачити.

Основні режими відмов, що кидають у initramfs

1) Кореневий пристрій не знайдено (відсутній драйвер/модуль або зміни в апаратурі)

Класичний сценарій: ви змінили режим SATA в BIOS, пересунули диск на інший контролер, змінили тип сховища в віртуальній машині (virtio ↔ SCSI) або встановили ядро/initramfs, яке не містить потрібного модуля. Ядро завантажується, але вузли пристроїв для вашого кореня ніколи не зʼявляються.

2) Неправильний UUID/PARTUUID у GRUB або `/etc/fstab`

Можливо, ви клонували диск, відновили з бекапу, перегенерували файлову систему або замінили розділ. Ідентифікатори змінилися. Завантажувач і таблиця файлових систем все ще вказують на старі значення.

3) RAID не зібрано достатньо рано

Якщо корінь на mdadm RAID, initramfs має зібрати масив. Відсутність /etc/mdadm/mdadm.conf в initramfs, деградований масив або змінені метадані можуть зупинити збір. Пристрої існують, але корінь (масив) — ні.

4) LVM не активовано

Ви можете бачити PV, але не логічні томи. Без виконання vgchange -ay (або без інструментів LVM взагалі) корінь ніколи не зʼявиться.

5) LUKS не розблоковано (або ключі недоступні)

Шифрований корінь додає ранню залежність від cryptsetup і можливості запросити або отримати ключ. Якщо ви покладалися на ключовий файл на окремому розділі, і той розділ не змонтувався, виникає тупик.

6) Файлова система не монтується (корупція, невірний драйвер або невідповідні опції)

Ext4 зазвичай монтується навіть у поганому стані (іноді надто охоче). XFS може бути суворим. Btrfs може відмовитися, якщо бракує пристроїв. ZFS root має власну логіку імпорту. У всіх випадках initramfs зупиняється, бо не може безпечно змонтувати корінь.

7) Сам initramfs неправильний (старі хуки, відсутні бінарники, неправильна конфігурація)

Люди рідше перебудовують initramfs, ніж слід. Або вони перебудували його один раз і забули про інше ядро. Або оновили /etc/crypttab, але не перегенерували initramfs. Тоді при перезавантаженні ви отримуєте цілком послідовну помилку.

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

Все нижче написано для оболонки initramfs (подібної до BusyBox), якщо не вказано інше. Деякі команди можуть бути відсутні залежно від того, як було зібрано initramfs. Відсутність інструменту — це теж сигнал.

Завдання 1: Визначте, де ви і які інструменти доступні

cr0x@server:~$ uname -a
Linux (none) 6.12.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.6-1 (2025-01-05) x86_64 GNU/Linux
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.12.0-1-amd64 root=UUID=4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1 ro quiet
cr0x@server:~$ busybox
BusyBox v1.36.1 (Debian 1:1.36.1-9) multi-call binary.

Що це означає: Версія ядра важлива для доступності драйверів. Командний рядок показує, що воно вважає коренем. BusyBox підтверджує, що ви перебуваєте в мінімальному середовищі.

Рішення: Якщо root=UUID=... не відповідає жодному блочному пристрою, який ви побачите пізніше, готуйтеся виправляти ідентифікатори. Якщо в cmdline вказано /dev/sdX, плануйте перейти на UUID/PARTUUID після відновлення.

Завдання 2: Подивіться повідомлення ядра про виявлення сховища

cr0x@server:~$ dmesg | tail -n 40
[    2.011234] virtio_blk virtio0: [vda] 83886080 512-byte logical blocks (42.9 GB/40.0 GiB)
[    2.022110]  vda: vda1 vda2
[    6.104990] EXT4-fs (vda2): mounted filesystem with ordered data mode. Quota mode: none.
[    9.887650] VFS: Cannot open root device "UUID=4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1" or unknown-block(0,0): error -6
[    9.887690] Please append a correct "root=" boot option; here are the available partitions:
[    9.887720] 0100            4096 ram0
[    9.887740] 00ff          1048575 ram15
[    9.887760] 0b00        83886080 vda  driver: virtio_blk
[    9.887780]   0b01          1048576 vda1
[    9.887800]   0b02        82838528 vda2

Що це означає: Ядро бачить vda2, але не UUID, вказаний як корінь. Зазвичай це означає «неправильний UUID», а не «відсутній диск».

Рішення: Перейдіть до blkid і порівняйте UUID. Якщо диск зовсім не перелічений, переключіться на проблеми з драйвером/модулем.

Завдання 3: Перелічіть блочні пристрої та файлові системи

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINT
NAME   SIZE TYPE FSTYPE UUID                                 MOUNTPOINT
vda     40G disk
├─vda1   1G part vfat   2C1A-9F33
└─vda2  39G part ext4   7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a

Що це означає: У вас є кандидат на корінь ext4 з UUID 7e3b…, але в командному рядку завантаження вказано 4b3f….

Рішення: Або оновіть root= у GRUB до нового UUID, або відкотіть зміну диска/розділу, що її спричинила. Зазвичай: виправте конфігурацію і перебудуйте initramfs/GRUB, щоб зміни збереглися.

Завдання 4: Підтвердьте UUID старим добрим способом

cr0x@server:~$ blkid
/dev/vda1: UUID="2C1A-9F33" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="2f1e3e1b-01"
/dev/vda2: UUID="7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2f1e3e1b-02"

Що це означає: blkid — ваша основна істина для UUID файлових систем.

Рішення: Якщо командний рядок ядра використовує UUID, оновіть його. Якщо він використовує PARTUUID, порівнюйте саме ті значення. Не здогадуйтеся; копіюйте/вставляйте уважно.

Завдання 5: Спробуйте змонтувати підозрюваний корінь у режимі readonly

cr0x@server:~$ mkdir -p /mnt
cr0x@server:~$ mount -o ro /dev/vda2 /mnt
cr0x@server:~$ ls /mnt
bin  boot  dev  etc  home  lib  lib64  proc  root  run  sbin  usr  var

Що це означає: Файлова система змонтувалася. Чудово: це здебільшого невідповідність конфігурації, а не корупція.

Рішення: Перевірте /mnt/etc/fstab і конфіг завантажувача, потім перебудуйте initramfs і GRUB з chroot або середовища відновлення.

Завдання 6: Перевірте `/etc/fstab` на невідповідності, які вас підведуть пізніше

cr0x@server:~$ sed -n '1,120p' /mnt/etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/disk/by-uuid/4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1 / ext4 defaults,errors=remount-ro 0 1
UUID=2C1A-9F33  /boot/efi vfat umask=0077 0 1

Що це означає: fstab все ще посилається на старий UUID кореня (4b3f…). Навіть якщо ви виправите GRUB, пізніше монтування зазнає невдачі або ви потрапите в emergency mode після switch_root.

Рішення: Оновіть fstab до 7e3b… (фактичний UUID кореня), потім перебудуйте initramfs/GRUB в інстальованій системі, щоб все було послідовним.

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

cr0x@server:~$ cp -a /mnt/etc/fstab /mnt/etc/fstab.bak
cr0x@server:~$ sed -i 's/4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1/7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a/' /mnt/etc/fstab
cr0x@server:~$ grep ' / ' /mnt/etc/fstab
/dev/disk/by-uuid/7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a / ext4 defaults,errors=remount-ro 0 1

Що це означає: Ви узгодили fstab із реальністю.

Рішення: Тепер потрібно, щоб kernel cmdline root= також відповідав. Зазвичай за це відповідає GRUB.

Завдання 8: Перевірте, чи задіяний RAID (mdadm)

cr0x@server:~$ cat /proc/mdstat
Personalities : 
unused devices: <none>
cr0x@server:~$ mdadm --examine --scan
mdadm: No devices listed in conf file were found.

Що це означає: Наразі жодні RAID-пристрої не зібрані. Якщо ви очікували масиви md, це проблема.

Рішення: Якщо корінь на RAID, спробуйте зібрати: mdadm --assemble --scan і перевірте /proc/mdstat. Якщо RAID не передбачено, рухайтеся далі.

Завдання 9: Зберіть mdadm масиви (якщо потрібно)

cr0x@server:~$ mdadm --assemble --scan
mdadm: /dev/md0 has been started with 2 drives.
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 vda2[0] vdb2[1]
      41361408 blocks super 1.2 [2/2] [UU]
unused devices: <none>

Що це означає: RAID тепер активний і здоровий ([UU]).

Рішення: Якщо корінь має бути на /dev/md0, змонтуйте його і виправте конфіг завантаження, щоб посилатися правильно (UUID файлової системи на md-пристрої, або md UUID).

Завдання 10: Активуйте LVM (якщо потрібно)

cr0x@server:~$ vgscan
  Found volume group "vg0" using metadata type lvm2
cr0x@server:~$ vgchange -ay
  2 logical volume(s) in volume group "vg0" now active
cr0x@server:~$ lvs
  LV    VG  Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root  vg0 -wi-a----- 30.00g
  swap  vg0 -wi-a-----  8.00g

Що це означає: LV тепер доступні. Корінь може бути /dev/vg0/root.

Рішення: Якщо система використовує LVM для кореня, необхідно переконатися, що initramfs містить хуки для LVM і що root= вказує на правильний LV (за UUID іноді безпечніше, ніж за імʼям).

Завдання 11: Розблокуйте LUKS (якщо потрібно)

cr0x@server:~$ cryptsetup luksDump /dev/vda2 | head
LUKS header information
Version:        2
Epoch:          5
Metadata area:  16384 [bytes]
Keyslots:
  0: luks2
cr0x@server:~$ cryptsetup luksOpen /dev/vda2 cryptroot
Enter passphrase for /dev/vda2:
cr0x@server:~$ ls -l /dev/mapper/cryptroot
brw-------    1 root     root      253,   0 Dec 28 09:01 /dev/mapper/cryptroot

Що це означає: Ви створили розшифроване відображення. Корінь може бути всередині нього (можливо з LVM зверху).

Рішення: Якщо це працює вручну, але не під час завантаження, ймовірно, зіпсовано /etc/crypttab або в initramfs відсутні хуки cryptsetup або ключовий матеріал. Плануйте виправити і перебудувати initramfs з chroot.

Завдання 12: Перевірте стан файлової системи, якщо mount не вдається

cr0x@server:~$ mount -o ro /dev/vda2 /mnt
mount: mounting /dev/vda2 on /mnt failed: Structure needs cleaning
cr0x@server:~$ fsck.ext4 -fy /dev/vda2
e2fsck 1.47.1 (20-May-2024)
/dev/vda2: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vda2: 245321/2621440 files (0.3% non-contiguous), 1987654/10485760 blocks

Що це означає: «Structure needs cleaning» вказує на корупцію файлової системи, яка заважала монтуванню. fsck щось відновив.

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

Завдання 13: Якщо ви можете змонтувати корінь, зберіть реальні логи завантаження

cr0x@server:~$ mount -o ro /dev/vda2 /mnt
cr0x@server:~$ grep -R "ALERT!" -n /mnt/var/log | head
/mnt/var/log/boot.log:37:ALERT! /dev/disk/by-uuid/4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1 does not exist. Dropping to a shell!

Що це означає: Встановлена система вже зафіксувала помилку раніше. Зазвичай це невідповідність ідентифікаторів або відсутній шар.

Рішення: Користуйтесь точним рядком помилки для направлення виправлення. Не «оптимізуйте» — виправляйте саме те, що названо.

Завдання 14: Підготуйте chroot для стійких змін (з initramfs або rescue)

cr0x@server:~$ mount /dev/vda2 /mnt
cr0x@server:~$ mount /dev/vda1 /mnt/boot/efi
cr0x@server:~$ mount -t proc proc /mnt/proc
cr0x@server:~$ mount -t sysfs sys /mnt/sys
cr0x@server:~$ mount -o bind /dev /mnt/dev
cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# cat /etc/debian_version
trixie/sid

Що це означає: Ви працюєте всередині встановленої системи, з доступом до пакетних інструментів і конфігів у потрібному місці.

Рішення: Перебудуйте initramfs і оновіть GRUB звідти, щоб зміни збереглися між перезавантаженнями.

Завдання 15: Перебудуйте initramfs правильно (для ядра, яке ви завантажуєте)

cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# ls /boot
System.map-6.12.0-1-amd64  config-6.12.0-1-amd64  initrd.img-6.12.0-1-amd64  vmlinuz-6.12.0-1-amd64  efi
cr0x@server:/# update-initramfs -u -k 6.12.0-1-amd64
update-initramfs: Generating /boot/initrd.img-6.12.0-1-amd64

Що це означає: Debian згенерував образ initramfs для цього конкретного ядра.

Рішення: Якщо ви змінили /etc/crypttab, mdadm, lvm або модулі, цей крок є обовʼязковим. Якщо встановлено кілька ядер, розгляньте -k all, щоб не потрапити на старий зламаний образ при наступному завантаженні.

Завдання 16: Оновіть GRUB, щоб root= відповідав реальності

cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-1-amd64
Found initrd image: /boot/initrd.img-6.12.0-1-amd64
done
cr0x@server:/# grub-install /dev/vda
Installing for x86_64-efi platform.
Installation finished. No error reported.

Що це означає: Конфіг GRUB перегенеровано; GRUB встановлено на потрібну ціль (тут UEFI). На BIOS-системах ви побачите i386-pc і вбудовування в MBR/BIOS.

Рішення: Виконуйте grub-install лише за потреби (коли замінено диск, пошкоджено EFI-записи або відсутній завантажувач). Інакше update-grub зазвичай достатньо і менш ризиковано.

Завдання 17: Перевірте, що ідентифікатори у fstab можна розвʼязати

cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# findmnt --verify --verbose
Success, no errors or warnings detected

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

Рішення: Якщо findmnt --verify скаржиться, виправте ці записи перед перезавантаженням. Не повертайте в продакшн машину, яка «завантажується, але монтування розбиті».

Три корпоративні міні-історії з реального життя

Інцидент №1: Аварія через хибне припущення (імена пристроїв стабільні)

Середня компанія запускала Debian на флоті віртуалізаційних хостів. Кореневі розділи вказувалися в GRUB і /etc/fstab як /dev/sda2. «Працювало роками», і так технічний борг привчив їх втрачати пильність.

Вони додали новий HBA для розширення сховища. Після планового перезавантаження два хоста опинилися в initramfs. Диски були в порядку. ОС — ні. Новий контролер змінив порядок виявлення, і колишній /dev/sda став /dev/sdb. Система намагалася змонтувати невірний розділ як корінь; initramfs зупинилося, правильно відмовившись продовжувати з нісенітницею.

Перший респондент зробив те, що роблять багато в стресі: почав правити записи GRUB вручну на консолі, замінюючи sda2 на sdb2. Воно завантажилося. Те ж зробили на другому хості. Усі видихнули.

Але при наступному перезавантаженні порядок пристроїв знову змінився на одному хості, і він знову впав. Тоді вони виконали нудне правильне виправлення: перейшли на UUID у посиланнях кореня, перегенерували конфіг GRUB, перебудували initramfs і стандартизували флот.

Висновок не в «не додавайте HBA». Він у тому, що /dev/sdX — ефемерні імена в усіх місцях, які повинні пережити перезавантаження. Linux не обіцяє вам стабільність алфавіту.

Інцидент №2: Оптимізація, що обернулась проти («тонкий» initramfs не завантажував)

Команда SaaS хотіла швидше завантажувати вузли для автоскейлінгу. Хтось запропонував обрізати вміст initramfs: менше модулів, менше хуків, менший образ, швидше розпакування. Розумна ідея — поки не згадаєш, що ранній етап завантаження — це місце, де перевіряється реальність.

Вони налаштували генерацію initramfs так, щоб пропускати те, що «не потрібно». У staging це працювало, бо там був один профіль сховища: virtio диски, без шифрування, без RAID. Продакшн був різноманітнішим: деякі вузли з NVMe, деякі з SATA, деякі з LUKS через вимоги комплаєнсу, і кілька все ще на md RAID, бо так починався кластер роками раніше.

Під час оновлення ядра підмножина вузлів почала падати в initramfs. Initramfs більше не містило NVMe-модуля в деяких образах, і cryptsetup-хук в інших. Вони не мали «зламаних серверів». Вони просто чесно виконували те, що їм склали у вигляді артефактів завантаження.

Виправлення не полягало в додаванні «rootdelay» і надії. Вони відкотили обрізання, перебудували initramfs з правильними хуками, а потім ввели контрольовану матрицю: один образ на профіль сховища. Також додали передперезавантажувальний контроль: перевіряти, що initramfs містить потрібні модулі для платформи.

Оптимізація не заощадила часу. Вона перенесла час із «шляху завантаження» у «реакцію на інцидент», що є найдорожчим обчисленням: увага людини о 2 ранку.

Інцидент №3: Нудна практика, що врятувала день (задокументоване відновлення + послідовні ідентифікатори)

Фінансова організація запускала Debian на базах даних із шифрованим коренем і LVM. Середовище було нудним у найкращому сенсі: послідовне розділення, монтування за UUID і стандартна процедура «відновлення після завантаження». Це існувало тому, що хтось уже один раз заплатив за хаос.

Одного ранку подія з електропостачання вивела з ладу стійку. Після відновлення живлення кілька серверів зупинилися в initramfs з повідомленнями про неочищену файлову систему і затримані пристрої. Ніхто не панікував, бо у них був план дій, який тестували щоквартально.

On-call виконав кроки: перевірити виявлення пристроїв, вручну розблокувати LUKS, активувати LVM, змонтувати корінь readonly, за потреби виконати fsck, потім chroot і перебудувати initramfs, щоб гарантувати правильність хуків. Вони також перевірили SMART до оголошення перемоги.

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

Жарт №2: Найнадійніші системи будуються на нудних звичках, тому їх рідко запрошують на захопливі наради.

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

Саме тут живе більшість «квитків initramfs назавжди»: не в глибоких багах ядра, а в передбачуваному дрейфі конфігурації. Використовуйте цей розділ як довідник.

«ALERT! /dev/disk/by-uuid/… does not exist» → неправильний UUID → оновіть ідентифікатори і перебудуйте

Симптом: initramfs виводить ALERT про відсутній UUID і кидає в оболонку.
Корінна причина: UUID файлової системи змінився (клон/відновлення/форматування) або конфіг вказує на старий диск.
Виправлення: Використайте blkid, щоб знайти реальні UUID; оновіть /etc/fstab і конфіг GRUB; виконайте update-initramfs і update-grub.

«Gave up waiting for root device» → пристрій зʼявляється пізно або ніколи → додайте драйвер, виправте модулі або додайте затримку

Симптом: Повідомлення про очікування root, а потім невдача.
Корінна причина: Відсутній модуль контролера в initramfs або повільне виявлення сховища (USB/NVMe через дивну прошивку).
Виправлення: Переконайтеся, що модуль включено (встановіть відповідні пакети, додайте в /etc/initramfs-tools/modules), перебудуйте initramfs. Лише якщо апарат повільно, але коректно зʼявляється, тимчасово додайте rootdelay=10.

«Volume group not found» → відсутні інструменти LVM/хук → додайте lvm2 в initramfs

Симптом: Немає /dev/vg0/root, vgscan не виявляє або відсутній.
Корінна причина: lvm2 не встановлено або не включено в initramfs; або невірний фільтр у конфігурації LVM.
Виправлення: З chroot: встановіть/відновіть lvm2, виконайте update-initramfs -u -k all. Уникайте надмірного фільтрування пристроїв, якщо ви точно не знаєте чому.

«Cannot unlock /dev/… (cryptsetup: not found)» → відсутній cryptsetup → перебудуйте initramfs з cryptsetup

Симптом: Відсутній запит фрази-пароля або помилки cryptsetup.
Корінна причина: Пакет/hook cryptsetup відсутній в initramfs, або /etc/crypttab пошкоджено.
Виправлення: Виправте /etc/crypttab, переконайтеся, що встановлено cryptsetup-initramfs, перебудуйте initramfs.

«md0 stopped/does not exist» → RAID не збирається → виправте конфіг mdadm і initramfs

Симптом: Масиви відсутні в /proc/mdstat.
Корінна причина: Конфіг mdadm не вбудовано в initramfs, UUID масиву змінився або змінилися імена пристроїв.
Виправлення: Зберіть вручну, щоб довести працездатність; оновіть /etc/mdadm/mdadm.conf; перебудуйте initramfs.

«Structure needs cleaning» або помилка mount → корупція файлової системи → fsck/xfs_repair і дослідження стану диска

Симптом: mount не вдається; fsck повідомляє про виправлення.
Корінна причина: Нечисте завершення роботи, помилки I/O або реальна відмова носія.
Виправлення: Запустіть відповідний інструмент відновлення; потім перевірте SMART і журнали ядра на помилки I/O. Якщо помилки тривають — не довіряйте цьому диску.

Завантаження працює лише один раз після ручних правок → ви виправили симптом, а не систему → зробіть зміни постійними

Симптом: Правки GRUB на завантажувальному екрані дозволяють зайти, але після перезавантаження все ламається знову.
Корінна причина: Ви не перегенерували конфіг GRUB або initramfs в інстальованій системі.
Виправлення: Змонтуйте корінь, chroot, внесіть зміни в /etc/default/grub, /etc/fstab, /etc/crypttab, потім виконайте update-grub і update-initramfs.

Контрольні списки / покроковий план (повернутися в зелений статус)

Чекліст A: Мінімальні кроки для одноразового завантаження (режим триажу)

В оболонці initramfs виконайте cat /proc/cmdline і запишіть, чим має бути корінь.
Виконайте lsblk і blkid, щоб побачити, що існує.
Якщо корінь зашифрований: cryptsetup luksOpen.
Якщо корінь на LVM: vgscan потім vgchange -ay.
Якщо корінь на RAID: mdadm --assemble --scan.
Змонтируйте корінь readonly; перегляньте /etc/fstab і /var/log/boot.log на предмет явних помилок.
Якщо mount не вдається: запустіть інструмент відновлення файлової системи, що підходить вашому FS.
Перезавантажуйтеся лише після приведення ідентифікаторів у відповідність, інакше потрапите в той самий цикл.

Чекліст B: Стійкі кроки відновлення (щоб запобігти повторенню)

Змонтуйте корінь і (за потреби) EFI-партію в /boot/efi.
Bind-монтуйте /dev, змонтуйте /proc і /sys, потім chroot.
Виправте /etc/fstab, щоб використовувати правильні UUID/PARTUUID (надавайте перевагу UUID для файлових систем, PARTUUID для розділів у деяких сценаріях завантаження).
Виправте /etc/crypttab і /etc/mdadm/mdadm.conf, якщо використовуються.
Перегенеруйте initramfs для всіх встановлених ядер: update-initramfs -u -k all.
Перегенеруйте конфіг GRUB: update-grub.
Встановлюйте GRUB лише якщо сам завантажувач пошкоджено або змінилися диски/EFI-записи: grub-install ....
Запустіть findmnt --verify --verbose, щоб перевірити монтування.
Перезавантажтеся і спостерігайте консоль. Якщо це віддалений сервер, тримайте підключену OOB-консоль при першому перезавантаженні.

Чекліст C: Якщо в initramfs немає потрібних інструментів

Завантажтеся з інсталятора Debian/rescue ISO або live-образу.
Змонтуйте кореневу файлову систему під /mnt (плюс EFI, якщо потрібно).
Chroot і встановіть відсутні пакети: lvm2, mdadm, cryptsetup-initramfs за потреби.
Перебудуйте initramfs і GRUB з chroot.

Поширені питання

1) Чи означає initramfs, що моя інсталяція пошкоджена?

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

2) Я бачу диск у `lsblk`. Чому він не може змонтувати корінь?

Бо «диск існує» не те саме, що «ідентифікатор кореня співпадає» або «шари зібрані». Порівняйте UUID через blkid. Якщо використовується шифрування/LVM/RAID, корінь може бути всередині відображеного пристрою, який ще не створено.

3) Чи слід додати `rootdelay=` щоб це виправити?

Лише якщо пристрій зʼявляється пізно, але постійно (поширено для деяких USB-завантажень або дивної прошивки). Якщо UUID неправильний або драйвер відсутній, rootdelay лише змусить вас довше чекати ту саму помилку.

4) Чому це сталося відразу після оновлення ядра?

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

5) Я редагував GRUB під час завантаження і це спрацювало. Як зробити це постійним?

Завантажіться, змонтуйте корінь, chroot, виправте /etc/default/grub або реальні посилання на UUID, потім виконайте update-grub. Якщо потрібні зміни в initramfs — виконайте update-initramfs -u -k all.

6) Чи можна просто повернутися до посилань на `/dev/sda2`?

Можете, але ви свідомо обираєте крихкість. Стабільні ідентифікатори існують, бо перелік пристроїв нестабільний. Використовуйте UUID/PARTUUID, якщо не любите рулетку при завантаженні.

7) У чому різниця між виправленням `/etc/fstab` і виправленням `root=` у GRUB?

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

8) Чи безпечно запускати ремонт файлової системи з initramfs?

Часто це безпечніше, бо менше речей змонтовано. Проте: запускайте лише інструмент, що відповідає вашій FS, і віддавайте перевагу спочатку діагностиці та readonly. Якщо підозрюєте апаратні збої, ремонти можуть не закріпитися.

9) Моя оболонка initramfs не має `lvm` або `mdadm`. Що робити?

Завантажтеся в середовище відновлення, змонтуйте систему, chroot, встановіть відсутні пакети, потім перебудуйте initramfs. Якщо інструментів немає в initramfs, воно не зможе зібрати ваш стек сховища під час завантаження.

10) Як зрозуміти, чи це апаратна проблема?

Шукайте помилки I/O у dmesg, повторювану корупцію файлової системи, зникнення пристроїв або невдачі SMART (з rescue-середовища). Конфіг-проблеми зазвичай провалюються стабільно; апаратні — творчо.

Наступні кроки, щоб уникнути повторення

Підказка initramfs — це симптом, а не діагноз. Вона повідомляє одне: «корінь не змонтовано». Ваше завдання — відповісти на питання чому з доказами: блочні пристрої, ідентифікатори і збір шарів сховища.

Зробіть наступне, у такому порядку:

Узгодьте ідентифікатори. Вирівняйте root=, /etc/fstab і конфіги шарів (crypttab, mdadm, LVM) з тим, що показує blkid.
Перебудуйте initramfs для всіх ядер, які ви можете завантажити. Якщо виправити лише поточне ядро, наступне перезавантаження може використати старий зламаний образ.
Перегенеруйте конфіг GRUB. Встановлюйте GRUB лише за потреби.
Стандартизуйте і документуйте. Якщо ви керуєте кількома системами, уніфікуйте стек кореня (UUID, однакова схема розділів, однакова стратегія шифрування/LVM/RAID) і тримайте перевірений чекліст відновлення.

Одна цитата, яку варто тримати в голові під час таких інцидентів: «Надія — це не стратегія.» (парафразована ідея, часто повторювана в інженерних/операційних колах)

Коли ви відновите систему, розглядайте інцидент як подарунок: він показав, де ваш ланцюг завантаження покладається на племінні знання. Виправте цю залежність. Майбутній ви буде менше стомлений.

Схожі статті

Debian 13: Відновлення доступу root через rescue mode — не погіршіть ситуацію