Debian/Ubuntu: как освободить /boot и исправить ошибки initramfs при обновлении ядра

Ошибка /boot no space left обычно всплывает в самый неудобный момент: во время apt upgrade, установки нового ядра или пересборки initramfs. В логах при этом встречаются формулировки вроде initramfs update error, apt kernel update failed, not enough free space in boot и сообщения от dpkg о невозможности завершить настройку пакета.

Типичный сценарий простой: у сервера есть небольшой отдельный раздел /boot, в нём накопились старые ядра и их образы initrd, а очередное обновление уже не помещается. Особенно часто это случается на старых шаблонах, VPS с компактной разметкой и системах, которые долго обновлялись без ручной проверки.

Хорошая новость в том, что в большинстве случаев проблема решается без переустановки и без опасных экспериментов с загрузчиком. Плохая — чистить /boot надо очень аккуратно: если удалить текущее ядро или запутать состояние пакетов, можно получить уже не ошибку обновления, а не загружающуюся систему.

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

Материал особенно полезен тем, кто обслуживает серверы по SSH, в том числе на VDS, и хочет починить обновления без лишнего риска.

Как понять, что проблема именно в переполненном /boot

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

df -h /boot

df -i /boot

mount | grep ' /boot '

uname -r

Если df -h /boot показывает 100% использования или считаные мегабайты свободного места, причина почти очевидна. df -i /boot полезна на случай, если закончились не блоки, а inode. Команда uname -r покажет ядро, на котором система работает сейчас — его удалять нельзя.

Дальше полезно посмотреть содержимое раздела и понять, что именно занимает место. Обычно это файлы vmlinuz-*, initrd.img-*, System.map-* и config-*.

ls -lh /boot

du -sh /boot/* 2>/dev/null | sort -h

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

Главное правило: сначала выясняем, какое ядро загружено сейчас, и только потом удаляем старые версии. Не ориентируйтесь на даты файлов — смотрите на версии пакетов и вывод uname -r.

Почему /boot переполняется

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

На Debian и Ubuntu пакеты ядра обычно называются через linux-image-..., а заголовки — через linux-headers-.... При установке нового ядра создаётся соответствующий initramfs, и именно на этом этапе чаще всего возникает ошибка: пакет распакован, но его финальная настройка не помещается в раздел.

Из-за этого apt и dpkg могут остаться в промежуточном состоянии. После первого сбоя любые следующие операции с пакетами начинают ругаться на незавершённую конфигурацию, даже если проблема уже частично устранена.

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

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

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

Подробнее

Сначала определяем текущее и старые ядра

Перед удалением нужно увидеть список установленных пакетов ядра. Нас интересуют прежде всего linux-image, а также связанные с ними linux-modules, linux-modules-extra и linux-headers.

uname -r

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

dpkg -l | grep '^ii' | grep 'linux-headers'

Сравните вывод пакетов с результатом uname -r. Текущее ядро удалять нельзя. На практике обычно оставляют ещё и одно предыдущее рабочее ядро как резервное.

• оставляем ядро, на котором система работает сейчас;
• оставляем ещё одно предыдущее ядро как запасной вариант;
• все более старые версии удаляем через пакетный менеджер;
• не трогаем метапакеты вроде linux-image-amd64 или linux-generic, если не уверены в их роли.

Это важно, потому что метапакеты отвечают за нормальное получение новых ядер в будущем. Удалить старую конкретную версию — хорошо. Удалить метапакет — значит потенциально сломать дальнейшие обновления ядра.

Безопасная очистка старых ядер

Правильный путь — удалять старые версии через apt или dpkg, а не вручную стирать файлы из /boot. Тогда корректно обновится база пакетов, перестроится загрузочная конфигурация и не останется мусора.

Сначала можно посмотреть, что система считает больше не нужным:

apt autoremove --dry-run

Если список выглядит нормально и там действительно старые ядра, часто достаточно выполнить:

apt autoremove

Если же система уже споткнулась во время обновления и autoremove не проходит, удаляем конкретные старые версии вручную:

apt purge linux-image-6.8.0-41-generic linux-headers-6.8.0-41-generic

apt purge linux-image-6.8.0-45-generic linux-headers-6.8.0-45-generic

На Ubuntu вместе с образом ядра часто нужно удалить и пакеты модулей:

dpkg -l | grep '6.8.0-41-generic'

apt purge linux-image-6.8.0-41-generic linux-modules-6.8.0-41-generic linux-modules-extra-6.8.0-41-generic linux-headers-6.8.0-41-generic

После удаления сразу проверьте, освободилось ли место:

df -h /boot

ls -lh /boot

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

Что делать, если apt уже сломан и пишет про dpkg или initramfs

После переполнения /boot очень часто появляются ошибки вида dpkg was interrupted, Sub-process /usr/bin/dpkg returned an error code или update-initramfs: failed for .... Это ожидаемо: обновление стартовало, но не смогло завершиться.

После освобождения места выполните стандартную цепочку восстановления:

dpkg --configure -a

apt -f install

update-initramfs -u -k all

update-grub

Если update-initramfs -u -k all снова жалуется на нехватку места, значит очищено недостаточно или в /boot лежат лишние файлы, не привязанные к пакетам. Тогда повторно сверяем содержимое раздела и список установленных ядер.

Иногда полезно сначала пересобрать образ только для текущего ядра:

update-initramfs -u -k $(uname -r)

Но в финале систему всё равно стоит привести в полностью согласованное состояние и убедиться, что все установленные ядра имеют свои образы и записи в GRUB.

Если после очистки dpkg --configure -a отрабатывает без ошибок, это уже хороший признак: чаще всего основная аварийная часть позади.

Если места настолько мало, что apt purge не запускается

Это самый неприятный сценарий: /boot заполнен под завязку, и даже штатное удаление пакетов не может завершиться. В такой ситуации допустима только очень аккуратная аварийная мера.

Сначала ещё раз фиксируем текущее ядро:

uname -r

Потом ищем явно старые файлы initrd.img-*, которые точно не относятся к текущему ядру и не являются вашим последним резервным вариантом. В крайнем случае можно временно переместить один старый образ из /boot, чтобы высвободить место для нормальной работы пакетного менеджера.

ls -lh /boot

mv /boot/initrd.img-6.8.0-41-generic /root/

Часто одного старого initrd.img уже достаточно, чтобы вернуть возможность выполнить apt purge и завершить ремонт штатно. После этого нужно сразу удалить соответствующий пакет, обновить GRUB и проверить, что в /boot не осталось случайных остатков.

Руками нельзя трогать файл ядра текущей версии, а также не стоит массово удалять всё по шаблону. Ошибка в одной цифре здесь быстро превращается в необходимость лезть в консоль провайдера или rescue-режим.

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

Как проверить, не осталось ли битых пакетов и мусора

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

dpkg -l | grep '^i[^i]'

apt-mark showauto | grep linux

apt-mark showmanual | grep linux

ls -1 /boot

Команда dpkg -l | grep '^i[^i]' помогает найти пакеты, которые не находятся в нормальном состоянии ii. Если такие записи есть, их нужно дочинить через dpkg --configure -a, точечное apt install или удаление проблемного пакета.

Отдельно стоит проверить, нет ли в /boot файлов, для которых уже не существует пакетов. Такое бывает после ручных вмешательств или неудачных операций. Если сомневаетесь, сначала сверяйте версии с dpkg -l.

Нужно ли пересоздавать initramfs и обновлять GRUB

После очистки старых ядер и восстановления состояний пакетов ответ почти всегда один: да, нужно. Это недорогая и полезная проверка целостности загрузочной цепочки.

update-initramfs -u -k all

update-grub

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

До перезагрузки вы всё ещё работаете на уже загруженном ядре, даже если новое установилось успешно. Это нормально, но об этом легко забыть при проверке результата.

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

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

Подробнее

Когда проблема не в /boot, а в другом

Хотя запросы про boot partition full чаще всего действительно означают переполненный /boot, бывают и похожие случаи: заполнен корень /, закончились inode, файловая система смонтировалась только для чтения или не хватает места в /var для распаковки пакетов.

Поэтому базовая диагностика должна включать и общий взгляд на систему:

df -h

df -i

journalctl -p err -b

Если /boot свободен, а ошибка остаётся, ищите проблему в общем дисковом пространстве, состоянии файловой системы и журнале ошибок. Для похожей системной диагностики по PHP-нагрузке может пригодиться и разбор slowlog в PHP-FPM.

Профилактика: как не ловить это снова

После первого такого инцидента почти все админы начинают внимательнее относиться к разделу /boot. И правильно: проблема повторяется регулярно, особенно на серверах с автоматическими обновлениями безопасности.

• периодически запускайте apt autoremove после обновлений;
• не храните без причины много старых ядер;
• проверяйте размер /boot при развёртывании новых систем;
• держите доступ к консоли или rescue-режиму на случай неудачной загрузки;
• контролируйте результат обновлений, а не только факт их запуска;
• настройте мониторинг свободного места и алерт при заполнении раздела.

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

Краткий безопасный runbook

1. Проверить место: df -h /boot.
2. Узнать текущее ядро: uname -r.
3. Посмотреть установленные версии: dpkg -l | grep '^ii' | grep 'linux-image'.
4. Удалить старые ядра, кроме текущего и одного резервного: apt purge ....
5. Завершить незакрытые операции: dpkg --configure -a и apt -f install.
6. Пересобрать initramfs и обновить GRUB: update-initramfs -u -k all и update-grub.
7. Проверить, что обновления снова проходят без ошибок.

Итог

Ошибки вида /boot no space left, initramfs update error и apt kernel update failed в Debian и Ubuntu почти всегда связаны не с поломкой системы как таковой, а с банальной нехваткой места в маленьком загрузочном разделе.

Безопасный путь один: определить текущее ядро, удалить действительно старые версии через пакетный менеджер, восстановить состояния dpkg, пересобрать initramfs и обновить GRUB. Ручные действия в /boot допустимы только как временная аварийная мера.

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