Завантаження Linux: коли GRUB «працює», а система не вантажиться — відновлення без паніки

February 23, 2026 • February 23, 2026 • Читання: 6 хв • Views: 1

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

Ви перезавантажуєте Linux-машину. GRUB з’являється ніби задоволений собою. Ви обираєте ядро. Екран мерехтить. Потім: чорний екран, kernel panic, оболонка initramfs або запит systemd emergency, що виглядає так, ніби прокинувся сердитим.

Це найгірший тип помилки завантаження, бо здається, що прогрес є. «GRUB працює» — це не діагноз; це лише доказ того, що прошивка знайшла щось виконуване. Справжня робота — знайти кореневу файлову систему, завантажити драйвери, зібрати сховище і запустити PID 1 — відбувається після GRUB, і саме там ховаються проблеми.

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

Поява меню GRUB означає:

Прошивка (UEFI або BIOS) знайшла GRUB (або shim у налаштуваннях Secure Boot) та виконала його.
GRUB може прочитати достатньо диска, щоб завантажити свою конфігурацію та показати записи.

Це все. Це не означає:

Що ядро бачить контролер диска (не вистачає драйвера? інший PCI ID? ласкаво просимо в initramfs).
Що UUID кореневої файлової системи відповідає реальності (клон, форматування, відбудова RAID, імпорт ZFS, відновлення заголовка LUKS…).
Що LVM/VG активовано (або mdadm зібрав масив) до монтування кореня.
Що /etc/fstab коректний (одна помилка може перетворити завантаження на імпровізаційний танець).
Що systemd може змонтувати залежності або запустити критичні сервіси (мережеві монтування, зашифровані томи і «хитрі» таймаути — часті винуватці).

Загальне правило: якщо ви можете обрати ядро, але система не вантажиться, ви в зоні kernel args, initramfs contents, storage assembly і userspace mount/service ordering. Добра новина: це відновлювано. Погана новина: здогадки крадуть години.

Жарт №1: GRUB — як ресепціоністка, що посміхається і каже «вас чекають», прямо перед тим як охорона покличе вас у коридорі.

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

Це послідовність «перестань панікувати», яку я використовую в продакшені. Мета — швидко знайти вузьке місце, а не висловлювати свої емоції консолі.

Перший крок: класифікуйте стадію збою за 60 секунд

Чи бачите ви взагалі повідомлення ядра?
- Якщо ні: можливо, зависання при передачі графіки, Secure Boot або поганий образ ядра/initramfs.
- Якщо так: читайте далі; ваше ядро працює.
Чи потрапляєте ви в оболонку initramfs/dracut «екстрена оболонка»?
- Якщо так: коренева файл.система не монтується/не знайдена або стек сховища не зібраний.
Чи потрапляєте ви в режим екстреного завантаження systemd?
- Якщо так: ядро змонтувало корінь, а потім користувацький простір не зміг змонтувати/запустити сервіси (часто /etc/fstab або критичний unit).
Чи бачите ви «Kernel panic – not syncing: VFS: Unable to mount root fs»?
- Якщо так: невідповідність root device/driver, неправильний root=, відсутні модулі initramfs або невірний тип файлової системи.

Другий крок: перевірте ідентифікатор кореня (UUID/LABEL/device mapper) перед будь-якими змінами

Більшість інцидентів «GRUB працює, але не вантажиться» — це проблеми ідентичності: UUID змінились, імена пристроїв переставалися, або шари шифрування/LVM/RAID недоступні у потрібний момент.

Третій крок: вирішіть режим відновлення: редагувати kernel args чи завантажитись з live media

Якщо ви можете потрапити до initramfs або systemd emergency mode, часто можна виправити без live media.
Якщо ви не отримуєте шелу (порожній екран, миттєвий ребут), переходьте на live media раніше. Не грайтеся у героя, поки таймер простою тікає.

Одне принципове правило

Спочатку робіть зворотні зміни. Редагування kernel args в GRUB для одного завантаження, монтування файлових систем у режимі лише для читання, регенерація initramfs — це зворотні кроки. Бездумне переписування таблиць розділів — як створити другий інцидент всередині першого.

Цікаві факти та історія для інцидентної наради

Факт 1: Назва GRUB походить від «Grand Unified Bootloader», це типова GNU-era звичка давати іменам риторичний характер.
Факт 2: UEFI замінив стару модель BIOS, але багато збоїв досі відчуваються як 1999 рік — просто складність завантаження перемістилася шарами.
Факт 3: Імена пристроїв Linux, як /dev/sda, ніколи не були стабільними ідентифікаторами; UUID і PARTUUID з’явилися, бо «порядок дисків» — хаос.
Факт 4: initramfs замінив старіший підхід initrd у багатьох дистрибутивах, зробивши ранній користувацький простір модульним — і відсутність модулів стала частою причиною збою.
Факт 5: systemd зробив завантаження більш спостережуваним і більш паралельним, що покращило швидкість і логування — але також зробило порядок і таймаути реальною операційною проблемою.
Факт 6: Secure Boot додав не лише перевірки підписів; він змінив ланцюжок довіри, тож «завантажується з USB» більше не доказ, що воно запустить на реальній прошивці.
Факт 7: Ключова логіка навколо аргументу kernel root=UUID= та initramfs випробувана роками, але клонування дисків і досі часто ламає її.
Факт 8: Збирання RAID під час завантаження історично крихке, бо час має значення: ядро бачить диски раніше, ніж mdadm знає, що з ними робити.
Факт 9: LVM став популярним частково тому, що дозволяв resize і snapshot без переформатування — але також означає, що неактивований VG може заблокувати завантаження.

Конвеєр завантаження: де насправді відбуваються збої

Ось конвеєр, у практичних термінах SRE:

Прошивка (UEFI/BIOS) знаходить запис завантаження і виконує лоадер (GRUB, shim, systemd-boot тощо).
GRUB завантажує ядро і initramfs, передає аргументи kernel command line.
Ядро ініціалізує апаратні драйвери (built-in спочатку, модулі пізніше), монтує початковий root з initramfs.
Користувацький простір initramfs виконує скрипти (dracut, initramfs-tools) для зборки сховища: розшифровує LUKS, збирає md RAID, активує LVM, імпортує ZFS, завантажує відсутні модулі, а потім монтує реальний корінь файлової системи.
switch_root / pivot_root відбувається: система переходить від initramfs до реального root.
PID 1 (systemd) запускається, читає unit-файли, монтує /etc/fstab, запускає сервіси.

Якщо GRUB завантажився, але завантаження провалилося, розрив зазвичай відбувається на кроках 3–6. Ваше завдання — визначити, який крок відмовляє і чому. Логи існують — навіть коли здається, що їх нема. Потрібно просто знати, де шукати.

Корисна операційна цитата — коротко і трохи перефразовано, бо точність важлива:

Річард Кук (перефразована ідея): «Успіх будується на адаптації; відмова рідко має одну причину.»

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

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

оболонка initramfs/dracut
режим systemd emergency
live USB / rescue ISO (часто найпростіше для постійних ремонті)

Кожне завдання включає: команду, що означає її вивід, і рішення на її підставі. Виконуйте їх послідовно, коли можете. Не влаштовуйте хаотичних змін.

Завдання 1: Подивіться рядок команд ядра, з яким ви фактично завантажились

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0 root=UUID=2a1b... ro quiet splash

Що це означає: Це істина, а не те, що ви вважаєте, що налаштовано в GRUB.

Рішення: Якщо root= вказує на UUID, якого не існує, ви женетесь за неправильним коренем. Якщо бачите дивні прапори (rd.luks.uuid=, rd.md.uuid=, rootflags=), ви знаєте, який ранній підсистем працює.

Завдання 2: Ідентифікуйте диски, розділи та UUID файлових систем

cr0x@server:~$ lsblk -f
NAME        FSTYPE      FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1      vfat        FAT32       6C1A-9B2E                             400M     3%  /boot/efi
├─sda2      ext4        1.0         2a1b1111-2222-3333-4444-555555555555
└─sda3      crypto_LUKS 2           9d7c... 
  └─cryptroot
            LVM2_member LVM2 001    ...
    ├─vg0-root
            ext4        1.0         7c2d...
    └─vg0-swap
            swap        1           a1b2...

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

Рішення: Підтвердьте, чи існує UUID з /proc/cmdline. Якщо ні — виправте конфіг GRUB або відкоригуйте root= для одного завантаження, щоб зайти і виправити правильно.

Завдання 3: Підтвердіть, що кореневу файлову систему можна змонтувати (спочатку лише для читання)

cr0x@server:~$ mkdir -p /mnt/root
cr0x@server:~$ mount -o ro /dev/vg0/root /mnt/root
cr0x@server:~$ echo $?
0

Що це означає: Код виходу 0 означає, що файлова система монтується. Якщо не вдається, рядок помилки — золото: скопіюйте його.

Рішення: Якщо mount падає з «unknown filesystem», у вас бракує підтримки файлових систем у ядрі або модулів в initramfs. Якщо «bad superblock» — ви в зоні ремонту файлових систем, а не завантажувача.

Завдання 4: Якщо ви в dracut/initramfs, перелічіть завантажені модулі і завантажте відсутній драйвер сховища

cr0x@server:~$ lsmod | head
Module                  Size  Used by
xhci_hcd               28672  0
nvme                   53248  0
dm_mod                180224  0
cr0x@server:~$ modprobe ahci
cr0x@server:~$ dmesg | tail -n 5
[   12.441] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3 impl SATA mode
[   12.512] scsi host0: ahci

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

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

Завдання 5: Для LUKS: відкрийте зашифрований контейнер і перевірте, чи з’явилися mapper-пристрої

cr0x@server:~$ cryptsetup luksOpen /dev/sda3 cryptroot
Enter passphrase for /dev/sda3:
cr0x@server:~$ ls /dev/mapper
control  cryptroot

Що це означає: Якщо cryptroot з’явився, розшифрування працює, і проблема далі — LVM, монтування fs, fstab.

Рішення: Якщо cryptsetup падає, підозрюйте: неправильний шлях пристрою, зламаний initramfs без крипто-модулів або пошкоджений заголовок LUKS (рідко, але катастрофічно).

Завдання 6: Для LVM: скануйте і активуйте volume group

cr0x@server:~$ lvm pvscan
  PV /dev/mapper/cryptroot   VG vg0   lvm2 [<930.00 GiB / 0    free]
  Total: 1 [<930.00 GiB] / in use: 1 [<930.00 GiB] / in no VG: 0 [0   ]
cr0x@server:~$ lvm vgchange -ay
  2 logical volume(s) in volume group "vg0" now active

Що це означає: Ваш VG існує і його можна активувати. Якщо він не показується, ранній етап завантаження не бачить PV (драйвер) або розшифровування не відбулося.

Рішення: Якщо активація робить томи видимими, перебудуйте initramfs для включення LVM-інструментів/хуків або виправте конфіг dracut.

Завдання 7: Для mdadm RAID: зберіть масиви і перевірте стан

cr0x@server:~$ mdadm --assemble --scan
mdadm: /dev/md0 has been started with 2 drives.
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976630336 blocks super 1.2 [2/2] [UU]

Що це означає: [UU] вказує, що обидва члени присутні. [U_] вказує на деградований масив; він все ще може завантажуватись, залежно від розмітки.

Рішення: Якщо потрібно збирати вручну, ймовірно ваш initramfs не містить конфіг mdadm або таймінг udev порушений. Виправлення — перебудова initramfs і правильний mdadm.conf.

Завдання 8: Визначте, чи ви падаєте в initramfs чи в користувацький простір за допомогою журналів

cr0x@server:~$ journalctl -xb -p err
-- No entries --
cr0x@server:~$ journalctl -xb | tail -n 30
...
systemd[1]: Failed to mount /data.
systemd[1]: Dependency failed for Local File Systems.
systemd[1]: Starting Emergency Shell...

Що це означає: В режимі systemd emergency, journalctl -xb часто найшвидший шлях до точного невдалого unit.

Рішення: Якщо провал — mount unit або local-fs.target, перевірте /etc/fstab. Якщо це сервіс — вирішіть, чи можна тимчасово його замаскувати, щоб відновити вузол.

Завдання 9: Безпечно перевірте /etc/fstab (і виправте типові пастки)

cr0x@server:~$ cat /etc/fstab
UUID=7c2d...  /      ext4  defaults,errors=remount-ro  0 1
UUID=6C1A-9B2E /boot/efi vfat umask=0077              0 1
UUID=deadbeef-... /data  ext4  defaults               0 2

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

Рішення: Для некореневих файлових систем додайте nofail і розумний таймаут, щоб не зависати при відсутніх дисках. Root має бути правильним, не опціональним.

Завдання 10: Зі сторінки GRUB тимчасово відредагуйте запис для перевірки гіпотез

У меню GRUB натисніть e для редагування, потім змініть рядок Linux. Типові тимчасові зміни:

Видалити quiet splash, щоб бачити повідомлення.
Додати systemd.unit=emergency.target, щоб швидше отримати шел.
Додати rd.break (dracut), щоб зупинитись в initramfs перед монтуванням кореня.
Перевизначити root: root=/dev/vg0/root або root=UUID=....

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

Завдання 11: Chroot з live media (надійний спосіб зробити постійні ремонти)

cr0x@server:~$ mount /dev/vg0/root /mnt
cr0x@server:~$ mount /dev/sda2 /mnt/boot
cr0x@server:~$ mount /dev/sda1 /mnt/boot/efi
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:~$ uname -r
6.1.0-26-amd64

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

Рішення: Використовуйте chroot для регенерації initramfs, перевстановлення GRUB, виправлення конфігів і запуску перевірок файлових систем за потреби.

Завдання 12: Перебудуйте initramfs (бо ранній-boot — там де помирають мрії)

Стиль Debian/Ubuntu:

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.1.0-26-amd64

Стиль RHEL/CentOS/Fedora (dracut):

cr0x@server:~$ dracut -f --kver 6.8.0-0.rc3.202.fc40.x86_64
dracut: Executing: /usr/bin/dracut -f --kver 6.8.0-0.rc3.202.fc40.x86_64

Що це означає: Це перепаковує ранній користувацький простір. Відсутні драйвери, mdadm правила, LVM інструменти, крипто-модулі — тут їх виправляють.

Рішення: Якщо система стартує лише після ручних modprobe/vgchange/mdadm кроків, перебудова initramfs — не опціональна; це фактичне виправлення.

Завдання 13: Правильно перевстановіть GRUB (UEFI vs BIOS має значення)

Приклад для UEFI:

cr0x@server:~$ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
Installing for x86_64-efi platform.
Installation finished. No error reported.
cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-26-amd64
Found initrd image: /boot/initrd.img-6.1.0-26-amd64
done

Що це означає: GRUB встановлено у правильний EFI System Partition і його конфіг згенеровано заново.

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

Завдання 14: Перевірте UEFI NVRAM записи завантаження (коли «перемагає» неправильний диск)

cr0x@server:~$ efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* GRUB    HD(1,GPT,4d2f...,0x800,0x100000)/File(\EFI\GRUB\grubx64.efi)
Boot0001* UEFI OS HD(1,GPT,9a11...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Що це означає: Прошивка обирає запис. Якщо диски змінились або ви клонували систему, записи можуть вказувати на тепер неправільний ESP.

Рішення: Виправте BootOrder або перевстановіть GRUB/shim у ESP, яким користується прошивка.

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

cr0x@server:~$ umount /dev/vg0/root
cr0x@server:~$ fsck.ext4 -f /dev/vg0/root
e2fsck 1.47.0 (5-Feb-2023)
/dev/vg0/root: clean, 245632/61054976 files, 8123456/244121600 blocks

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

Рішення: Якщо fsck знаходить повторні проблеми, припиніть трактувати ремонт завантаження як всю інцидент; можливо, у вас проблеми з диском/контролером.

Завдання 16: Перегляньте вміст initramfs на предмет відсутніх драйверів/інструментів (досить просунуте, але вирішальне)

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.1.0-26-amd64 | grep -E 'ahci|nvme|mdadm|lvm|cryptsetup' | head
usr/sbin/cryptsetup
usr/sbin/lvm
usr/sbin/mdadm
lib/modules/6.1.0-26-amd64/kernel/drivers/md/raid1.ko
lib/modules/6.1.0-26-amd64/kernel/drivers/ata/ahci.ko

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

Рішення: Якщо модуль/інструмент відсутній, змініть конфіг генерації initramfs (dracut modules, initramfs-tools hooks) і перебудуйте.

Завдання 17: Знайдіть, який unit спричинив паніку systemd (і тактично розблокуйте завантаження)

cr0x@server:~$ systemctl --failed
  UNIT            LOAD   ACTIVE SUB    DESCRIPTION
● mnt-data.mount  loaded failed failed /data
cr0x@server:~$ systemctl status mnt-data.mount
...
mount[412]: mount: /data: can't find UUID=deadbeef-...
systemd[1]: mnt-data.mount: Failed with result 'exit-code'.

Що це означає: systemd каже вам прямо, що не вдалось і чому.

Рішення: Якщо /data некритичний — встановіть nofail,x-systemd.device-timeout=5s в fstab або тимчасово закоментуйте, щоб відновити вузол, а потім виправте сховище.

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

cr0x@server:~$ dmesg -T | tail -n 80 > /root/boot-dmesg-tail.txt
cr0x@server:~$ cat /proc/cmdline > /root/boot-cmdline.txt
cr0x@server:~$ lsblk -f > /root/boot-lsblk.txt

Що це означає: Ви зберегли докази, поки вони ще «гарячі».

Рішення: Завжди робіть це, коли ви відповідаєте на інцидент. Це скорочує наступні інциденти і робить постмортем менш вигаданим.

Жарт №2: Найнадійніший пристрій зберігання під час аварії завантаження — людська пам’ять — аж поки не почнеться інцидентний огляд.

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

Міні-історія 1: Аутейдж через хибне припущення

Середовище було флотом Linux VM на двох різних кластерах гіпервізорів. Той самий дистро, та сама автоматизація, те ж меню GRUB. Команда вважала їх взаємозамінними, бо дашборди виглядали однаково. Так оптимізм перетворюється на запит на зміни.

Під час вікна техобслуговування розгорнули оновлення ядра. Більшість машин перезавантажилися нормально. Частина флоту впала в initramfs з «unable to find root device». Перше припущення — оновлення зламало GRUB. GRUB виконав свою роботу ідеально: він завантажив нове ядро і initramfs. Ядро просто не бачило віртуальний диск-контролер.

Два кластери гіпервізорів представляли різне віртуальне апаратне забезпечення. Один використовував контролер, що вимагав модуль, який не був включений в initramfs, створений конфігом pipeline. Попередня комбінація ядро/initramfs випадково його включала. Нова — ні. Проблема була не в GRUB і навіть не в ядрі. Це був вміст initramfs.

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

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

Платформна команда хотіла швидших завантажень. Вони мали дані: «cold boot» був повільнішим за бажане, і деякі сервіси мали жорсткі бюджети рестартів. Тож вони «оптимізували» dracut, ввімкнувши режим host-only: включати лише драйвери, виявлені на цьому конкретному хості, а не загальний набір.

Це спрацювало. Завантаження стало швидшим. Всі тихо святкували, бо ніхто не любить говорити про «проєкт по зменшенню часу завантаження» вголос. Потім відбувся рутинний апгрейд обладнання: той самий модель сервера, трохи інша ревізія контролера сховища. Той самий вендор, те ж ім’я, інший PCI ID.

Після ребуту GRUB завантажив ядро; initramfs стартував; dracut не знайшов кореневий пристрій, бо драйвер контролера не був включений — host-only його виключив. Виправлення вимагало завантаження з rescue media, генерації не-host-only initramfs (або примусового включення потрібного модуля), а потім повторного розгортання. «Оптимізація» відклала ризик у майбутнє і нарахувала відсотки.

Урок не в «ніколи не оптимізувати». Він у тому, що якщо ви оптимізуєте завантаження, зменшуючи те, що включається на ранньому етапі, ви маєте поєднати це з валідацією, яка симулює апаратні зміни. Інакше ви збудуєте систему, яка завантажується тільки у вівторок і тільки при точній PCI-топології народження.

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

Інша команда запускала бази даних на зашифрованому LVM з виділеним /boot і /boot/efi. Нічого екзотичного, просто багатошарове сховище і здорова боязнь простою. Їхній pipeline завантаження мав одну дуже непривабливу політику: кожна зміна, що зачіпала артефакти завантаження (ядро, initramfs, конфіг GRUB, fstab), тригерила автоматичний «reboot-in-staging» тест на клоні.

Прийшла зміна: хтось додав нове монтування у /etc/fstab для директорії даних агента відповідності. Воно посилалося на диск за UUID, що існував на машині-білдері, а не на цільовій. Під час першого staging reboot вузол потрапив у systemd emergency mode, бо local-fs.target впав. Тест відразу це виявив.

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

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

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

Цей розділ навмисно конкретний. Узагальнена порада — заспокоює, але марна.

1) Симптом: меню GRUB з’являється, потім «Kernel panic – not syncing: VFS: Unable to mount root fs»

Корінна причина: неправильний аргумент root=, відсутній драйвер сховища в initramfs, або тип файлової системи не підтримується при завантаженні.
Вирішення: У режимі редагування GRUB приберіть quiet, підтвердіть, що root= відповідає lsblk -f. Перебудуйте initramfs, включивши контролер/модулі файлової системи. Якщо використовуєте LUKS/LVM/RAID — перевірте, що ці шари збираються в initramfs.

2) Симптом: падає в оболонку initramfs/dracut з «Warning: /dev/disk/by-uuid/… does not exist»

Корінна причина: UUID змінився (клон диска, відновлення, перепризначення розділів), або пристрій не видимий через не завантажений драйвер.
Вирішення: Використовуйте blkid/lsblk -f, щоб знайти правильний UUID. Завантажіться один раз з виправленим root= або виправте конфіг GRUB. Якщо диск зовсім не з’являється — завантажте правильний модуль і перебудуйте initramfs.

3) Симптом: режим systemd emergency; журнал каже «Failed to mount /data» і «Dependency failed for Local File Systems»

Корінна причина: запис у fstab для некореневого монтування вказує на відсутній диск, неправильний UUID або повільний пристрій без достатнього таймауту.
Вирішення: Додайте nofail і x-systemd.device-timeout= для некритичних монтувань, або видаліть/закоментуйте їх, поки сховище не відновите. Не ставте nofail для кореня.

4) Симптом: завантажується лише якщо вручну виконати `vgchange -ay` в initramfs

Корінна причина: initramfs не має хуків/інструментів для LVM, або udev не спрацював вчасно.
Вирішення: Перебудуйте initramfs з примусовою підтримкою LVM. Переконайтесь, що потрібні пакети і модулі dracut/initramfs-tools встановлені.

5) Симптом: завантажується лише якщо вручну виконати `mdadm --assemble --scan`

Корінна причина: конфіг mdadm не включений в initramfs або масиви визначені так, що ранній завантажувальний етап не може їх зібрати автоматично.
Вирішення: Переконайтесь що mdadm.conf правильний, включіть його в initramfs, перебудуйте initramfs. Розгляньте використання метаданих/layout, відомих своєю передбачуваністю складання.

6) Симптом: чорний екран після вибору ядра; немає видимих логів

Корінна причина: проблема з режимом графіки, quiet boot ховає єдині підказки, або ядро миттєво перезавантажується.
Вирішення: Приберіть quiet splash, додайте nomodeset для одного завантаження, або додайте параметри серійної консолі, якщо є віддалене управління. Якщо воно все ще перезавантажується — використайте live media, щоб перевірити цілісність /boot та initramfs.

7) Симптом: «Switch root failed» або dracut «failed to mount /sysroot»

Корінна причина: initramfs не зміг змонтувати реальний root у шляху, який очікувався; root-пристрій не готовий, неправильний тип fs або відсутній модуль.
Вирішення: Перевірте root=, виконайте blkid, спробуйте ручне mount кореня для читання. Перебудуйте initramfs і впевніться, що він містить потрібні модулі.

8) Симптом: завантажується старе ядро, але не нове

Корінна причина: новий initramfs не містить драйверів або хуків; змінилося налаштування ядра; microcode або підпис Secure Boot не співпадають у деяких налаштуваннях.
Вирішення: Завантажтесь зі старим ядром, порівняйте вміст initramfs, регенеруйте initramfs для нового ядра і знову згенеруйте конфіг GRUB.

Контрольні списки / покроковий план

Контрольний список A: на консолі триаж (ще без live media)

У GRUB відредагуйте запис: приберіть quiet splash. Завантажте і дивіться, де падає.
Якщо ви отримали оболонку initramfs: виконайте cat /proc/cmdline, потім lsblk -f.
Спробуйте ручні кроки зі збирання в залежності від стеку:
- LUKS: cryptsetup luksOpen
- RAID: mdadm --assemble --scan
- LVM: vgchange -ay
Спробуйте змонтувати корінь лише для читання в /mnt/root.
Якщо root монтований: ймовірно у вас проблема користувацького простору або конфігурації. Якщо ні: драйвер або файлова система.

Контрольний список B: відновлення з live media (швидкий шлях до постійних виправлень)

Завантажте live media. Підтвердьте, що диски видимі: lsblk -f.
Якщо зашифровано — відкрийте LUKS. Якщо RAID — зберіть масиви. Якщо LVM — активуйте VG.
Змонтуйте корінь в /mnt, потім змонтуйте /boot і /boot/efi відповідно.
Bind-монтуйте /dev, /proc, /sys; потім chroot.
Всередині chroot:
- Виправте /etc/fstab UUID та опції.
- Перегенеруйте initramfs для уражених ядер.
- Перегенеруйте конфіг GRUB; перевстановіть GRUB за потреби.
Перезавантажтесь. Якщо знову не вдалось — тепер у вас кращі докази і постійні логи.

Контрольний список C: правила «не роби гірше»

Монтайте підозрілі файлові системи у режимі лише для читання, поки не з’ясуєте, що сталося.
Не запускайте ремонт файлової системи на неправильному пристрої. Підтвердіть через lsblk -f спочатку.
Не змінюйте розділення, коли ви втомлені. Якщо мусите — зробіть знімок/образ спочатку.
Не «виправляйте» розбіжності UUID випадковими правками у трьох різних місцях. Вирішіть, де правда — диск або конфіг, і вирівняйте все одноразово.
Зберігайте докази: збережіть /proc/cmdline, dmesg та витяги з journalctl перед великими правками.

FAQ

1) Якщо GRUB показує меню, чи означає це, що мій диск в порядку?

Ні. Це означає, що прошивка може завантажити GRUB і GRUB може прочитати достатньо для завантаження конфігурації. Ваше ядро все ще може не мати драйвера для доступу до кореневого диска, або ідентифікатор root може бути неправильний.

2) Який найшвидший спосіб отримати корисний вивід завантаження?

Відредагуйте запис GRUB і приберіть quiet splash. Якщо все ще занадто швидко, додайте systemd.unit=emergency.target або використайте серійну консоль, якщо середовище її підтримує.

3) Чому моя система впала в initramfs після, здавалося б, нешкідливої зміни?

Тому що «нешкідливо» часто означає «я не чіпав /boot», а не «я не змінив критичну ідентичність завантаження». Клони дисків, зміни UUID, дрейф конфіг mdadm/LVM і відсутні модулі initramfs — часті тригери.

4) Чи варто виправляти проблеми з root-пристроєм, використовуючи /dev/sda2 замість UUID?

Тільки для тимчасового тесту завантаження. Постійна конфігурація має використовувати UUID/PARTUUID або стабільні шляхи mapper. Імена пристроїв можуть змінюватись між перезавантаженнями і апаратурою.

5) Коли доречно додати `nofail` до /etc/fstab?

Для некритичних монтувань (наприклад, опціональних дисків даних), де доступність важливіша за обов’язкове монтування. Ніколи не ставте nofail для кореня; це дорога в нікуди.

6) Я можу вручну змонтувати корінь в initramfs. Чому воно не завантажується автоматично?

Зазвичай це вказує на те, що логіка initramfs не зібрала стек автоматично (відсутні хуки для LVM/mdadm/cryptsetup) або неправильні аргументи ядра. Перебудуйте initramfs і перевірте, що потрібні інструменти/модулі в ньому присутні.

7) Чому завантаження працює з старим ядром, але не з новим?

Часто тому, що initramfs для нового ядра неповний або не відповідає: відсутні модулі, відсутня конфігурація, або згенерований з іншими параметрами (наприклад, host-only). Порівняйте вміст initramfs і перебудуйте.

8) Що робити, якщо підозрюю проблему з прошивкою/UEFI записами?

Використайте efibootmgr -v, щоб підтвердити, що прошивка насправді завантажує. Клони дисків і декілька ESP часто залишають NVRAM записи, які вказують на неправильний лоадер.

9) Чи може Secure Boot спричиняти «GRUB працює, а Linux не завантажується»?

Так. Можна завантажити shim/GRUB, але зазнати провалу далі, якщо підписи ядра/initramfs або модулів не відповідають політиці. Симптоми залежать від дистро й конфігурації; найсильніша підказка — повідомлення після видалення quiet.

10) Чи варто перевстановлювати GRUB як перший крок?

Ні. Якщо GRUB завантажується і запускає ядро, зазвичай ваш час краще витратити на ідентифікацію кореня, вміст initramfs і логи systemd. Перевстановлюйте GRUB, коли є докази, що запис прошивки або конфіг GRUB неправильні.

Практичні наступні кроки

Якщо ви тримаєте інцидентний тикет, зробіть це:

Класифікуйте стадію відмови: kernel panic vs initramfs shell vs systemd emergency.
Зберіть докази (/proc/cmdline, lsblk -f, dmesg, journalctl -xb) перед правками.
Перевірте ідентичність кореня і зберіть стек сховища (LUKS → mdadm → LVM → mount). Доведіть, чого саме бракує.
Зробіть зворотну одноразову зміну в GRUB, щоб підтвердити напрямок виправлення.
Виконайте постійний ремонт з chroot: виправте fstab, перебудуйте initramfs, регенеруйте конфіг GRUB, перевірте UEFI записи.

Якщо ви запобігаєте наступному інциденту, зробіть це:

Додайте тест перезавантаження в staging для будь-якої зміни, що зачіпає ядро, initramfs, конфіг GRUB, шари сховища або fstab.
Стандартизуйте типи віртуального апаратного забезпечення і документуйте критичні залежності сховища.
Майте принаймні один відомо-робочий запис завантаження і уникайте «прибирання», яке видаляє останнє робоче ядро під час релізу.
Запишіть точні кроки відновлення, які використовувала ваша команда, з деталями вашого стеку сховища. Майбутній ви не пам’ятатиме о 03:17.

«GRUB працює» — це не перемога; це лише вступ. Система завантажується тоді, коли ядро бачить сховище, initramfs може його зібрати, і systemd може змонтувати без спотиканняся об вашу конфігурацію. Ставтесь до цього як до розслідування. Збирайте факти. Робіть маленькі, зворотні кроки. І перестаньте перевстановлювати GRUB з рефлексу.