Відсутня прошивка після встановлення Debian 13: правильно відновлюємо підтримку NIC і HBA

Що фактично відбувається (і чому Debian так поводиться)

«Відсутня прошивка» у Debian майже ніколи не означає, що драйвер ядра відсутній. Це означає, що драйвер завантажився, спробував ініціалізувати
обладнання, а потім запросив файл прошивки з простору користувача (зазвичай через udev/systemd-udevd) із
/lib/firmware. Драйвер є; мікрокодовий бінарник — ні.

На сучасних NIC і HBA прошивка — це не декоративна опція. Це спосіб, яким пристрій піднімає тренування лінку, механізми offload, управління чергами,
поведінку PHY і іноді навіть здатність коректно перерахувати або скинутися. Багато драйверів підключаються без прошивки,
але вони покажуть «netdev», який ніколи не вийде на лінк, або HBA, яке бачить присутність PCIe, але не піднімає SAS/SATA фізи.

Debian історично розділяв «вільне» програмне забезпечення і «non-free» прошивки. Це політичне рішення з технічними наслідками:
інсталятор і стандартні джерела apt можуть не включати пакети прошивки, потрібні для завантаження мережі або сховища.
Debian 12 ввів компонент non-free-firmware як перший клас репозиторію, що допомогло, але оновлення, кастомні образи
та мінімальні інсталяції все ще можуть залишити вас у пастці без прошивки.

Правильне виправлення — це не «скопіювати випадковий файл у /lib/firmware і забути». Правильне виправлення:
встановити потрібні пакети прошивки Debian (щоб отримувати оновлення, контрольні суми й відстеження залежностей),
забезпечити їхню наявність в initramfs, якщо потрібно,
і перевірити, що пристрій дійсно завантажив прошивку після перезавантаження.

Операційне правило: якщо машина потребує прошивки для доступу до мережі, яка постачає цю прошивку, вам потрібен позасітний шлях.
Це може бути фізичний носій, локальний mirror, друга робоча NIC або IPMI/iKVM з монтуванням ISO. Якщо ви смієтеся,
значить, ви вже були в цій ситуації.

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

Кілька фактів і історія, які варто знати

• Завантаження прошивки перестало бути «рідкісним краєм» і стало поведінкою за замовчуванням: багато PCIe-пристроїв постачаються з мінімальними ROM і покладаються на бінарники, які завантажує ОС, для функцій і виправлень.
• Linux використовує стандартний механізм запиту: драйвери викликають request_firmware(), і ядро просить користувацький простір надати файл із /lib/firmware.
• Розділення репозиторіїв Debian визначається політикою: історично «main» залишався вільним; прошивка часто не кваліфікувалася, тому жила в «non-free».
• Debian 12 ввів non-free-firmware: пакети прошивки перемістилися у виділений компонент, щоб спростити інсталяцію без змішування всього в «non-free».
• Поведінка інсталятора залежить від образу: деякі ISO інсталятори містять прошивку; інші навмисне не включають. Той самий інсталятор — різний результат.
• Прошивка NIC часто впливає на лінк і offload: інтерфейс може бути видимим, але без carrier, зі стабільною або дивною поведінкою контрольних сум/TSO.
• Прошивка HBA та драйвер ядра — окремі шари: PCIe-пристрій може перераховуватися, але SAS-транспорт ніколи не підніметься, якщо прошивка не завантажена або несумісна.
• Initramfs має значення для критичного для завантаження сховища: якщо кореневий FS розташований за HBA, яка потребує прошивки, бінарник має бути доступний рано (всередині initramfs), а не тільки після монтування кореня.
• Пакети прошивки оновлюють також з міркувань безпеки: це не лише «змусити пристрій працювати», а й «не постачати старий вразливий мікрокод/прошивку».

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

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

Перше: підтвердьте, що ядро бачить обладнання взагалі

• PCIe видно? Якщо lspci не показує пристрій, це не проблема пакета прошивки. Думайте про налаштування BIOS, живлення слота, біплексування, пошкоджений riser або несправну плату.
• Драйвер прив’язаний? Якщо пристрій видно, але немає прив’язаного драйвера, ви в зоні «відсутній драйвер/модуль», а не «відсутня прошивка».

Друге: пошукайте запити та помилки завантаження прошивки

• dmesg каже правду: шукайте «firmware», «Direct firmware load failed» або «failed to load». Це дасть точне ім’я файлу, який драйвер запитує.
• Зіставте ім’я файлу з пакетом: пакети Debian розміщують файли під /lib/firmware. Якщо файлу немає, встановіть пакет, який його забезпечує.

Третє: вирішіть, чи потрібна initramfs

• Корінь на цьому пристрої? Якщо відсутня прошивка впливає на пристрій, який забезпечує root (HBA, NVMe за контролером тощо), потрібно переконатися, що прошивка потрапляє в initramfs та перебудувати його.
• NIC не для кореня? Для NIC initramfs зазвичай не потрібен, якщо ви не робите netboot, не використовуєте iSCSI root або не потребуєте мережі на ранньому етапі для розблокування дисків.

Четверте: виправте конфігурацію репозиторіїв перед «виправленням прошивки»

• Увімкніть non-free-firmware: не вставляйте блоби вручну, якщо ви не ізольовані від мережі і не маєте дисципліни їх керувати.
• Оновіть, встановіть, перебудуйте initramfs, перезавантажте: зробіть це один раз, чисто, а потім перевірте журнали.

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

Завдання 1: Визначте точне обладнання (PCI ID)

cr0x@server:~$ sudo lspci -nn | egrep -i 'ethernet|network|fibre|sas|raid|scsi'
03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
04:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087]

Що це означає: Ядро бачить і NIC, і HBA на рівні PCIe. Добре.
Квадратні ідентифікатори (8086:1572, 1000:0087) — це ваші істини.

Рішення: Якщо ваш пристрій тут не відображається, припиніть шукати пакети прошивки. Перевірте BIOS/UEFI, встановлення в слот, живлення та топологію PCIe.

Завдання 2: Перевірте, який драйвер прив’язаний (або ні)

cr0x@server:~$ sudo lspci -nnk -s 03:00.0
03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
	Subsystem: Intel Corporation Ethernet Converged Network Adapter X710-2 [8086:0000]
	Kernel driver in use: i40e
	Kernel modules: i40e

Що це означає: NIC використовує i40e, отже драйвер існує і прив’язаний.

Рішення: Якщо «Kernel driver in use» відсутній, можливо, потрібне інше ядро, модуль або потрібно вирішити питання Secure Boot/підпис модулів — не прошивка.

Завдання 3: Знайдіть помилки прошивки в журналі ядра

cr0x@server:~$ sudo dmesg -T | egrep -i 'firmware|direct firmware|failed to load|i40e|mpt3sas' | tail -n 30
[Mon Dec 30 09:12:18 2025] i40e 0000:03:00.0: Direct firmware load for i40e/ddp/ppm.pkg failed with error -2
[Mon Dec 30 09:12:18 2025] i40e 0000:03:00.0: The DDP package was not found at i40e/ddp/ppm.pkg
[Mon Dec 30 09:12:19 2025] mpt3sas 0000:04:00.0: Direct firmware load for mpt3sas/mpi3mr.fw failed with error -2
[Mon Dec 30 09:12:19 2025] mpt3sas 0000:04:00.0: firmware: failed to load mpt3sas/mpi3mr.fw (-2)

Що це означає: Помилка -2 — «файл не знайдено». Драйвер запропонував конкретні імена файлів.

Рішення: Вам потрібні пакети, що надають /lib/firmware/i40e/ddp/ppm.pkg і /lib/firmware/mpt3sas/mpi3mr.fw, або принаймні правильний набір для вашого покоління пристрою.

Завдання 4: Підтвердьте, що файл прошивки відсутній (не робіть припущень)

cr0x@server:~$ ls -l /lib/firmware/i40e/ddp/ppm.pkg /lib/firmware/mpt3sas/mpi3mr.fw
ls: cannot access '/lib/firmware/i40e/ddp/ppm.pkg': No such file or directory
ls: cannot access '/lib/firmware/mpt3sas/mpi3mr.fw': No such file or directory

Що це означає: Файли відсутні. Це ще не «баг драйвера». Це відсутній файл.

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

Завдання 5: Перевірте компоненти apt (чи увімкнено non-free-firmware?)

cr0x@server:~$ grep -R --no-filename -E '^[[:space:]]*deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null
deb http://deb.debian.org/debian trixie main
deb http://deb.debian.org/debian-security trixie-security main
deb http://deb.debian.org/debian trixie-updates main

Що це означає: Увімкнено лише main. Пакети прошивки зазвичай містяться в non-free-firmware.

Рішення: Додайте non-free-firmware (і зазвичай contrib) до відповідних рядків.

Завдання 6: Оновіть джерела безпечно (зробіть правку один раз)

cr0x@server:~$ sudo sed -i 's/ main$/ main contrib non-free-firmware/' /etc/apt/sources.list
cr0x@server:~$ tail -n 3 /etc/apt/sources.list
deb http://deb.debian.org/debian trixie main contrib non-free-firmware
deb http://deb.debian.org/debian-security trixie-security main contrib non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free-firmware

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

Рішення: Тепер apt має бачити пакети прошивки. Якщо мережі все одно немає, вам потрібен офлайн-шлях — читайте далі.

Завдання 7: Оновіть метадані apt і перевірте пакети прошивки

cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://deb.debian.org/debian-security trixie-security InRelease
Hit:3 http://deb.debian.org/debian trixie-updates InRelease
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

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

Рішення: Якщо apt не може дістатися до репозиторіїв, оскільки єдина NIC потребує прошивки, переходьте до офлайн-кроків у розділі контрольних списків.

Завдання 8: Встановіть загальний набір прошивок (часто достатньо)

cr0x@server:~$ sudo apt install -y firmware-linux firmware-linux-nonfree firmware-misc-nonfree
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  firmware-linux firmware-linux-nonfree firmware-misc-nonfree
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 78.4 MB of archives.
After this operation, 210 MB of additional disk space will be used.
Setting up firmware-linux-nonfree (20250801-1) ...
Setting up firmware-misc-nonfree (20250801-1) ...
Setting up firmware-linux (20250801-1) ...

Що це означає: Ці мета-пакети покривають значну кількість звичних бінарників. Для серверних NIC і HBA це часто вирішує проблему негайно.

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

Завдання 9: Знайдіть, який пакет надає конкретний файл прошивки

cr0x@server:~$ apt-file update
cr0x@server:~$ apt-file search -x '(^|/)i40e/ddp/ppm\.pkg$'
firmware-misc-nonfree: /lib/firmware/i40e/ddp/ppm.pkg

Що це означає: apt-file зіставляє імена файлів з пакетами. Це чистий спосіб закрити дискусію швидко.

Рішення: Встановіть ідентифікований пакет(и). Якщо у вас мінімальне оточення без apt-file, використовуйте dpkg -S після встановлення ймовірних бандлів прошивки.

Завдання 10: Перебудуйте initramfs, коли мова про сховище

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.12.0-1-amd64
W: Possible missing firmware /lib/firmware/mpt3sas/mpi3mr.fw for module mpt3sas

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

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

Завдання 11: Переконайтеся, що файл прошивки тепер існує

cr0x@server:~$ ls -l /lib/firmware/i40e/ddp/ppm.pkg
-rw-r--r-- 1 root root 1048576 Aug  1 12:01 /lib/firmware/i40e/ddp/ppm.pkg

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

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

Завдання 12: Підтвердіть, що NIC дійсно піднімається і має лінк

cr0x@server:~$ ip -br link show
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp3s0f0         DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>

Що це означає: Інтерфейс існує. Він DOWN. Це може бути адміністративно (його не підняли) або фізично (немає carrier).

Рішення: Підніміть і перевірте carrier; якщо немає carrier, перевірте оптики, порт комутатора та журнал драйвера/прошивки.

Завдання 13: Підніміть інтерфейс і перевірте carrier + швидкість

cr0x@server:~$ sudo ip link set enp3s0f0 up
cr0x@server:~$ ip -br link show enp3s0f0
enp3s0f0         UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>
cr0x@server:~$ sudo ethtool enp3s0f0 | egrep -i 'link detected|speed|duplex'
Speed: 10000Mb/s
Duplex: Full
Link detected: yes

Що це означає: Лінк піднято на 10G, що свідчить про те, що ситуація з прошивкою NIC вирішена (принаймні для функціонування).

Рішення: Якщо Link detected: no, не одразу звинувачуйте прошивку. Перевірте сумісність оптик/DAC, конфігурацію комутатора і dmesg на предмет повторних скидань.

Завдання 14: Підтвердіть, що HBA перераховує пристрої

cr0x@server:~$ sudo lsscsi -g
[0:0:0:0]    disk    ATA      INTEL SSDSC2  DL2C  /dev/sda  /dev/sg0
[1:0:0:0]    disk    SEAGATE   ST16000NM00  SN03  /dev/sdb  /dev/sg1
[1:0:1:0]    disk    SEAGATE   ST16000NM00  SN03  /dev/sdc  /dev/sg2

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

Рішення: Якщо нічого не показує, перевірте dmesg на предмет помилок завантаження прошивки HBA або відсутності лінків на физах.

Завдання 15: Перевірте повідомлення модулів про прошивку після перезавантаження

cr0x@server:~$ sudo journalctl -b -k | egrep -i 'firmware|i40e|mpt3sas' | tail -n 40
Dec 30 09:24:01 server kernel: i40e 0000:03:00.0: firmware version 9.30 0x8000c6a8 1.2762.0
Dec 30 09:24:02 server kernel: i40e 0000:03:00.0: DDP package loaded successfully
Dec 30 09:24:02 server kernel: mpt3sas 0000:04:00.0: firmware version 16.00.12.00
Dec 30 09:24:02 server kernel: scsi host1: mpt3sas

Що це означає: Це стан успіху: рядки з версіями прошивки та відсутність «failed to load».

Рішення: Зберігайте ці журнали у ваших нотатках про збірку/комісіонування. При наступному оновленні ядра, якщо щось поламається,
ви знатимете, як виглядало «добре».

Як виправити правильно: репозиторії, пакети та initramfs

1) Віддавайте перевагу пакуваній прошивці над ручним додаванням файлів

Скопіювати бінарник у /lib/firmware працює — поки не перестане. Це обходить власність dpkg, ускладнює аудит і
тихо ламає перевстановлення, бо ніхто не знає про той артізаньський файл, який ви скопіювали опів на другу.

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

2) Явно увімкніть non-free-firmware

У Debian 13 розумний дефолт для реального обладнання — main contrib non-free-firmware для базових репозиторіїв.
Ви можете тримати non-free вимкненим, якщо хочете; прошивка відокремлена не випадково.

Якщо ви керуєте флотом, не залишайте це на волю випадку. Вбудуйте це в provisioning (preseed/autoinstall, золоті образи, конфігураційне управління).

3) Встановіть правильні пакети прошивки

Почніть з загальних наборів:
firmware-linux,
firmware-linux-nonfree,
firmware-misc-nonfree.
Вони покривають багато: шматки Intel NIC, Realtek, різні контролерні прошивки і загальні мікрокод-подібні payload.

Потім переходьте до цілевого підходу. Використовуйте ім’я файлу з dmesg і зіставляйте його з пакетом через apt-file search.
Це збереже вас від звички «встановити 600MB прошивок, бо бракує одного файлу».

4) Визначте, чи повинна прошивка бути в initramfs

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

Інструменти initramfs Debian зазвичай включають прошивки, пов’язані з включеними модулями, але існують крайні випадки:
модулі завантажуються пізніше, драйвер запитує після скидання або імена файлів змінюються між версіями ядра.
Якщо ви бачите попередження під час update-initramfs, сприймайте їх як підказку перевірити, а не як фоновой шум.

5) Перезавантажуйте усвідомлено (або чисто скидайте пристрій)

Прошивка завантажується під час ініціалізації пристрою драйвером. Іноді це можна викликати перезавантаженням модуля.
На серверах чисте перезавантаження часто найпростіше, особливо коли зачіпається сховище.
«Давайте просто rmmod драйвер HBA на живому корені» — це приклад кар’єрного розвитку, який трапляється несподівано.

Цитата (перефразована ідея) від Gene Kim: високопродуктивні операційні команди зменшують кількість відмов, роблячи роботу видимою і відтворюваною, а не героічною.

Особливості NIC і HBA: що ламається і як це виглядає

NIC: пристрій є, мережі немає

Збої прошивки NIC зазвичай проявляються трьома способами:

• Інтерфейс відсутній: рідко для «відсутньої прошивки», частіше для проблем з драйвером/модулем або PCI-проблем.
• Інтерфейс є, але немає carrier: бінарник або конфігурація PHY; також несумісні оптики/DAC.
• Інтерфейс працює, але нестабільний: повторні скидання в dmesg, флапінг лінку, дивні поведінки offload або падіння продуктивності під навантаженням.

Найпродуктивніша звичка: коли мережа зламана, завжди фіксуйте рядки dmesg навколо імені драйвера. На Intel серверних NIC ви часто побачите
запит DDP-пакетів або повідомлення, пов’язані з NVM. На Broadcom — імена прошивок bnx2/bnx2x. На Realtek — специфічні payload під rtl_nic/.

HBA: завантаження може працювати, а потім сховище розвалюється (або ніколи не з’являється)

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

Реальні сценарії відмов, які ви побачите:

• PCIe перераховано, немає SCSI-хостів: драйвер завантажився, але не може ініціалізувати контролер без прошивки.
• Є SCSI-хост, немає цілей: контролер ініціалізувався, але не може підняти фізи; іноді це кабелі/бекплейн, іноді — прошивка.
• Цілі з’являються періодично: скидання, таймаути, масові abort-команди; може бути прошивка, маргінальні SAS-кабелі або особливості expander/backplane.

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

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

Три корпоративні історії (усі реалістичні)

Інцидент через хибні припущення: «Інтерфейс є, отже прошивка має бути в порядку»

Середня компанія розгорнула Debian на новій партії серверів з двопортовими 10G NIC. Автоматизація у стилі kickstart перевіряла, що ip link
показує очікувані імена інтерфейсів, а потім налаштовувала VLAN, бонди і маршрутизацію. Критерій прийняття був простий: «інтерфейс присутній» і «MAC
відповідає інвентарю».

Першого тижня все здавалося нормальним — поки трафік не зріс. Під стійким навантаженням NIC почав скидатися, бонд руйнувався і відновлювався.
Моніторинг зафіксував випадкову втрату пакетів і дивні стрибки затримок. Мережна команда звинуватила комутатор. Серверна команда звинуватила мережну — як це часто буває.
Ніхто не хотів дивитися в dmesg, бо «начебто NIC є».

Журнали ядра казали інше: драйвер працював без DDP-пакету і постійно відкотувався. Це не було бінарним «працює/не працює».
Це було «працює, поки ви не попросите від нього те, за що заплатили».

Виправлення було нудним: увімкнути non-free-firmware, встановити правильний пакет прошивки, перезавантажити і оновити тест прийняття.
Новий тест вимагав «лінк up», «відсутність помилок завантаження прошивки» і «немає скидань під синтетичним навантаженням».
Те саме обладнання. Те саме ядро. Інший результат, бо перестали робити припущення.

Оптимізація, що відкотилася: мінімальні образи й «без зайвих пакетів»

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

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

Інженери відповіли класичним аварійним хаком: додали одноразовий крок, який scp-ив файл прошивки на хост під час провізіонування.
Це «виправило» початкове завантаження. Але створило іншу проблему: при наступному оновленні ядра ім’я файлу змінилося тонко,
initramfs не включив його, і перезавантаження стало рулеткою. Образи були мінімальні, але експлуатаційний безлад — максимальний.

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

Нудна, але правильна практика, що врятувала день: поетапні перезавантаження і збереження «хороших» журналів

Фінансова компанія мала консервативний процес змін. Не ефектно. Але ефективно.
Вони підтримували staging з тією ж сумішшю NIC/HBA, що й продакшн, і вимагали, щоб кожне оновлення ядра/прошивки проходило тест перезавантаження,
перевірку сховища і тест тривалої пропускної здатності мережі.

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

Перемога була не в хитрому дебагу, а в документації. У них був «золотий журнал завантаження» для кожної платформи з очікуваними рядками версій прошивки і відсутністю помилок.
На виклик вони могли порівняти staging/production за кілька хвилин.

Вони виправили дрейф, нав’язавши компоненти репозиторіїв і пакети прошивки через конфігураційне управління, а потім перебудували initramfs по флоту.
Продакшн не побачив простою. Єдина жертва — чиєсь переконання, що ретельний процес несумісний з інженерною гордістю.

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

1) «Інсталятор сказав, що прошивка відсутня, але система завантажується добре. Не буду це виправляти.»

Симптом: Завантаження успішне, але продуктивність NIC нестабільна або сховище видає таймаути пізніше.
Причина: Пристрій працює в деградованому режимі без прошивки або помиляється лише під певними навантаженнями.
Виправлення: Перегляньте dmesg для точних імен файлів прошивки, увімкніть non-free-firmware, встановіть правильні пакети, перезавантажте та перевірте версії прошивки в журналах.

2) «Я додав non-free, але apt все одно не знаходить пакети прошивки.»

Симптом: apt install firmware-… говорить «Unable to locate package».
Причина: Ви увімкнули неправильний компонент (non-free замість non-free-firmware), або ваші джерела вказують на невірний реліз.
Виправлення: Переконайтеся, що кожний рядок deb включає non-free-firmware і відповідає коду вашого релізу; запустіть apt update, потім повторіть спробу.

3) «Файл прошивки є, але dmesg все одно каже, що його не може завантажити.»

Симптом: /lib/firmware/… містить файл, але в журналі видно помилки завантаження.
Причина: Невірне ім’я/шлях для даної версії драйвера, initramfs не містить його для раннього завантаження, або проблеми з правами/SELinux-подібні обмеження (рідко у Debian за замовчуванням).
Виправлення: Підтвердіть точно шлях, який запитує dmesg; переконайтеся, що файл є за цим шляхом. Якщо критично для завантаження, перебудуйте initramfs і перевірте вміст.

4) «Мережа померла, тому я не можу apt install прошивку, яка відновить мережу.»

Симптом: Немає інтерфейсу, немає лінку або немає DHCP; apt не дістається до mirror-ів.
Причина: Єдина NIC потребує прошивки, і ви не надали її під час інсталяції.
Виправлення: Використайте офлайн-інсталяцію: змонтуйте ISO інсталятора і додайте його як джерело apt, встановіть пакети прошивки з нього (якщо вони там), або скористайтеся контрольованим USB/ISO з потрібними .deb пакетами.

5) «Я перебудував initramfs і тепер система не завантажується.»

Симптом: Завантаження падає в initramfs shell або не знаходить root.
Причина: Критичний для завантаження драйвер/прошивка не включені або ви неправильно змінили хуки/модулі initramfs.
Виправлення: Завантажте попереднє ядро/initramfs з GRUB, якщо доступно. Встановіть відсутні пакети прошивки, запустіть update-initramfs -u -k all і збережіть принаймні один відомо-робочий запис завантаження.

6) «Я заніс драйвер у чорний список, бо він спамив помилками прошивки.»

Симптом: Журнал став тихішим, але тепер ви не маєте NIC/сховища.
Причина: Лікування симптомів замість встановлення прошивки.
Виправлення: Приберіть чорний список, встановіть правильні пакети прошивки і перевірте стабільну роботу. Логи — не ворог; вони — свідки.

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

Контрольний список A: Онлайн-виправлення (мережа якось працює)

1. Зфіксуйте докази:

   cr0x@server:~$ sudo dmesg -T | egrep -i 'firmware|direct firmware|failed to load' | tail -n 80
   [Mon Dec 30 09:12:18 2025] i40e 0000:03:00.0: Direct firmware load for i40e/ddp/ppm.pkg failed with error -2
   

   Рішення: Запишіть точні імена файлів. Не вгадуйте.

2. Увімкніть потрібний компонент репозиторію:

   cr0x@server:~$ sudo editor /etc/apt/sources.list
   

   Рішення: Переконайтеся, що на відповідних рядках є main contrib non-free-firmware.

3. Оновіть і встановіть пакети прошивки:

   cr0x@server:~$ sudo apt update
   cr0x@server:~$ sudo apt install -y firmware-linux firmware-linux-nonfree firmware-misc-nonfree
   

   Рішення: Якщо конкретний файл все ще відсутній, зіставте його через apt-file і встановіть точний пакет.

4. Перебудуйте initramfs, якщо це потрібно для сховища/раннього завантаження:

   cr0x@server:~$ sudo update-initramfs -u -k all
   

   Рішення: Попередження про прошивку вашого пристрою означає, що ви ще не завершили.

5. Перезавантажте і переконайтеся, що прошивка завантажена:

   cr0x@server:~$ sudo reboot
   

   cr0x@server:~$ sudo journalctl -b -k | egrep -i 'firmware|failed to load' | tail -n 60
   Dec 30 09:24:02 server kernel: i40e 0000:03:00.0: DDP package loaded successfully
   

   Рішення: Відсутність рядків «failed to load» і наявність явних повідомлень про версію прошивки — ваш критерій успіху.

Контрольний список B: Офлайн-виправлення (немає робочої мережі)

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

• Змонтоване ISO інсталятора як apt-репозиторій (працює, якщо ISO містить потрібні пакети).
• Контрольований USB з .deb пакетами прошивки з вашого внутрішнього дзеркала.
• Тимчасово використайте відому робочу USB NIC для bootstrap реальної NIC (так, це неефектно, але дієво).

Опція 1: Використати змонтований ISO як репозиторій

cr0x@server:~$ sudo mkdir -p /mnt/iso
cr0x@server:~$ sudo mount -o ro /dev/sr0 /mnt/iso
cr0x@server:~$ ls /mnt/iso
README.html  dists  doc  install.amd  pool

Що це означає: ISO змонтовано і містить структуру репозиторію Debian.

Рішення: Додайте його до apt і спробуйте встановити пакети з нього.

cr0x@server:~$ echo "deb [trusted=yes] file:/mnt/iso trixie main contrib non-free-firmware" | sudo tee /etc/apt/sources.list.d/iso.list
deb [trusted=yes] file:/mnt/iso trixie main contrib non-free-firmware
cr0x@server:~$ sudo apt update
Get:1 file:/mnt/iso trixie InRelease
Reading package lists... Done

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

Рішення: Встановіть прошивки. Якщо apt їх не знаходить, цей ISO, ймовірно, не містить потрібних пакетів.

cr0x@server:~$ sudo apt install -y firmware-linux firmware-linux-nonfree firmware-misc-nonfree
Reading package lists... Done
Building dependency tree... Done
Selecting previously unselected package firmware-linux-nonfree.
Setting up firmware-linux-nonfree (20250801-1) ...

Опція 2: Встановити .deb пакети прошивки з USB (контрольований бандл)

cr0x@server:~$ sudo mount /dev/sdb1 /mnt
cr0x@server:~$ ls /mnt
firmware-linux-nonfree_20250801-1_all.deb
firmware-misc-nonfree_20250801-1_all.deb
firmware-linux_20250801-1_all.deb

Що це означає: Пакети доступні локально.

Рішення: Встановіть через dpkg, потім виправте залежності через apt, якщо можливо (з ISO або пізніше через мережу).

cr0x@server:~$ sudo dpkg -i /mnt/firmware-linux-nonfree_20250801-1_all.deb /mnt/firmware-misc-nonfree_20250801-1_all.deb /mnt/firmware-linux_20250801-1_all.deb
Selecting previously unselected package firmware-linux-nonfree.
Unpacking firmware-linux-nonfree (20250801-1) ...
Setting up firmware-linux-nonfree (20250801-1) ...

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

Контрольний список C: Перевірте і закріпіть (щоб не відкотилося)

1. Підтвердіть відсутність помилок завантаження прошивки при старті:

   cr0x@server:~$ sudo journalctl -b -k | egrep -i 'Direct firmware load|failed to load' || true
   

   Рішення: Пустий вивід — добре. Будь-які рядки тут потребують дії.

2. Перевірте приналежність файлів пакету (немає невідомих блобів):

   cr0x@server:~$ dpkg -S /lib/firmware/i40e/ddp/ppm.pkg
   firmware-misc-nonfree: /lib/firmware/i40e/ddp/ppm.pkg
   

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

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

   cr0x@server:~$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'mpt3sas/|i40e/'
   usr/lib/firmware/i40e/ddp/ppm.pkg
   usr/lib/firmware/mpt3sas/mpi3mr.fw
   

   Рішення: Якщо прошивка потрібна до монтування кореня і її тут немає, перебудуйте initramfs і перевірте хуки/модулі.

FAQ

1) Чому Debian встановлюється без прошивки, яка мені явно потрібна?

Тому що за замовчуванням Debian консервативний щодо того, що потрапляє в «main», а ліцензування прошивки часто не підпадає під вимоги.
Залежно від образу інсталятора та ваших виборів ви можете опинитися без пакетів прошивки, навіть якщо драйвер ядра присутній.

2) Чи достатньо увімкнути non-free-firmware, чи потрібен ще non-free?

Для прошивки ключовим є non-free-firmware. Можливо, вам знадобиться contrib для деяких залежностей пакування,
але non-free потрібен лише якщо ви хочете інше non-free ПЗ окрім прошивки.

3) Інсталятор попереджав про відсутність прошивки, але моя NIC зараз працює. Чи варто перейматися?

Так. Попередження зазвичай означає «драйвер запитав щось і не отримав». Іноді пристрій працює у fallback-режимі; іноді він падає пізніше.
Перевірте journalctl -b -k на помилки завантаження прошивки і усуньте їх навмисно.

4) Чи можу я просто скачати файл прошивки і помістити його в /lib/firmware?

Можете, але ви берете на себе управління життєвим циклом: оновлення, походження, аудит і забезпечення включення в initramfs, коли це потрібно.
У продакшні віддавайте перевагу Debian-пакетам прошивки, якщо ви не в air-gapped оточенні і не керуєте власним перевіреним бандлом.

5) Навіщо перебудовувати initramfs? Я вже встановив пакет.

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

6) Як дізнатися, який пакет містить мій відсутній файл прошивки?

Використовуйте apt-file search за іменем файлу, який повідомляє dmesg. Це найшвидший точний спосіб зіставлення «відсутній файл» → «встановіть цей пакет».

7) Після встановлення прошивки треба перезавантажуватися?

Часто так. Драйвери зазвичай завантажують прошивку під час ініціалізації пристрою. Іноді можна перезавантажити модуль для NIC,
але для HBA і шляхів сховища перезавантаження безпечніше і зазвичай швидше, ніж налагодження напівскинутого контролера.

8) Що робити, якщо я на віддаленому сервері без OOB, і єдина NIC потребує прошивки?

Ви в поганому архітектурному кутку. Практично: тимчасово використайте USB NIC (якщо маєте фізичний доступ),
або завантажтеся з rescue-носія з включеною прошивкою, або домовтеся про OOB-доступ у майбутньому.
Операційно: не розгортайте сервери без відновлюваного шляху для мережевого bootstrap.

9) Це баг ядра чи баг Debian?

Зазвичай ні те, ні інше. Це проблема доступності пакета/репозиторію плюс сучасний дизайн апаратного забезпечення.
Ви це підтвердите, перевіривши: драйвер присутній і прив’язаний, файл прошивки запрошено, файлу немає. Це не баг — це відсутня залежність.

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

Виправити «відсутню прошивку» в Debian 13 неважко. Справжня робота — зробити це так, щоб не вдарило пізніше.
Рецепт простий: ідентифікуйте пристрій і ім’я файлу прошивки, увімкніть non-free-firmware, встановіть потрібний пакет,
перебудуйте initramfs, якщо раннє завантаження цього вимагає, перезавантажтеся і перевірте журнали.

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

• Уніфікуйте компоненти apt (включіть non-free-firmware) через конфігураційне управління.
• Додайте перевірку при комісіонуванні, яка фейлить, якщо journalctl -b -k містить помилки завантаження прошивки.
• Збережіть «хороші» журнали завантаження з версіями прошивок для кожної платформи, щоб регресії було легко виявити.
• Забезпечте офлайн bootstrap-путь (ISO-репозиторій, внутрішнє дзеркало або OOB) до того, як це знадобиться.

Вам не потрібні герої. Потрібні повторювані процедури і дисципліна вірити своїм журналам.