Debian/Ubuntu: как исправить mkinitramfs failure, missing modules и initramfs unpacking failed

Ошибки mkinitramfs failure, missing modules, сообщения от depmod и предупреждение initramfs unpacking failed чаще всего появляются после обновления ядра в Debian и Ubuntu. Иногда сервер еще загружается на старом ядре, но новое уже неработоспособно. Иногда проблема проявляется прямо во время установки пакетов: update-initramfs падает, dpkg остается в неконсистентном состоянии, а следующая перезагрузка становится рискованной.

Обычно это не «фатальная поломка ядра», а вполне приземленная история: поврежден или не полностью установлен каталог /lib/modules, переполнен /boot, не завершилась установка пакетов, сломан hook, не отработал depmod или уже созданный initramfs оказался битым. Самая частая ошибка администратора в такой ситуации — начать удалять ядра наугад и случайно снести последнее рабочее.

Безопасный подход простой: сначала определить, на каком ядре система работает сейчас, затем проверить диск, пакеты и дерево модулей, после этого восстановить пакетный статус, пересобрать initramfs и только потом думать о чистке старых ядер или переустановке проблемной версии. На удаленном сервере это особенно важно, если у вас нет физического доступа к консоли.

Не удаляйте текущее рабочее ядро, пока новое не установлено полностью и не проверено хотя бы одной успешной загрузкой.

Ниже — практический runbook для Debian и Ubuntu, который удобно выполнять шаг за шагом, контролируя результат после каждой команды.

Как понять, что именно сломалось

Похожие на вид ошибки означают немного разное, и это важно для правильного ремонта.

• mkinitramfs failure — финальный симптом: сборка initramfs завершилась неуспешно.
• missing modules — для конкретной версии ядра отсутствуют ожидаемые модули или каталог модулей неполный.
• ошибки depmod — не удается построить зависимости модулей, часто из-за отсутствующих файлов .ko или поврежденного дерева /lib/modules/<version>.
• initramfs unpacking failed — проблема уже на этапе загрузки: initramfs поврежден, обрезан, некорректно собран или не подходит по содержимому.

Первый вопрос: сбой виден только при установке пакетов или уже мешает загрузке. Если система все еще стартует на старом ядре — это хороший сценарий. Если новое ядро не грузится, но старое доступно из GRUB — тоже ремонтируемо без лишнего риска. Самый неприятный вариант — когда рабочее ядро уже удалено, а сервер доступен только через rescue-консоль.

Базовая диагностика: ядро, пакеты и свободное место

Не спешите переустанавливать ядро. Сначала снимите текущее состояние системы: какое ядро загружено, хватает ли места в /boot, нет ли зависших пакетов и удержаний.

uname -r
ls -1 /boot
df -h
df -i
dpkg --audit
apt-mark showhold

Особенно внимательно смотрите на раздел /boot. Даже если корневой раздел заполнен умеренно, маленький отдельный /boot на 200–500 МБ очень часто становится источником проблем после нескольких обновлений ядра.

Затем проверьте, какие пакеты ядра и служебные пакеты реально установлены:

dpkg -l | grep -E 'linux-image|linux-headers|linux-modules|initramfs-tools'

И сразу сравните загруженное ядро со списком каталогов модулей:

uname -r
ls -1 /lib/modules

Если пакет ядра числится установленным, а каталога /lib/modules/<version> нет или он пустой, это почти прямое объяснение ошибок missing modules и depmod.

Для удаленных инстансов на VDS и обычных VM имеет смысл до перезагрузки убедиться, что у вас есть доступ к консоли провайдера: это сильно упрощает откат, если новое ядро не взлетит.

Самая частая причина: битый или неполный каталог /lib/modules

При неудачном обновлении, переполненном диске, обрыве питания или конфликте пакетов система может успеть зарегистрировать пакет ядра в dpkg, но не разложить модульное дерево до конца. В итоге update-initramfs пытается собрать образ для ядра, у которого нет части драйверов диска, файловой системы, LVM, RAID или виртуального контроллера.

Проверьте содержимое каталога проблемного ядра:

ls -lah /lib/modules/$(uname -r)
find /lib/modules/$(uname -r) -maxdepth 2 -type f | head

Если проблема относится не к текущему, а к новому ядру, подставьте нужную версию вручную. В нормальной структуре вы должны видеть каталог kernel и индексные файлы вроде modules.dep, modules.alias, modules.order.

Если каталога нет, он практически пустой или в нем отсутствуют индексные файлы, не пытайтесь чинить это вручную. Надежнее переустановить пакет ядра и заново собрать initramfs.

Как безопасно пересобрать зависимости модулей

Если файлы модулей на месте, но индексы не собрались, сначала выполните depmod:

depmod -a
depmod -a 6.8.0-52-generic

Затем попробуйте пересобрать initramfs только для проблемной версии:

update-initramfs -u -k 6.8.0-52-generic

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

ls -lh /boot/initrd.img-6.8.0-52-generic
file /boot/initrd.img-6.8.0-52-generic

Слишком маленький initrd.img почти всегда означает, что проблему вы не решили до конца.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Если update-initramfs падает: ищем первичную причину

Сообщение mkinitramfs failure — это обычно не причина, а следствие. Настоящая ошибка находится выше по выводу: не найден модуль, не смонтирован /boot, закончилось место, не отработал hook, поврежден компрессор, отсутствует нужный пакет или пакетная система зависла в полуустановленном состоянии.

Проверьте журналы и историю операций:

journalctl -b -p err
journalctl -xe
grep -Ri 'initramfs\|mkinitramfs\|depmod' /var/log
tail -n 200 /var/log/dpkg.log
tail -n 200 /var/log/apt/history.log

Если ошибка возникла во время установки пакетов, сначала восстановите консистентность пакетной базы:

dpkg --configure -a
apt -f install

Повторять update-initramfs до исправления статуса dpkg обычно бессмысленно: вы будете каждый раз упираться в один и тот же недоустановленный пакет.

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

Переустановка проблемного ядра без удаления рабочего

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

apt install --reinstall linux-image-6.8.0-52-generic linux-modules-6.8.0-52-generic
apt install --reinstall linux-headers-6.8.0-52-generic
update-initramfs -c -k 6.8.0-52-generic
update-grub

Ключ -c здесь полезен тем, что создает initramfs заново, а не пытается обновить уже потенциально битый образ.

Если вы не уверены в названии пакетов, сначала получите список реально установленных версий:

dpkg -l | grep '^ii' | grep -E 'linux-image|linux-modules'

На Ubuntu не путайте метапакеты вроде linux-generic и конкретные версионные пакеты. Исправлять обычно нужно именно версионный linux-image-... и соответствующий linux-modules-....

Нехватка места в /boot: причина, которую часто замечают слишком поздно

Если в /boot нет свободного места, новый initrd.img может записаться не полностью, а установка следующего ядра оборвется в самый неудобный момент. Это один из самых частых сценариев на серверах, которые долго обновлялись без ручной чистки старых пакетов.

Проверьте размер и содержимое раздела:

df -h /boot
ls -lh /boot

Сначала убедитесь, на каком ядре работает система сейчас:

uname -r

Только после этого удаляйте действительно старые версии, не затрагивая текущее ядро и то, которое вы собираетесь тестировать:

apt purge linux-image-6.8.0-31-generic linux-headers-6.8.0-31-generic linux-modules-6.8.0-31-generic
apt autoremove --purge
update-grub

Затем заново соберите initramfs:

update-initramfs -u -k all

Если у вас отдельный /boot, обязательно проверьте, что он вообще смонтирован. Иначе система могла записать файлы в каталог на корневом разделе, а не в реальный загрузочный раздел:

mount | grep ' /boot '
findmnt /boot

Когда initramfs unpacking failed появляется уже при загрузке

Сообщение initramfs unpacking failed не всегда означает мгновенную катастрофу. Бывает, что предупреждение появляется в консоли, но система продолжает загружаться. Однако если после него root-раздел не находится, загрузка уходит в emergency shell или просто зависает, действовать нужно уже как при поломке загрузочного образа.

Типовые причины здесь такие:

• initramfs поврежден или обрезан из-за нехватки места;
• в образ не попали модули контроллера диска, LVM, RAID, dm-crypt или файловой системы;
• каталог /lib/modules не соответствует версии ядра;
• часть пакетов ядра установлена не полностью;
• повреждены файлы в /boot или есть проблемы с файловой системой.

Если старое ядро доступно через GRUB, загрузитесь в него и выполняйте ремонт уже из рабочей системы. Это намного безопаснее, чем пытаться править состояние пакетов из аварийной оболочки initramfs.

Проверка initramfs-tools и модулей для root-диска

Если проблема повторяется на каждом новом ядре, проверьте настройки initramfs-tools и набор модулей, попадающих в ранний загрузочный образ. Особенно это актуально для LVM, RAID, LUKS, NVMe, virtio и нестандартных виртуальных контроллеров.

grep -v '^#' /etc/initramfs-tools/initramfs.conf
ls -1 /etc/initramfs-tools/conf.d
ls -1 /etc/initramfs-tools/modules
cat /etc/initramfs-tools/modules

Если корневой диск расположен на виртуальном или NVMe-устройстве, отсутствие критичного модуля может ломать загрузку уже на ранней стадии. В спорной ситуации допустимо временно добавить ключевые модули вручную и пересобрать образ:

printf '%s
' virtio_blk virtio_scsi nvme ext4 xfs dm_mod >> /etc/initramfs-tools/modules
update-initramfs -u -k all

Не нужно бездумно включать десятки модулей «на всякий случай», но драйверы root-диска, LVM и файловой системы должны быть в initramfs обязательно.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Что делать, если сломан текущий пакетный статус

Иногда ядро здесь вообще не первопричина. Настоящая проблема — прерванное обновление: завис apt, закончился диск, оборвалась сессия, параллельно запустился автоматический timer, не завершился postinst-скрипт. В такой ситуации ошибки depmod и update-initramfs — только верхушка айсберга.

Базовый порядок восстановления выглядит так:

1. Проверить статус dpkg и незавершенные операции.
2. Довести пакетную систему до консистентного состояния.
3. Переустановить конкретный пакет ядра, если он установлен не полностью.
4. Пересоздать initramfs.
5. Обновить GRUB.

dpkg --audit
dpkg --configure -a
apt -f install
apt install --reinstall initramfs-tools initramfs-tools-core
update-initramfs -u -k all
update-grub

Если в логах видно, что сбой начался с firmware-пакета или DKMS-модуля, сначала добейтесь загрузочного рабочего образа на базовом ядре, а уже потом возвращайтесь к дополнительным драйверам.

DKMS и сторонние модули после обновления ядра

Отдельный класс проблем — внешние модули через DKMS. Если они не пересобираются под новое ядро, вся установка может завершиться ошибкой, и вы увидите те же mkinitramfs failure или сообщения от depmod.

Проверьте состояние DKMS:

dkms status
journalctl -b | grep -i dkms

Если внешний модуль не собирается, это не всегда мешает самой загрузке, но часто ломает postinst-скрипты. В таком случае обновите проблемный DKMS-пакет или временно уберите его из уравнения, затем завершите установку ядра и пересборку initramfs.

Особенно осторожно действуйте, если от DKMS зависит доступ к сети или диску. На production-сервере задача номер один — восстановить гарантированную загрузку, а не любой ценой сохранить весь набор внешних модулей.

Проверка результата перед перезагрузкой

Перед ребутом убедитесь, что у нового ядра есть весь комплект файлов: образ ядра, initramfs, каталог модулей и запись в GRUB.

ls -lh /boot/vmlinuz-* /boot/initrd.img-*
ls -ld /lib/modules/*
grep menuentry /boot/grub/grub.cfg | head -n 20

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

Профилактика: как не поймать проблему снова

Ошибки вокруг initramfs редко возникают внезапно. Обычно им предшествуют переполненный /boot, старые ядра, прерванные обновления, неаккуратные правки в /etc/initramfs-tools или забытые DKMS-модули.

• держите минимум одно гарантированно рабочее старое ядро;
• перед обновлением проверяйте свободное место в /boot;
• не прерывайте apt, пока не завершились postinst-скрипты;
• после установки ядра проверяйте вывод update-initramfs и update-grub;
• имейте доступ к VNC, serial console или rescue-среде;
• на хостах с DKMS тестируйте новые ядра аккуратнее, чем на «чистых» системах.

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

Краткий runbook

Если нужен короткий порядок действий без лишней теории, используйте такую последовательность:

1. Проверить текущее ядро, место на диске и статус пакетов.
2. Убедиться, что /boot смонтирован и не переполнен.
3. Сверить версии в dpkg, /boot и /lib/modules.
4. Выполнить dpkg --configure -a и apt -f install.
5. При необходимости переустановить конкретный пакет ядра.
6. Запустить depmod -a <version> и update-initramfs -c -k <version>.
7. Обновить GRUB и только потом перезагружать сервер.

Эта схема закрывает большинство практических случаев с mkinitramfs failure, missing modules, ошибками depmod и initramfs unpacking failed в Debian и Ubuntu без лишнего риска для рабочего окружения.