Ubuntu 24.04: Оновлення системи зламали модулі — правильно відтворіть initramfs (Випадок №88)

January 28, 2026 • February 3, 2026 • Читання: 7 хв • Views: 8

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

Ви поставили патчі Ubuntu, перезавантажилися як відповідальна людина — і машина відповіла запрошенням initramfs, відсутніми мережевими адаптерами або тим, що коренева файлова система раптом «не існує».
Ласкаво просимо до випадку №88: оновлення не «зламало Linux». Воно порушило контракт між вашим ядром, його модулями та initramfs, який має їх об’єднати під час завантаження.

Виправлення зазвичай нудне: правильно відтворити initramfs для ядра, яке ви фактично завантажуєте, з модулями, які вам потрібні, і не ігнорувати реальний стан Secure Boot, DKMS або ZFS.
Трюк — робити це з достатньою дисципліною, щоб воно залишалося виправленим після наступного оновлення.

Що насправді зламалося: ланцюжок завантаження та контракт модулів

В Ubuntu 24.04 класична історія з initramfs усе ще актуальна: GRUB завантажує ядро (vmlinuz) і образ initramfs (initrd.img).
Initramfs — невелика коренева файлова система в оперативній пам’яті, що містить ранній userspace, скрипти та підмножину модулів ядра, необхідних для знаходження й монтування справжньої кореневої файлової системи.

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

Ви завантажуєте інше ядро, ніж думаєте (за замовчуванням GRUB змінився, старе ядро видалене або вибрано пункт відкату).
Ваш initramfs не відповідає ядру (невірна версія, застарілий образ, невдала регенерація).
Модулі є на диску, але не включені в initramfs (пошкоджені хуки, помилкова конфігурація, відсутні метадані залежностей).
DKMS не зібрав модулі (відсутні заголовки, невідповідність компілятора, помилка підписування при Secure Boot).
Secure Boot блокує непідписані модулі (NVIDIA, ZFS DKMS, сторонні драйвери).
Зміни у стеку зберігання (новий initramfs не містить LUKS, LVM, RAID, NVMe, HBA-модулів або компонентів ZFS).

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

Цікаві факти та контекст (бо історія повторюється о 3:00)

initramfs замінив initrd здебільшого тому, що стислий cpio-архів більш гнучкий, ніж образ ramdisk фіксованого розміру.
Стандартний інструментарій Ubuntu — initramfs-tools з update-initramfs, тоді як інші дистрибутиви покладаються на dracut; мускульна пам’ять може нашкодити.
«Ранній userspace» став поширеним, коли стек зберігання ускладнився: LVM-on-LUKS-on-MDRAID — це не те, що хочеться жорстко вшивати в ядро.
DKMS існує, бо сторонні модулі — реальність: вендорські NIC, NVIDIA та спеціальні файлові системи продовжують з’являтися у реальних парках серверів.
Secure Boot зробив завантаження модулів політичним: ядро може бути коректним, але відмовити вашому модулю через підписи.
ZFS на корені — прекрасне допоки не зламається: якщо initramfs не містить компонентів ZFS, корінь не змонтується за будь‑якої коректності пулу.
GRUB може завантажити «нормально», а ОС буде зламаною: передача відбувається, а потім initramfs не знаходить корінь; люди все одно звинувачують GRUB.
Зміни ABI ядра — навмисні: пакети ядра Ubuntu змінюють uname -r, і будь‑які сторонні модулі мають точно відповідати.

Одна перефразована думка від W. Edwards Deming: Якість виникає від покращення процесу, а не від перевірки помилок після їхнього виникнення.
Робота з надійністю — це переважно побудова процесів, які не створюють зламані образи initramfs спочатку.

Швидкий план діагностики

Коли перезавантаження пішло не так після оновлень, час має значення. Це найкоротша дорога до істини.
Перевіряйте ці пункти по порядку; зупиняйтеся, щойно знайдете невідповідність.

Спочатку: Ви завантажуєте ядро, яке думаєте?

Якщо можете зайти в систему: порівняйте uname -r з тим, що ви вважаєте встановленим.
Якщо не можете: використайте GRUB «Advanced options», щоб завантажити попереднє ядро і отримати shell.

По‑друге: Чи існує initramfs і чи відповідає воно цьому ядру?

Перевірте наявність /boot/initrd.img-$(uname -r) і чи воно актуальне.
Проінспектуйте, чи присутні всередині образу потрібні модулі (зберігання + крипто + платформні драйвери).

По‑третє: Чи не зазнали збою збірки модулів (DKMS / заголовки / Secure Boot)?

Перегляньте dkms status і стан пакетів.
Перевірте journalctl -b -0 на предмет помилок підписування модулів і невдач при завантаженні модулів.

По‑четверте: Чи не відмовляється виявлення кореневого пристрою?

«Gave up waiting for root device» означає відсутні драйвери або невірні UUID.
Перевірте UUID у /etc/fstab, crypttab і командному рядку GRUB.

Жарт №1 (короткий, доречний): initramfs — як аварійний набір: помічаєш, що зникло, тільки коли вже холодно й дратуєшся.

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

Ці завдання призначені для систем Ubuntu 24.04 з initramfs-tools (за замовчуванням).
Кожне завдання містить: команду, реалістичний вивід, що це означає, та рішення, яке ви приймаєте.
Виконуйте їх із робочого завантаження (можливо старішого ядра), у рятувальному shell або з live ISO з підключеними розділами кореня.

Завдання 1 — Підтвердіть запущене ядро і чи це режим відкату

cr0x@server:~$ uname -r
6.8.0-41-generic

Значення: Активне ядро — 6.8.0-41-generic. Усе, що ви відлагоджуєте, має відповідати цій версії.
Рішення: Використовуйте цей рядок точно при перевірці директорій модулів і образів initramfs. Ніяких здогадок, ніякої «майже того».

Завдання 2 — Перелічіть встановлені ядра (і знайдіть напіввидалені пакети)

cr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii|^rc/ {print $1, $2, $3}' | head -n 12
ii linux-image-6.8.0-40-generic 6.8.0-40.40
ii linux-image-6.8.0-41-generic 6.8.0-41.41
ii linux-image-generic-hwe-24.04 6.8.0-41.41
rc linux-image-6.8.0-39-generic 6.8.0-39.39

Значення: У вас кілька ядер, і одне перебуває в стані «rc» (видалено, лишилася конфігурація).
Рішення: Якщо бракує відомого працездатного попереднього ядра — перевстановіть його. Тримайте щонайменше одне запасне ядро, поки система не доведе стабільність.

Завдання 3 — Перевірте, чи існує initramfs для запущеного ядра

cr0x@server:~$ ls -lh /boot/initrd.img-$(uname -r)
-rw-r--r-- 1 root root 114M Dec 31 09:12 /boot/initrd.img-6.8.0-41-generic

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

Завдання 4 — Перевірте наявність директорії модулів для цього ядра

cr0x@server:~$ ls -ld /lib/modules/$(uname -r)
drwxr-xr-x 7 root root 4096 Dec 31 09:10 /lib/modules/6.8.0-41-generic

Значення: Модулі для запущеного ядра існують на диску.
Рішення: Якщо директорії немає — установка ядра неповна (або ви завантажили ядро без модулів). Виправте пакети спочатку.

Завдання 5 — Підтвердіть наявність метаданих залежностей модулів (depmod)

cr0x@server:~$ ls -1 /lib/modules/$(uname -r)/modules.dep /lib/modules/$(uname -r)/modules.alias
/lib/modules/6.8.0-41-generic/modules.alias
/lib/modules/6.8.0-41-generic/modules.dep

Значення: depmod створив карти залежностей.
Рішення: Якщо вони відсутні або пусті — запустіть depmod -a і перебудуйте initramfs. initramfs-tools покладається на ці метадані, щоб підключити драйвери.

Завдання 6 — Визначте тип кореневого пристрою (NVMe/SATA/LVM/LUKS/ZFS)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE /
/dev/mapper/cryptroot / ext4

Значення: Корінь знаходиться на dm-crypt мапі з іменем cryptroot.
Рішення: Initramfs має включати dm-crypt і відповідний нижчий драйвер зберігання (NVMe, AHCI, RAID тощо). Якщо завантаження падає — підозрюйте відсутні модулі крипто/зберігання або застарілий crypttab.

Завдання 7 — Перевірте, чи узгоджені UUID в crypttab та fstab

cr0x@server:~$ sudo grep -v '^\s*#' /etc/crypttab
cryptroot UUID=3b5a2d2c-9f1a-4c3b-bfb6-9f8c7e4a1f0e none luks,discard

cr0x@server:~$ sudo blkid | grep 3b5a2d2c-9f1a-4c3b-bfb6-9f8c7e4a1f0e
/dev/nvme0n1p3: UUID="3b5a2d2c-9f1a-4c3b-bfb6-9f8c7e4a1f0e" TYPE="crypto_LUKS" PARTUUID="b6a0..."

Значення: crypttab вказує на реальний UUID пристрою.
Рішення: Якщо UUID не співпадає, initramfs буде чекати вічно на пристрій, якого немає. Виправте crypttab/fstab, потім перебудуйте initramfs.

Завдання 8 — Перегляньте потрібні модулі всередині образу initramfs

cr0x@server:~$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'cryptsetup|dm-crypt|nvme|ahci|zfs' | head
usr/sbin/cryptsetup
lib/modules/6.8.0-41-generic/kernel/drivers/md/dm-crypt.ko.zst
lib/modules/6.8.0-41-generic/kernel/drivers/nvme/host/nvme.ko.zst

Значення: initramfs містить cryptsetup та модулі dm-crypt і NVMe.
Рішення: Якщо критичний модуль відсутній — виправте конфігурацію initramfs-tools або хуки, і потім перебудуйте.

Завдання 9 — Перевірте, чи відбуваються помилки при перебудові initramfs (дивіться логи)

cr0x@server:~$ sudo journalctl -u systemd-update-utmp -b -0 | tail -n 5
Dec 31 09:12:24 server systemd[1]: Starting Update UTMP about System Boot/Shutdown...
Dec 31 09:12:24 server systemd[1]: Finished Update UTMP about System Boot/Shutdown.

cr0x@server:~$ sudo grep -R "update-initramfs" -n /var/log/apt/term.log | tail -n 6
2025-12-31 09:11:57 update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
2025-12-31 09:12:03 cryptsetup: WARNING: Resume target cryptswap uses a key file

Значення: initramfs був згенерований під час оновлення; є попередження, але явних фатальних помилок тут не видно.
Рішення: Якщо бачите «failed» або «cannot find module», вважайте це фатальною зупинкою: виправте основну проблему і згенеруйте знову.

Завдання 10 — Перевірте стан DKMS для сторонніх модулів

cr0x@server:~$ dkms status
nvidia/550.90.07, 6.8.0-41-generic, x86_64: installed
zfs/2.2.2, 6.8.0-41-generic, x86_64: built

Значення: NVIDIA встановлено для цього ядра; ZFS зібрано (не обов’язково встановлено).
Рішення: Будь‑що, що не «installed» для вашого ядра — ймовірна причина того, що модулі не завантажуються. Пересоберіть DKMS модулі і знову згенеруйте initramfs.

Завдання 11 — Підтвердіть стан Secure Boot (і передбачте помилки підписування)

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Значення: Secure Boot увімкнено; непідписані сторонні модулі можуть не завантажуватися.
Рішення: Якщо завантаження модуля падає через помилки підпису, або зареєструйте MOK і підпишіть модулі, або вимкніть Secure Boot. Оберіть одне; не робіть вигляд, що проблема зникне сама.

Завдання 12 — Виявлення помилок завантаження модулів у поточному завантаженні

cr0x@server:~$ sudo journalctl -k -b -0 | grep -E "module verification failed|Unknown symbol|taint|Lockdown" | tail -n 8
Dec 31 09:13:01 server kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
Dec 31 09:13:01 server kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel

Значення: Ядро в режимі lockdown; непідписані модулі можуть бути заблоковані або «плямувати» ядро залежно від політики.
Рішення: Якщо модуль блокується (не лише плямує), виправлення — підпис/реєстрація ключів або відключення Secure Boot. Одна лише перебудова initramfs тут не допоможе.

Завдання 13 — Переконайтеся, що ви випадково не змінили генератор initramfs

cr0x@server:~$ dpkg -l | awk '/initramfs-tools|dracut/ {print $1, $2, $3}'
ii initramfs-tools 0.142ubuntu25.2

Значення: Ви використовуєте initramfs-tools. Добре: дотримуйтеся одного інструменту, якщо у вас немає політики міграції.
Рішення: Якщо dracut встановлено і бере на себе роботу — з’ясуйте, який інструмент оновлює ваш initrd, і стандартизуйте. Змішані інструменти — повільна аварія.

Завдання 14 — Перевірте артефакти завантаження і симлінки в /boot

cr0x@server:~$ ls -l /boot | grep -E 'vmlinuz|initrd|System.map' | head -n 10
lrwxrwxrwx 1 root root      27 Dec 31 09:12 initrd.img -> initrd.img-6.8.0-41-generic
-rw-r--r-- 1 root root 119458690 Dec 31 09:12 initrd.img-6.8.0-41-generic
lrwxrwxrwx 1 root root      24 Dec 31 09:12 vmlinuz -> vmlinuz-6.8.0-41-generic
-rw-r--r-- 1 root root  14901248 Dec 31 09:12 vmlinuz-6.8.0-41-generic

Значення: Симлінки вказують на найновіше ядро. Це нормально для Ubuntu.
Рішення: Якщо вони вказують на ядро, яке не має модулів або має зламаний initramfs — зафіксуйте GRUB на відомому працездатному ядрі, поки ви лагодите нове.

Правильне відтворення initramfs (і доказ, що воно спрацювало)

Мета — не «запустити update-initramfs і сподіватися». Мета — створити детерміністичний initramfs для конкретної версії ядра,
що містить потрібні модулі, з актуальними метаданими залежностей модулів і з оновленими конфігами завантажувача.

Крок 0 — Виберіть версію ядра, яку будете лагодити

Вирішіть явним чином цільову версію ядра. Зазвичай це найновіше встановлене ядро, яке ви хочете завантажувати.
У подальших прикладах припустимо KVER=6.8.0-41-generic.

Завдання 15 — Переконайтеся, що образ ядра і заголовки встановлені

cr0x@server:~$ KVER=6.8.0-41-generic
cr0x@server:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y linux-image-$KVER linux-headers-$KVER
Reading package lists... Done
Building dependency tree... Done
linux-image-6.8.0-41-generic is already the newest version (6.8.0-41.41).
linux-headers-6.8.0-41-generic is already the newest version (6.8.0-41.41).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Значення: Ядро і заголовки присутні. DKMS має шанс зібратися.
Рішення: Якщо заголовки відсутні — встановіть їх перед тим, як чіпати DKMS або initramfs. Інакше ви перебудуєте initramfs, яке ніколи не зможе містити потрібні модулі.

Завдання 16 — Пересоберіть DKMS модулі (якщо ви їх використовуєте)

cr0x@server:~$ sudo dkms autoinstall -k $KVER
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
Building module:
Cleaning build area...
Building module(s)... done.
Installing /lib/modules/6.8.0-41-generic/updates/dkms/nvidia.ko.zst
depmod...

Значення: DKMS пересобрав і встановив модуль для цього ядра, потім запустив depmod.
Рішення: Якщо DKMS повідомляє помилки — не перебудовуйте initramfs поки не виправите DKMS (заголовки, компілятор, підписування Secure Boot), далі продовжуйте.

Завдання 17 — Явно оновіть метадані залежностей модулів

cr0x@server:~$ sudo depmod -a $KVER

Значення: Карти залежностей модулів регенеровано для цільового ядра.
Рішення: Якщо depmod видає помилки про відсутні файли — ваша дерево модулів непослідовне. Усуньте це перед генерацією initramfs, яке успадкує неконсистентність.

Завдання 18 — Перебудуйте initramfs саме для одного ядра (с sensible default)

cr0x@server:~$ sudo update-initramfs -u -k $KVER
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
W: Possible missing firmware /lib/firmware/i915/rlc.bin for module i915

Значення: initramfs перебудовано для цільового ядра. Попередження про прошивку може або не вплинути на шлях завантаження.
Рішення: Якщо видно «failed» або повернуто код помилки — зупиніться і виправте. Якщо завершилося з попередженнями — вирішіть, чи вони зачіпають критичне обладнання для завантаження.

Завдання 19 — Проінспектуйте вміст initramfs, щоб підтвердити виправлення

cr0x@server:~$ lsinitramfs /boot/initrd.img-$KVER | grep -E 'dm-crypt.ko|nvme.ko|mlx|bnx2|zfs.ko' | head -n 20
lib/modules/6.8.0-41-generic/kernel/drivers/md/dm-crypt.ko.zst
lib/modules/6.8.0-41-generic/kernel/drivers/nvme/host/nvme.ko.zst

Значення: Критичні модулі зберігання/крипто присутні.
Рішення: Якщо потрібного модуля немає — додайте його (див. наступні кроки), замість того щоб повторювати регенерацію як ігровий автомат.

Завдання 20 — Примусове включення модуля (коли автодетекція не спрацьовує)

initramfs-tools зазвичай робить це правильно. Іноді ні — особливо на незвичних контролерах зберігання, багаторівневому шарі зберігання або коли хуки ламаються.
Ви можете примусово додати модулі через /etc/initramfs-tools/modules.

cr0x@server:~$ echo -e "nvme\ndm-crypt\n" | sudo tee -a /etc/initramfs-tools/modules
nvme
dm-crypt

cr0x@server:~$ sudo update-initramfs -u -k $KVER
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

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

Завдання 21 — Переконайтеся, що конфігурація завантажувача знає про ядро

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
done

Значення: GRUB виявив пару ядро/initrd.
Рішення: Якщо GRUB не перераховує очікуване ядро/initrd — виправте монтування /boot, інсталяцію пакетів або проблеми з місцем на файлі системи перед перезавантаженням.

Завдання 22 — Переконайтеся, що /boot не заповнений (мовчазні помилки initramfs це люблять)

cr0x@server:~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  975M  912M   11M  99% /boot

Значення: /boot на 99%. Це небезпечна зона; регенерація може провалитися або обрізатися.
Рішення: Безпечно видаліть старі ядра (apt-get autoremove --purge) і збережіть щонайменше одне запасне ядро. Потім знову перебудуйте initramfs.

Завдання 23 — Безпечне видалення старих ядер (звільнення місця без самопсування)

cr0x@server:~$ sudo apt-get autoremove --purge
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  linux-image-6.8.0-40-generic* linux-modules-6.8.0-40-generic*
After this operation, 412 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 214233 files and directories currently installed.)
Removing linux-image-6.8.0-40-generic (6.8.0-40.40) ...
Processing triggers for initramfs-tools (0.142ubuntu25.2) ...
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
Processing triggers for grub-pc (2.12-1ubuntu7) ...

Значення: Старе ядро видалено; initramfs згенеровано; GRUB оновлено.
Рішення: Переконайтеся, що у вас ще є як мінімум одне старіше ядро для відкату. Потім приступайте до тестового перезавантаження.

Завдання 24 — Перезавантажте для тесту (і тримайте консоль відкритою)

cr0x@server:~$ sudo reboot

Значення: Ви тестуєте відновлений шлях завантаження.
Рішення: Якщо машина віддалена — використовуйте OOB консоль (IPMI/iDRAC/virt console). Перезавантаження без консолі — джерело листів‑вибачень.

Жарт №2 (короткий, доречний): Secure Boot чудовий, аж доки ви о 2:00 намагаєтеся завантажити модуль, і він починає вимагати «папери».

Три корпоративні міні-історії з польових робіт

Міні-історія 1: Інцидент, спричинений хибним припущенням

Середня компанія експлуатувала флоти Ubuntu на bare metal з зашифрованими кореневими дисками. Режим патчування був акуратний: stage, test, roll out.
Але одного п’ятниці розгортання все ж пішло в прод — бо передпродакшн кластер «виглядав нормально».

В понеділок частина продакшну не повернулася після рутинного перезавантаження. Системи опинилися в initramfs з «cannot find /dev/mapper/cryptroot».
На виклику підозрювали масив дисків. Сторедж оглядали. Усі дивилися на iostat як на ворожіння.

Насправді причина була буденною: initramfs, згенерований під час оновлення, не включив певного модуля контролера зберігання, потрібного для виявлення NVMe дисків.
Хибне припущення було в тому, що «cryptsetup падає — значить крипто». Але крипто-шар був ні при чому; він чекав на диск, якого не було видно.

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

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

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

Це працювало — доки не вийшло наступне оновлення ядра. Одна ревізія ядра змінила, який модуль надає певну функцію зберігання.
Генерація initramfs все ще «успішно» відбувалась, але тепер бракувало правильного імені модуля для нової упаковки ядра.

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

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

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

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

Оскільки політика вимагала збирання стану DKMS і вмісту initramfs, вони виявили помилку в стейджингу до продакшну.
Вони зафіксували версію пакета, пересобрали DKMS з потрібними заголовками і запланували вікно обслуговування зі збереженим для відкату ядром.

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

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

1) Падіння в initramfs з повідомленням «Gave up waiting for root filesystem device»

Симптом: Завантаження опускається в initramfs prompt; кореневий UUID не знайдено.
Корінна причина: В initramfs відсутній драйвер контролера зберігання або невірний UUID у fstab/crypttab.
Виправлення: Перевірте UUID за допомогою blkid. Інспектуйте initrd за допомогою lsinitramfs. Примусово додайте модуль у /etc/initramfs-tools/modules. Перебудуйте з update-initramfs -u -k KVER.

2) Мережа зникає після перезавантаження (відсутній драйвер NIC)

Симптом: Хост завантажується, але інтерфейси, окрім loopback, відсутні; ip link не показує корисного.
Корінна причина: Сторонній NIC-драйвер (DKMS) не зібрався для нового ядра; initramfs також може не містити прошивки.
Виправлення: Перевірте dkms status. Встановіть заголовки. Виконайте dkms autoinstall -k KVER. Підтвердіть завантаження модуля через modprobe і журнали ядра, потім перебудуйте initramfs.

3) NVIDIA драйвер «вчора працював, сьогодні чорний екран»

Симптом: GUI падає, дисплейний менеджер циклічно перезапускається, в журналах ядра — помилки модуля nvidia.
Корінна причина: Невідповідність DKMS модуля або примусове застосування політик Secure Boot.
Виправлення: Перевірте Secure Boot за допомогою mokutil --sb-state. Пересоберіть DKMS. Якщо Secure Boot увімкнено — зареєструйте/підпишіть модулі або вимкніть його. Потім перебудуйте initramfs і перезавантажтеся.

4) «Unknown symbol» при завантаженні модуля

Симптом: Вставлення модуля не вдається; dmesg показує unknown symbols.
Корінна причина: Модуль зібрано проти інших заголовків ядра, ніж запущене ядро (несумісність ABI).
Виправлення: Переконайтеся, що linux-headers-KVER збігаються. Пересоберіть DKMS саме для цього ядра, виконайте depmod -a KVER, регенеруйте initramfs.

5) Перебудова initramfs «успішна», але завантаження все ще падає

Симптом: Ви запустили update-initramfs; нічого не змінилося; завантаження все одно падає.
Корінна причина: Ви перебудували для неправильної версії ядра або GRUB завантажує інший запис.
Виправлення: Підтвердіть uname -r для ядра, яке ви завантажили успішно, інспектуйте симлінки в /boot, виконайте update-grub і встановіть GRUB за замовчуванням на відомо‑робоче ядро, поки лагодите нове.

6) «Недостатньо місця на /boot» призводить до частково записаного initrd

Симптом: initrd існує, але надзвичайно мале; логи регенерації показують проблеми з простором.
Корінна причина: Розділ /boot майже повний; старі ядра не очищуються.
Виправлення: Видаліть старі ядра через apt-get autoremove --purge (залиште fallback). Перебудуйте initramfs і оновіть GRUB.

7) ZFS root не імпортується при завантаженні

Симптом: Завантаження опускається в initramfs; пул не знайдено/імпорт не вдається.
Корінна причина: Модуль ZFS не присутній в initramfs, збірка DKMS не інстальована або невідповідність між ядром і модулем ZFS.
Виправлення: Перевірте стан ZFS DKMS, переконайтеся, що модуль ZFS присутній у initrd (lsinitramfs), пересоберіть DKMS і перебудуйте initramfs для цільового ядра.

Чек-листи / покроковий план

Чек‑лист A — Якщо система ще завантажується (найкращий варіант)

Підтвердіть запущене ядро: uname -r.
Перевірте встановлені ядра і виявте зламані пакети: dpkg -l 'linux-image-*'.
Перегляньте місце в /boot: df -h /boot. Якщо >90% — спочатку почистіть.
Переконайтеся, що в модулі для цільового ядра є: ls /lib/modules/KVER.
Перевірте DKMS: dkms status. Виправте все, що не «installed».
Запустіть depmod -a KVER.
Перебудуйте initramfs: update-initramfs -u -k KVER.
Перевірте наявність модулів всередині initrd: lsinitramfs і grep для ваших драйверів.
Оновіть GRUB: update-grub.
Перезавантажтеся з доступом до консолі і перевірте журнали після завантаження.

Чек‑лист B — Якщо система не завантажується (режим реального інциденту)

Спробуйте через GRUB «Advanced options» завантажити старіше ядро (якщо воно є).
Якщо нічого не завантажується: використайте live ISO, змонтуйте root та boot розділи, потім chroot.
Всередині chroot: переконайтеся, що /boot змонтовано і доступне для запису.
Перевстановіть образ ядра та заголовки для цільової версії.
Виправте помилки DKMS, особливо для модулів зберігання/мереж і ZFS.
Перебудуйте initramfs для цільового ядра.
Запустіть update-grub і підтвердіть, що воно бачить пару ядро/initrd.
Перезавантажте і валідуйте.

Завдання 25 — Робочий процес відновлення через chroot (коли потрібно ремонтувати з live ISO)

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ sudo mount /dev/mapper/cryptroot /mnt
cr0x@server:~$ for d in /dev /proc /sys /run; do sudo mount --bind $d /mnt$d; done
cr0x@server:~$ sudo chroot /mnt /bin/bash

cr0x@server:/# update-initramfs -u -k 6.8.0-41-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

cr0x@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
done

Значення: Ви перебудували артефакти завантаження в контексті встановленої ОС, а не live-середовища.
Рішення: Якщо update-grub не знаходить ваше ядро — /boot може бути неправильно змонтовано або пакети відсутні. Виправте це перед перезавантаженням.

Питання й відповіді

1) Використовувати `update-initramfs` чи `mkinitramfs`?

Використовуйте update-initramfs для рутинних операцій. Воно керує стандартними шляхами і працює з тригерами пакетів.
Використовуйте mkinitramfs, коли хочете згенерувати конкретний файл вручну для тестування, але не робіть це звичкою.

2) Я перебудував initramfs, але воно все одно завантажує старе ядро. Чому?

Бо GRUB завантажує те, що в нього налаштовано. Запустіть update-grub, перевірте симлінки в /boot і підтвердіть стандартний пункт меню.
Також переконайтеся, що ви не перебудували initramfs для ядра, яке ви не обираєте.

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

Вам потрібні всі компоненти, необхідні для виявлення й монтування кореня: контролер дисків (NVMe/AHCI/HBA), RAID/LVM/dm-crypt, драйвер файлової системи і все інше, що потрібно для шляху до кореня.
Ви можете підтвердити це, інспектуючи initrd за допомогою lsinitramfs і виконуючи grep за потрібними модулями.

4) Чи безпечно примусово додавати модулі в `/etc/initramfs-tools/modules`?

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

5) Навіщо Secure Boot, якщо модуль присутній в initramfs?

Присутність в initramfs не гарантує, що модуль буде завантажено. Політика Secure Boot може відмовити непідписаним модулям під час завантаження.
Якщо в журналах ядра ви бачите повідомлення про підписи/lockdown — вирішуйте питання підписування/реєстрації ключів або вимикайте Secure Boot.

6) DKMS каже «built», але не «installed». У чому різниця?

«Built» означає, що компіляція пройшла успішно. «Installed» означає, що модуль скопійовано в дерево модулів ядра (зазвичай під /lib/modules/KVER/updates) і запущено depmod.
Вам потрібно «installed», щоб модуль надійно завантажувався і потрапляв у initramfs, коли це релевантно.

7) Мій /boot маленький. Чи просто його розширити?

Якщо можете — так. Сучасні ядра й initramfs не малі. Але в багатьох середовищах зміна розміру розділів — це бюрократія.
Операційно тримайте одне fallback-ядро, регулярно обрізайте старі і налаштуйте алерти на використання /boot.

8) Чи можна перебудувати initramfs для всіх ядер одразу?

Можна: update-initramfs -u -k all. Це корисно після широких змін (наприклад, додано потрібний модуль).
Але в режимі інциденту спочатку ціліть одне ядро, щоб розуміти, що змінилося.

9) Якщо з’явився prompt initramfs і я хочу діагностувати на місці — що робити?

У shell initramfs перевірте, які блочні пристрої існують, підтвердіть, чи видно кореневий UUID, і спробуйте завантажити модулі через modprobe.
Якщо завантаження потрібного драйвера робить кореневий пристрій видимим — ви довели корінну причину: відсутній модуль в initramfs.

10) Чи вирішить проблему перевстановлення пакета ядра?

Часто — так, бо це відновлює дерево модулів і запускає регенерацію initramfs.
Але якщо реальна проблема — DKMS + Secure Boot, перевстановлення ядра просто дасть нову стадію для тієї ж помилки.

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

Якщо ви в середині простою: завантажте відоме працездатне ядро, підтвердіть вирівнювання версій ядра/initramfs/модулів, виправте DKMS і реалії Secure Boot, потім перебудуйте initramfs для ядра, яке хочете.
Підтвердіть виправлення, інспектуючи вміст initramfs і переконайтесь, що GRUB бачить правильну пару.

Потім виконайте нудну роботу:

Тримайте щонайменше одне fallback-ядро встановленим, поки нове ядро не витримає реальні перезавантаження.
Моніторьте використання /boot і очищуйте старі ядра за графіком, а не коли воно досягне 99%.
У стейджингу валідуйте шлях завантаження, перевіряючи, що initramfs містить критичні для кореня модулі (зберігання/крипто/ZFS/NIC за потреби).
Якщо використовуєте DKMS модулі — ставте стан «DKMS installed for KVER» як блокер релізу, а не як приємне доповнення.
Визначте стратегію щодо Secure Boot і задокументуйте її. «Порозбираємось пізніше» — не стратегія, це майбутній інцидент.

Більшість випадків «оновлення системи зламало модулі» — просто невідповідність артефактів. Як тільки ви почнете ставитися до initramfs як до продукту збірки, який можна інспектувати і валідувати, драм менше.
Linux не крихкий. Наші припущення — крихкі.