Ubuntu 24.04: Secure Boot блокує драйвери — виправте без перевстановлення

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

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

Secure Boot має робити вашу систему безпечнішою. А потім ви встановлюєте оновлення драйвера, перезавантажуєтеся, і раптом ваша GPU зникла, Wi‑Fi пропав, або VirtualBox поводиться так, ніби ніколи не бачив ваше ядро. У логах — «verification failed». Машина каже «ні». І ваш календар каже, що зустріч через шість хвилин.

Ось реальність для Ubuntu 24.04 на сучасних UEFI-системах: Secure Boot + модулі поза ядром (NVIDIA, VirtualBox, ZFS DKMS, драйвери Wi‑Fi від вендора, агенти EDR) — це контракт. Якщо ви не підписали — модуль не завантажиться. Виправлення — не «перевстановити Ubuntu». Виправлення — діагностувати, що блокується, і або (a) записати ключ і підписати модулі, або (b) свідомо вимкнути Secure Boot у прошивці. Ви можете зберегти свою конфігурацію.

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

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

Спочатку: підтвердьте стан Secure Boot і примус до підписування модулів

Чи ввімкнений Secure Boot? Якщо вимкнений — перестаньте звинувачувати його і шукайте іншу причину.
Чи примусово ядро перевіряє підписи модулів? Ubuntu може застосовувати перевірку підписів, коли Secure Boot увімкнено. Це пояснює багато «раніше працювало» → «тепер заблоковано».
Який модуль не завантажується? Потрібні ім’я модуля і точний рядок помилки.

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

Чи це модуль DKMS? DKMS означає «перебудовується при оновленнях», а це значить «буде ламатися доти, доки не автоматизувати підписування».
Чи з пакета Ubuntu? Якщо так — є офіційні точки інтеграції (наприклад, підказки MOK під час інсталяції), якими можна скористатися.
Чи наданий постачальником? Якщо так — він може постачати неподписані бінарники або мати власний процес підписування.

По-третє: оберіть одну з двох розумних стратегій відновлення

Переважно для керованих флотів: залишайте Secure Boot ввімкненим, зареєструйте Machine Owner Key (MOK) і підписуйте модулі поза ядром (бажано автоматично).
Допустимо для персональних робочих станцій із прийнятним ризиком: вимкніть Secure Boot у прошивці й продовжуйте — задокументуйте це рішення, щоб майбутній ви не витрачали ніч на з’ясування причин.

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

Що насправді робить Secure Boot в Ubuntu 24.04

Secure Boot — це функція UEFI, яка перевіряє підписи завантажувачів і (на більшості сучасних дистрибутивів Linux) може поширити довіру на шлях завантаження модулів ядра. В Ubuntu ланцюжок зазвичай такий: прошивка перевіряє shim, shim перевіряє GRUB і ядро, а потім ядро використовує ключі (вбудовані та зареєстровані) для вирішення, які модулі ядра дозволено завантажувати.

Коротко: якщо Secure Boot увімкнений і ядро в режимі примусового валіду, модуль ядра без довірчої підпису завантажується як підроблене посвідчення в нічному клубі — незалежно від того, як «легітимно» він здається вам.

Ubuntu намагається зробити це терпимим за допомогою системи Machine Owner Key (MOK): ви генеруєте або встановлюєте ключ підписування, реєструєте публічну частину через диспетчер MOK під час завантаження, а потім підписуєте модулі приватним ключем. Після реєстрації ядро довіряє модулям, підписаним цим ключем.

Найбільша проблема — це синхронізація. Ви встановлюєте драйвер, DKMS будує модуль, і все здається в порядку — поки ви не перезавантажитеся, коли примусова перевірка Secure Boot змушує ядро відхилити його. Ваш драйвер «встановлений», але не працює. Ласкаво просимо в політично-кероване середовище.

Перефразована думка (не дослівно) від James Hamilton (Amazon, reliability): «Надійність досягається проєктуванням так, щоб відмова була нормальним станом, а не сюрпризом.» Відхилення модулів Secure Boot — це відмова через політику; ставтеся до цього як до інженерного стану, а не як до дивної помилки.

Факти та контекст, які варто знати

Secure Boot з’явився з вимогами Windows 8-ері (приблизно 2012) і став масовим, бо OEM-виробники почали вмикати його за замовчуванням.
Ubuntu використовує «shim», щоб працювати в екосистемі Microsoft UEFI CA, тож системи можуть завантажувати Linux без того, щоб кожен користувач керував платформеними ключами прошивки.
MOK існує, бо просити кожного користувача замінювати ключі прошивки нереалістично і часто неможливо на заблокованих ноутбуках.
Примусова перевірка підписів модулів ядра не однакова в усіх дистрибутивах; деякі трактують її як опціональну навіть із ввімкненим Secure Boot, тоді як Ubuntu схильна відхиляти неподписані модулі поза ядром.
DKMS має дві сторони: воно автоматично перебудовує модулі під нові ядра — чудово, поки не зрозумієте, що неподписані перебудови автоматично ламаються під Secure Boot.
NVIDIA-драйвери часто створюють проблеми, бо вони поза деревом ядра і багато налаштувань покладаються на DKMS для побудови під точне запущене ядро.
vboxdrv від VirtualBox — класичний приклад модуля, який «працює до перезавантаження», коли діє примусова підписка модулів.
У ядра є кілька ключових кілець (builtin, secondary, MOK/Platform); налагодження простіше, коли ви розумієте, що маєте справу з keyring-ами, а не з «флюїдами».
Деякі прошивки тихо скидають налаштування Secure Boot під час оновлень прошивки, тому ви можете «раптом» бачити відхилення модулів на раніше стабільній машині.

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

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

Завдання 1: Перевірити, чи ввімкнений Secure Boot

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

Значення: Прошивка каже, що Secure Boot увімкнений, і shim/mokutil бачать це.

Рішення: Далі працюйте, припускаючи, що неподписані модулі, ймовірно, будуть блокуватися. Якщо пише «disabled», ваша проблема, ймовірно, не в Secure Boot — перемикайтеся на інші діагностичні напрямки (сумісність драйвера, невідповідність ABI ядра або відсутні прошивки).

Завдання 2: Підтвердити, що ви завантажилися в режимі UEFI (не legacy/CSM)

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Значення: Ви справді в світі Secure Boot. Legacy-завантаження означає, що Secure Boot не застосовано.

Рішення: Якщо бачите «BIOS», зупиніться — виправлення, пов’язані з Secure Boot, тут не підходять. З’ясуйте, чому ви в legacy-режимі (налаштування прошивки, порядок завантаження, стара інсталяція) і виправте за потреби.

Завдання 3: Перевірити статус kernel lockdown

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity

Значення: Kernel lockdown активний в режимі «integrity», зазвичай спричинений Secure Boot. Це часто поєднується з примусовою перевіркою підписів і обмежує низькорівневі операції.

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

Завдання 4: Визначити симптом відсутнього драйвера (модуль не завантажується)

cr0x@server:~$ sudo modprobe nvidia
modprobe: ERROR: could not insert 'nvidia': Key was rejected by service

Значення: Модуль присутній, але відхилений через відсутність довіри до підпису.

Рішення: Це не проблема «драйвер не встановлений». Це проблема довіри/підпису. Рухайтеся до реєстрації MOK і підписування модулів.

Завдання 5: Прочитати системний лог ядра для точної причини відхилення

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Sat Dec 28 10:11:41 2025] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[Sat Dec 28 10:11:41 2025] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[Sat Dec 28 10:11:41 2025] nvidia: loading out-of-tree module taints kernel.
[Sat Dec 28 10:11:41 2025] nvidia: module license 'NVIDIA' taints kernel.

Значення: У вас одночасно lockdown і помилки перевірки. Зауважте різницю: «tainting kernel» — інформаційне повідомлення; «restricted» може означати, що модуль взагалі не завантажиться.

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

Завдання 6: Перевірити, чи модуль присутній і який файл завантажується

cr0x@server:~$ modinfo -n nvidia
/lib/modules/6.8.0-41-generic/updates/dkms/nvidia.ko

Значення: Модуль походить з виходу DKMS (updates/dkms). Це основна ціль для підписування.

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

Завдання 7: Перевірити статус DKMS (що побудовано для якого ядра)

cr0x@server:~$ dkms status
nvidia/550.90.07, 6.8.0-41-generic, x86_64: installed
vboxhost/7.0.20, 6.8.0-41-generic, x86_64: installed

Значення: DKMS побудував модулі для вашого поточного ядра. «Installed» не означає «завантажувано під Secure Boot».

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

Завдання 8: Перевірити, чи є зареєстровані MOK-ключі

cr0x@server:~$ sudo mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: 7a:9d:2b:1c:2f:7c:de:aa:8b:10:1b:6c:4f:5b:89:9a:1d:00:aa:41
Subject: CN=Ubuntu Secure Boot Module Signature key
Issuer: CN=Ubuntu Secure Boot Module Signature key

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

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

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

cr0x@server:~$ modinfo nvidia | egrep -i 'signer|sig_key|sig_hash'
signer:         CN=My DKMS Signing Key
sig_key:        3A:7F:1C:2D:4F:AA:11:9B:5A:1C:0D:32:77:2B:10:8F:DE:55:21:90
sig_hashalgo:   sha256

Значення: Модуль підписано. Тепер питання — чи довіряє ядро підпису (тобто чи зареєстровано відповідний публічний ключ через MOK або він у вбудованому keyring).

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

Завдання 10: Підтвердити, які keyring-і доступні ядру (операційна перевірка)

cr0x@server:~$ sudo keyctl list %:.system_keyring
3 keys in keyring:
  260754792: --alswrv     0     0 asymmetric: Ubuntu Secure Boot Module Signature key: X509.rsa
  412884911: --alswrv     0     0 asymmetric: Microsoft Windows Production PCA 2011: X509.rsa
  101388220: --alswrv     0     0 asymmetric: Canonical Ltd. Secure Boot Signing: X509.rsa

Значення: Системний keyring включає ключі Ubuntu/Canonical і часто ланцюжок Microsoft UEFI CA. MOK-ключі можуть з’явитися в вторинному keyring залежно від конфігурації.

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

Завдання 11: Перевірити, чи модуль блокує політика Secure Boot або бракує залежності

cr0x@server:~$ sudo modprobe vboxdrv
modprobe: ERROR: could not insert 'vboxdrv': Key was rejected by service

Значення: Та ж схема примусової перевірки підписів. VirtualBox — класика цього випадку.

Рішення: Не перенавантажуйтеся повторними інсталяціями VirtualBox. Підпишіть модуль і зареєструйте ключ. Перевстановлення дає той самий неподписаний модуль і свіжу фрустрацію.

Завдання 12: Швидко інспектувати змінні Secure Boot (допомагає виявити «скидання прошивки»)

cr0x@server:~$ sudo bootctl status | sed -n '1,18p'
System:
     Firmware: UEFI 2.70 (American Megatrends 5.17)
  Secure Boot: enabled
   Setup Mode: user
 TPM2 Support: yes
 Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 255.4-1ubuntu8
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ EFI variable boot loader control

Значення: Secure Boot увімкнений, і прошивка в режимі user (не setup). Режим setup може означати, що ключі були очищені/скинуті.

Рішення: Якщо бачите «Setup Mode: setup», вважайте це за «ключі платформи могли бути очищені», що може порушити довірчі ланцюжки і поведінку MOK. Переходьте до кроків управління прошивкою/ключами.

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

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

cr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii/{print $2,$3}' | tail -n 5
linux-image-6.8.0-40-generic 6.8.0-40.40
linux-image-6.8.0-41-generic 6.8.0-41.41
linux-image-generic 6.8.0.41.44

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

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

Завдання 14: Перебудувати DKMS для поточного ядра (коли вивід не збігається)

cr0x@server:~$ sudo dkms autoinstall -k 6.8.0-41-generic
Sign command: /lib/modules/6.8.0-41-generic/build/scripts/sign-file
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der

Building module:
Cleaning build area...
make -j16 KERNELRELEASE=6.8.0-41-generic...
Installing to /lib/modules/6.8.0-41-generic/updates/dkms/

Значення: Цей вивід показує здоровий шлях: DKMS знає про ключ підписування і викликає sign-file.

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

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

cr0x@server:~$ sudo tail -c 256 /lib/modules/6.8.0-41-generic/updates/dkms/vboxdrv.ko | strings | tail -n 5
~Module signature appended~
PKCS#7
X.509
sha256

Значення: У модулі є доданий blob підпису. Це грубий, але ефективний спосіб швидко довести, що підпис є.

Рішення: Якщо маркеру підпису немає — підпишіть. Якщо він є, але модуль відхиляють, у вас невідповідність довіри/реєстрації ключа.

Завдання 16: Переконатися, що ви справді завершили реєстрацію MOK при перезавантаженні

cr0x@server:~$ sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der
/var/lib/shim-signed/mok/MOK.der is already enrolled

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

Рішення: Вирівняйте «ключ, яким підписують» з «ключем, зареєстрованим у MOK». Один приватний ключ, один публічний сертифікат у MOK — без імпровізацій.

Шляхи виправлення: оберіть найменш ризикований

Є три реальних підходи. Два захищені. Один — «потім пожалкуєте».

Шлях A (найкращий): Залишати Secure Boot увімкненим, реєструвати MOK, підписувати модулі

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

Загалом:

Згенеруйте пару ключів для підписування (приватний ключ зберігається на машині з відповідними правами доступу).
Зареєструйте публічний сертифікат через MOK.
Підпишіть модулі поза ядром (NVIDIA, VirtualBox, ZFS DKMS, модулі вендора).
Переконайтеся, що DKMS підписує автоматично при перебудові, або додайте хуки після побудови.

Шлях B (іноді прийнятний): Вимкнути Secure Boot у прошивці

Це легітимне рішення, коли ви володієте ризиком і вам потрібно, щоб машина працювала зараз. Часто це роблять на робочих станціях для лабораторій, машинах в ізольованих мережах або домашніх/хобі-системах. Також це часто трапляється при роботі з певними агентами безпеки від вендорів, які не дружать з kernel lockdown.

Але якщо ви робите це на керованих кінцевих точках без документації, ви по суті залишаєте пастку для наступного on-call інженера (який може бути вами о 2-й ночі).

Шлях C (не робіть): «Примусове завантаження» неподписаних модулів

Люди шукають параметри завантаження та sysctl для обходу політики. Такий шлях непослідовний між ядрами, часто блокується lockdown і зазвичай розвалюється при наступному оновленні. Крім того, ви отримаєте систему з невідтворюваним і непідзвітним станом.

Короткий жарт #1: Secure Boot не «прискіпується». Воно просто робить ту роботу, яку ми попросили, на відміну від половини софту, який ми поставляємо.

Перелік кроків / покроковий план

Цей розділ — «робіть, не сперечайтесь» план. Виберіть сценарій, що відповідає вашій системі.

Сценарій 1: NVIDIA-драйвер встановлено, але блокується після перезавантаження

Підтвердіть, що блокування пов’язане з підписом (Завдання 4 і 5). Якщо бачите «Key was rejected by service», ви в потрібному місці.
Визначте шлях модуля (Завдання 6). Якщо він під updates/dkms, потрібно підписати DKMS-побудований модуль.
Перевірте зареєстровані ключі (Завдання 8) і чи модуль підписано (Завдання 9).
Якщо ключ відсутній: зареєструйте MOK:
```
cr0x@server:~$ sudo update-secureboot-policy --new-key
Creating new MOK key pair...
Key created in /var/lib/shim-signed/mok/
Importing new key into MOK...
input password:
```
Значення: Ubuntu згенерував пару ключів і поставив публічний сертифікат в чергу на реєстрацію в MOK. Він запитує одноразовий пароль, який використає MOK Manager під час завантаження.

Рішення: Перезавантажтеся зараз і завершіть реєстрацію в синьому екрані MOK Manager. Якщо пропустите — нічого не зміниться і ви витратите годину, звинувачуючи невірний рівень.
Після перезавантаження підтвердіть реєстрацію (Завдання 16).
Перебудуйте + підпишіть через DKMS (Завдання 14). Потім завантажте модуль:
```
cr0x@server:~$ sudo modprobe nvidia
```
Значення: Відсутність повідомлення — це успіх. Linux ввічливий.

Рішення: Якщо модуль завантажився, перевірте:
```
cr0x@server:~$ nvidia-smi
Sat Dec 28 10:26:12 2025
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.90.07              Driver Version: 550.90.07      CUDA Version: 12.4   |
+---------------------------------------------------------------------------------------+
```
Значення: Драйвер активний.

Рішення: Готово. Не чіпайте налаштування прошивки.

Сценарій 2: Драйвер ядра VirtualBox не завантажується («vboxdrv not loaded»)

Доведіть, що це відхилення підписом (Завдання 11).
Перевірте статус DKMS (Завдання 7).
Якщо DKMS не встановлено — встановіть потрібний пакет:
```
cr0x@server:~$ sudo apt-get install virtualbox-dkms
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  virtualbox-dkms
```
Значення: DKMS побудує модулі для вашого поточного ядра.

Рішення: З увімкненим Secure Boot ви все одно маєте забезпечити підписування (реєстрація MOK).
Зареєструйте/підтвердьте MOK-ключ (Сценарій 1, кроки 4/5).

Перебудуйте DKMS і підтвердьте підпис (Завдання 14). Потім:

cr0x@server:~$ sudo modprobe vboxdrv

Значення: Тихий успіх.

Рішення: Перевірте, що VirtualBox бачить драйвер:

cr0x@server:~$ VBoxManage list hostinfo | sed -n '1,12p'
Host Information:
Host name:            server
Operating system:     Linux
Operating system version: Ubuntu 24.04.1 LTS
Processor online count: 16
VirtualBox kernel modules: loaded

Сценарій 3: ZFS DKMS або інші модулі для зберігання не завантажуються

Якщо ви використовуєте ZFS-on-Linux через DKMS, Secure Boot може вдарити найболючіше в найгірший момент: коли ви перезавантажуєтеся після оновлення ядра, і ваші пули не імпортуються, бо модуль не завантажується. Інциденти зі зберіганням завжди мають найкращий таймінг.

Перевірте відмову завантаження модуля:
```
cr0x@server:~$ sudo modprobe zfs
modprobe: ERROR: could not insert 'zfs': Key was rejected by service
```
Рішення: Це проблема підпису/реєстрації, а не «ZFS зламався».

Підтвердьте шлях модуля:

cr0x@server:~$ modinfo -n zfs
/lib/modules/6.8.0-41-generic/updates/dkms/zfs.ko

Підтвердьте, що у вас є зареєстрований ключ і DKMS підписує (Завдання 8, 14, 16).
Після виправлення імпортуйте пули:
```
cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1034459023344556677
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          mirror-0  ONLINE
            sda     ONLINE
            sdb     ONLINE
```
Значення: Модуль ядра завантажено і ZFS бачить диски.

Рішення: Імпортуйте. Якщо пули не відображаються — у вас проблема в детекції сховища (HBA, multipath, шифрування), а не в Secure Boot.

Сценарій 4: Після ввімкнення Secure Boot не завантажується графіка (чорний екран)

Іноді симптом «драйвер заблоковано» проявляється як чорний екран або fallback framebuffer. Часто це відбувається, коли модулі NVIDIA блокуються і система намагається (і не вдається) коректно відновитися.

Завантажтеся в режим відновлення або в текстову консоль (спробуйте переключити TTY).
Підтвердіть помилки підпису через dmesg (Завдання 5).
Якщо потрібно швидко повернути GUI: тимчасово використайте відкриті драйвери або видаліть конфліктні пакети. Після цього проведіть правильний процес підписування для Secure Boot.

cr0x@server:~$ sudo apt-get purge 'nvidia*'
Reading package lists... Done
The following packages will be REMOVED:
  nvidia-dkms-550 nvidia-driver-550 ...

Значення: Ви видаляєте блокований набір модулів, щоб система могла використовувати альтернативні шляхи.

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

Три корпоративні кейси з практики

Кейс 1: Інцидент через неправильне припущення

В компанії був акуратний стандарт робочих станцій: Ubuntu LTS, Secure Boot увімкнений, шифрування диска на ноутбуках. Все логічно. Потім команда розгорнула пакет драйвера Wi‑Fi від вендора для партії нових ноутбуків, бо вбудований драйвер гірше працював в одному офісі з зашумленим RF середовищем.

Припущення було невимушеним і фатальним: «Якщо пакет встановився чисто — драйвер завантажиться». На тестовій машині так і було, бо Secure Boot місяцями тому вимкнули під час апгрейду обладнання і ніхто цього не задокументував.

У продукції новий драйвер встановився, DKMS побудував модуль, і все виглядало зелено у логах деплойменту. Після запланованого вікна перезавантажень ноутбуки повернулися без Wi‑Fi. Не «поганий» Wi‑Fi. Нема. Люди підключали телефони, щоб відвідувати наради — ознака реального інциденту.

Корінь проблеми виявився за п’ять секунд у dmesg: «Key was rejected by service.» Виправлення не складне — зареєструвати MOK і підписати DKMS-модуль — але відновлення затягнулося, бо машини були віддалені, а реєстрація MOK вимагає інтерактивного перезавантаження. Вони тимчасово відкотилися на вбудований драйвер, щоб відновити підключення, а потім виконали підписування в контрольованому вікні.

Висновок: якщо ваш деплой залежить від DKMS і Secure Boot увімкнений, у вас не процес «встановлення драйвера». У вас процес «керування ключами», який призводить до встановлення драйвера.

Кейс 2: Оптимізація, що дала зворотний ефект

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

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

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

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

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

Кейс 3: Нудна, але правильна практика, що врятувала ситуацію

Команда зі зберігання даних використовувала ZFS на флоті серверів Ubuntu для артефактів збірок. Не модно, але працювало. У них була сувора політика: кожен сервер мав «break glass» план у runbook — перевірки стану Secure Boot, процедури реєстрації MOK, та невелику резервну копію відомо-робочих ядер, притриману від автоповидалення.

Одного дня виробник обладнання розповсюдив оновлення прошивки. Після нього кілька серверів повернулися з Secure Boot увімкненим, тоді як раніше воно було вимкнене (або навпаки, залежно від моделі). Симптом був простий: після перезавантаження ZFS не завантажувався на двох вузлах. Пули і диски були в порядку. Ядро застосовувало перевірку підписів і DKMS-побудований ZFS-модуль не був довіреним.

Оскільки у них був нудний процес, відповідь була нудною теж: перевірити стан Secure Boot, підтвердити відхилення підпису, зареєструвати правильний MOK, перебудувати DKMS, підписати, перевірити завантаження, імпортувати пули. Ніякого панічного «fsck», ніяких експериментів з шляхом даних, ніяких випадкових понижень у проді.

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

Висновок: найкращий інструмент інцидент-менеджменту — runbook, який ви написали, коли були нудьгуючі.

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

1) «Драйвер встановлено, але пристрій відсутній після перезавантаження»

Симптом: GPU/Wi‑Fi/VirtualBox працює до перезавантаження; після — модуль не завантажується.

Корінь: Secure Boot увімкнений + модуль неподписаний/недовірений, тому його відхиляють під час завантаження.

Виправлення: Виконайте mokutil --sb-state, перегляньте dmesg на «Key was rejected by service», зареєструйте MOK, підпишіть модуль (або свідомо вимкніть Secure Boot).

2) «Я зареєстрував MOK, але все одно падає»

Симптом: Ви пройшли крок реєстрації MOK, але модулі все одно відхиляють.

Корінь: Ви зареєстрували інший публічний сертифікат, ніж приватний ключ, яким підписували, або не завершили UI MOK Manager під час перезавантаження.

Виправлення: Запустіть mokutil --test-key на сертифікаті, який думаєте що зареєстрований. Підтвердіть, що modinfo показує правильного signer-а. Якщо mismatch — пере-підпишіть модуль потрібним ключем або повторно зареєструйте вірний сертифікат.

3) «DKMS каже installed, отже має працювати»

Симптом: dkms status показує «installed», але модуль не завантажується.

Корінь: DKMS «installed» означає лише «побудовано і скопійовано», а не «довірено під Secure Boot».

Виправлення: Підтвердьте підпис за допомогою modinfo. Налаштуйте підписування DKMS (інструменти Ubuntu через update-secureboot-policy або свої хуки підписування).

4) «Чорний екран після ввімкнення Secure Boot»

Симптом: Система завантажується в чорний екран; TTY може працювати.

Корінь: GPU-модуль заблоковано; дисплей-менеджер запускається без апаратного прискорення або падає.

Виправлення: Завантажтеся в recovery/TTY, подивіться dmesg, тимчасово видаліть проблемний драйвер або підпишіть його правильно і переконайтеся в реєстрації ключа.

5) «Після оновлення прошивки все зламалося»

Симптом: Раніше стабільні DKMS-модулі тепер відхиляють, стан Secure Boot змінився.

Корінь: Оновлення прошивки могло скинути або змінити стан Secure Boot / ключі; може знадобитися повторна реєстрація MOK або зміна потоку завантаження.

Виправлення: Підтвердьте за допомогою mokutil --sb-state і bootctl status. При потребі зареєструйте MOK знову; перевірте keyring-и; повторно підпишіть модулі.

6) «Я вимкнув Secure Boot, але все одно пише «rejected»»

Симптом: Ви певні, що Secure Boot вимкнений, але модулі все ще падають.

Корінь: Ви могли переключити неправильну опцію прошивки (деякі UEFI мають окремі налаштування), або завантажуєте інший запис завантаження, або плутаєте Secure Boot з kernel lockdown, викликаним іншими налаштуваннями.

Виправлення: Підтвердіть стан з ОС (mokutil --sb-state) і перевірте режим UEFI. Не довіряйте лише UI прошивки.

7) «Я підписав модуль, але оновлення знову ламають»

Симптом: Працює до наступного оновлення ядра; потім знову ламається.

Корінь: DKMS перебудовує модуль при кожному оновленні ядра; якщо підпис був ручним — новий модуль непідписаний.

Виправлення: Інтегруйте підписування з DKMS (переконайтеся, що ключ підписування доступний, де DKMS очікує; перевірте, щоб у виводі DKMS згадувалось підписування). Додайте операційну перевірку перед перезавантаженням у нове ядро.

Короткий жарт #2: Найшвидший спосіб вивчити про Secure Boot — ігнорувати його один раз, а потім запланувати сесію навчання для наступного перезавантаження.

FAQ

1) Чи просто вимкнути Secure Boot?

Якщо це персональна машина і ви приймаєте компроміс, так — це дійсний вибір. На керованих системах краще залишати Secure Boot і підписувати модулі. Вимкнути Secure Boot легко; потім захищати його складніше.

2) Що таке MOK, простою мовою?

MOK (Machine Owner Key) — спосіб додати власний довірений сертифікат підписування в ланцюжок довіри завантаження без перепрошивки платформи. Ви реєструєте публічний сертифікат; потім ядро довіряє модулям, підписаним відповідним приватним ключем.

3) Чому Ubuntu блокує модулі, які «встановлені правильно»?

Тому що «встановлено» означає, що файли є на диску. Secure Boot перевіряє, чи ці файли довірені під час завантаження. Ядро застосовує політику; менеджери пакетів її не скасовують.

4) Як визначити, що це Secure Boot, а не зламаний драйвер?

Шукайте в dmesg рядки «Key was rejected by service» або «module verification failed: signature and/or required key missing». Також перевірте mokutil --sb-state. Якщо Secure Boot вимкнений — проблема, ймовірно, в іншому.

5) Чи знижує безпеку підпис модулів?

Це змінює межу довіри. Ви кажете ядру довіряти коду, підписаному вашим ключем. Це прийнятно, якщо ви захищаєте приватний ключ і контролюєте, що підписується. Це кращий варіант, ніж повністю вимикати Secure Boot.

6) Чому NVIDIA завжди в центрі уваги?

Бо драйвер поза ядром і часто будується через DKMS. Така комбінація означає, що нові ядра тригерять перебудови, перебудови потребують підпису, а підпис потребує зареєстрованого ключа. Пропустіть будь-який крок — і після перезавантаження буде біда.

7) Чи можу я підписувати модулі на одній машині і розгортати на інших?

Можете, але обережно: цільові машини мають довіряти сертифікату підписувача (MOK має бути зареєстрований всюди), і процес захисту приватного ключа має бути безпечним. У флотах це перетворюється на роботу з PKI і provisioning — робіть це усвідомлено або не робіть зовсім.

8) Що робити, якщо я загубив приватний ключ для підписування модулів?

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

9) Чому реєстрація MOK вимагає інтерактивного перезавантаження?

Бо реєстрація відбувається в процесі завантаження довіри. Середовище прошивки/shim показує UI MOK Manager, щоб підтвердити, що ви дійсно мали намір додати ключ. Це рішення з дизайну проти зловмисників, а не особлива зручність.

10) Як зробити, щоб це не повторювалося при оновленнях ядра?

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

Висновок: практичні наступні кроки

Ubuntu 24.04 у парі з Secure Boot не крихкий — він суворий. Ваші драйвери не «випадково падають». Їх відхиляють, бо вони не довірені за поточною політикою завантаження.

Зробіть це далі, в порядку:

Запустіть mokutil --sb-state і підтвердіть, що ви в режимі UEFI.
Спробуйте завантажити проблемний модуль і зафіксуйте точну помилку.
Перегляньте dmesg, щоб підтвердити відхилення підпису.
Оберіть стратегію: реєстрація MOK + підпис (переважно), або вимкнення Secure Boot (свідомо, з прийняттям ризику).
Якщо підписуєте: підтвердіть реєстрацію, перевірте підписувача модуля і зробіть підписування DKMS автоматичним перед тим, як дозволити оновлення ядра перезавантажувати систему.

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