SystemdDoctor
служба не работает ядро обновления

Служба падает после обновления ядра: модуль не собран

Службы, работающие через сторонние модули ядра (драйверы, средства виртуализации, сетевые фильтры), перестают работать после обновления ядра: модуль собран под прежнюю версию и не загружается.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Модуль не пересобран под новое ядро

    Сторонние модули собираются под конкретную версию ядра. При обновлении сборку нужно повторить, и обычно это делает механизм автоматической сборки — если он настроен.

  2. Ядро с проверкой подписи модулей

    При включённой проверке неподписанный модуль не загрузится. Признак — сообщение о неверной подписи в журнале ядра.

  3. Служба не объявила зависимость от модуля

    Если модуль загружается вручную, после перезагрузки его нет, и служба падает на первом обращении.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Сообщения ядра о загрузке модулей.

journalctl -k -b --no-pager | grep -iE "module|taint" | tail -20

Загруженные модули.

lsmod | head -20

Состояние автоматической сборки сторонних модулей.

dkms status 2>/dev/null

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Модуль не пересобран под новое ядро
Почему происходит
Сторонние модули собираются под конкретную версию ядра. При обновлении сборку нужно повторить, и обычно это делает механизм автоматической сборки — если он настроен.
Как проверить
Посмотрите, загружается ли модуль, и состояние сборки.
sudo modprobe имя_модуля 2>&1 | head
uname -r
dkms status 2>/dev/null
Как исправить
Пересоберите модуль под текущее ядро и убедитесь, что автоматическая сборка настроена: иначе следующее обновление ядра сломает службу снова.
2. Ядро с проверкой подписи модулей
Почему происходит
При включённой проверке неподписанный модуль не загрузится. Признак — сообщение о неверной подписи в журнале ядра.
Как проверить
Посмотрите состояние проверки подписи и сообщения.
journalctl -k -b --no-pager | grep -iE "module verification|signature" | tail
mokutil --sb-state 2>/dev/null
Как исправить
Подпишите модуль своим ключом или отключите проверку подписи в настройках загрузки — второе ослабляет защиту машины.
3. Служба не объявила зависимость от модуля
Почему происходит
Если модуль загружается вручную, после перезагрузки его нет, и служба падает на первом обращении.
Как проверить
Посмотрите, загружен ли модуль и есть ли он в списке автозагрузки.
lsmod | grep имя_модуля
cat /etc/modules-load.d/*.conf 2>/dev/null
Как исправить
Добавьте модуль в /etc/modules-load.d — он будет загружаться при старте системы.

Пример вывода

Модуль не собран под новое ядро. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

kernel: myapp_drv: version magic '6.8.0-51-generic SMP mod_unload' should be '6.8.0-52-generic SMP mod_unload'
modprobe[1100]: modprobe: ERROR: could not insert 'myapp_drv': Invalid module format
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

Связанные ошибки

Источники

  • modules-load.d(5)
    Загрузка модулей при старте системы.
    официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Наблюдалось после обновления ядра с несобранным сторонним модулем.
    собственная проверка, systemd 255
    сверено 15 сентября 2026