Как очистить раздел /boot от старых ядер в Ubuntu

Почему apt перестает работать при заполнении /boot старыми ядрами

В Ubuntu каждое обновление ядра записывает новый набор файлов в /boot и оставляет предыдущие версии на месте. В результате небольшой раздел /boot переполняется, и apt не может завершить установку. Исправление состоит из двух этапов. Определите, какие пакеты в системе являются ядрами, а какое из них загружено в данный момент, после чего удалите остальные с помощью apt autoremove --purge.

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

Как на самом деле выглядит сбой

Версия ядра устанавливает два больших файла в /boot: сжатое ядро (vmlinuz-<version>) и initramfs (начальная файловая система в оперативной памяти, initrd.img-<version> — небольшой архив, который ядро распаковывает перед монтированием основного корня). Образ initramfs собирается на вашей машине во время установки, поэтому для процесса требуется свободное место, а не только пропускная способность сети для загрузки. При нехватке места сборка завершается ошибкой, что приводит к сбою установки пакета.

update-initramfs: Generating /boot/initrd.img-6.8.0-64-generic
gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-6.8.0-64-generic with 1.
dpkg: error processing package linux-image-6.8.0-64-generic (--configure):
 installed linux-image-6.8.0-64-generic package post-installation script subprocess returned error exit status 1

Строка версии будет соответствовать вашей системе. Имя программы-архиватора берется из COMPRESS= в /etc/initramfs-tools/initramfs.conf, поэтому в свежих образах может быть указан zstd, тогда как в старых — gzip. Две строки, указывающие на эту проблему, — это No space left on device и следующая за ней строка dpkg: error processing package.

После этого пакет остается в состоянии незавершенной настройки. Каждый последующий запуск apt пытается настроить его снова, терпит ту же неудачу и завершается сообщением E: Sub-process /usr/bin/dpkg returned an error code (1). Это важный момент, выходящий за рамки простого отсутствия места на диске: unattended-upgrades запускается по расписанию, натыкается на ту же ошибку и прекращает работу. Сервер выглядит исправным, но незаметно перестает применять обновления безопасности. Это также означает, что любая попытка установки другого ПО будет приводить к такой же ошибке, и подозрение падет на тот пакет, который вы пытались добавить в этот момент. Именно поэтому стоит ознакомиться с ошибкой установки Tailscale в Ubuntu, чтобы в первую очередь рассматривать её как ошибку apt. Если apt update завершается с ошибкой раньше, чем вы дошли до этого этапа, это отдельная проблема, часто связанная с дублирующими записями после миграции источников deb822.

Проверка того, является ли /boot отдельным разделом

Прежде чем что-либо удалять, выясните, какой именно объем дискового пространства вы освобождаете.

findmnt /boot
findmnt -T /boot
df -h /boot /

Первая команда выводит строку только в том случае, если /boot является отдельной точкой монтирования. Вторая команда выводит данные всегда и указывает файловую систему, на которой фактически размещен /boot. Если они указывают на ту же файловую систему, что и /, значит, /boot — это просто каталог в корневой файловой системе, и он не может переполниться сам по себе: ваша корневая файловая система заполнена, а старые ядра — лишь одна из причин. В этом случае команда sudo apt clean, которая очищает загруженные файлы .deb в каталоге /var/cache/apt/archives, освободит место. На машине с отдельным разделом /boot команда apt clean не освободит там ничего, так как кэш находится в другой файловой системе.

Теперь получите числовые значения, с которыми будете работать.

df -h /boot
ls -lh /boot/vmlinuz-$(uname -r) /boot/initrd.img-$(uname -r)

Сравните столбец Avail с размером этих двух файлов. Файл initrd является более крупным. Для следующего обновления ядра потребуется место для еще одной пары файлов примерно такого же размера, поэтому, если Avail меньше размера текущего initrd, следующее обновление гарантированно завершится ошибкой.

Определение используемого ядра

uname -r
cat /var/run/reboot-required.pkgs

uname -r выводит строку версии ядра, которое в данный момент находится в памяти. Скопируйте эту строку. Это та версия, которую нельзя удалять.

Второй файл существует только в том случае, если пакет запросил перезагрузку. Наличие строки linux-image в нем означает, что на диске установлено более новое ядро, которое не используется, так как система не перезагружалась с момента его установки. По возможности выполните перезагрузку перед очисткой. apt защищает текущее и самое новое ядро, поэтому очистка во время работы на старом ядре сохранит в системе на одну версию больше, чем требуется.

Список пакетов ядра и их состояния

dpkg --list | grep -E 'linux-(image|modules|headers|tools)' | awk '{print $1, $2}'

Первое поле — это код состояния dpkg. ii означает, что пакет установлен и настроен. iF означает, что пакет установлен, но настроен лишь частично; именно это состояние остается после неудачного обновления, описанного выше. rc означает, что пакет удален, но его конфигурационные файлы остались на диске; они не занимают места в /boot, и их можно безопасно удалить командой purge.

Второе поле указывает тип пакета. Имя с версией, например linux-image-6.8.0-64-generic, относится к конкретной версии ядра. Имя без версии, такое как linux-image-generic, linux-headers-generic или linux-generic, является метапакетом. Он не содержит самого ядра. Его единственная задача — зависеть от новейшей версии ядра, чтобы apt upgrade автоматически устанавливал обновления. Удаление метапакета приведет к тому, что система перестанет получать обновления ядра, и никаких предупреждений об этом впоследствии не будет.

Семейства пакетов распределяются следующим образом. linux-image-* содержит сжатый образ ядра в /boot. linux-modules-* и linux-modules-extra-* содержат драйверы в /lib/modules. linux-headers-* содержит заголовочные файлы для сборки в /usr/src; это означает, что удаление заголовков освобождает место в корневой файловой системе, а не в /boot. Если ваша проблема заключается в переполнении раздела /boot, вам следует искать именно пакеты образов ядра.

ls -1 /boot/vmlinuz-*
ls -1 /lib/modules/

Эти два списка должны соответствовать друг другу и выводу команды dpkg --list. Наличие директории в /lib/modules, для которой нет соответствующего установленного пакета, означает, что файлы были удалены вручную.

Как apt определяет, какие ядра оставить

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

apt-config dump | grep -i -e neverautoremove -e versionedkernel
ls -l /etc/apt/apt.conf.d/01autoremove /etc/apt/apt.conf.d/01autoremove-kernels

APT::NeverAutoRemove — это список шаблонов имен пакетов, которые apt autoremove отказывается удалять. APT::VersionedKernelPackages — это список префиксов имен, которые apt изначально считает версионируемыми пакетами ядер. В релизах, где создается файл /etc/apt/apt.conf.d/01autoremove-kernels, он перезаписывается утилитой /etc/kernel/postinst.d/apt-auto-removal при каждой установке пакета ядра, поэтому ручное редактирование не имеет смысла: при следующей установке ядра ваши правки будут стерты. В релизах, где этот файл отсутствует, apt применяет те же правила защиты внутренними средствами. В любом случае, команда apt-config dump покажет правила, действующие на вашем сервере, и этот вывод является единственно верным ответом для вашего релиза.

Безопасная очистка

sudo apt update
sudo apt autoremove --purge --dry-run

--dry-run не вносит изменений на диск, а лишь выводит список того, что будет удалено при реальном запуске. Изучите этот список. Есть два признака, которые должны вас остановить. Если в списке на удаление присутствует метапакет, такой как linux-generic или linux-image-generic, это означает, что он был помечен как установленный автоматически, и его удаление приведет к прекращению обновлений ядра. Если в списке присутствует строка из uname -r, это означает, что текущее ядро не защищено от удаления; такая ситуация не должна возникать, и её необходимо исследовать перед продолжением.

Если список выглядит корректно, выполните команду по-настоящему.

sudo apt autoremove --purge
df -h /boot

Ключ --purge удаляет не только пакет, но и оставшиеся файлы конфигурации. Это освобождает немного дополнительного места и избавляет dpkg --list от накопления строк rc, что делает последующий аудит более наглядным.

Затем убедитесь, что меню загрузки было перестроено. Удаление пакета ядра автоматически запускает update-grub, поэтому меню должно содержать ссылки только на существующие файлы.

sudo grep -o 'vmlinuz-[^ ]*' /boot/grub/grub.cfg | sort -u
ls -1 /boot/vmlinuz-*

Каждая версия из первого вывода должна присутствовать во втором. Если пункт меню указывает на несуществующий файл, рабочий сервер может остановиться на приглашении GRUB. Это один из путей к VPS, которая не загружается после обновления ядра, и исправить это из консоли восстановления гораздо сложнее, чем предотвратить на данном этапе.

Почему apt autoremove иногда ничего не удаляет

apt autoremove удаляет только пакеты, помеченные как установленные автоматически, то есть те, что были установлены в качестве зависимостей других пакетов. Ядро, которое вы установили самостоятельно с помощью apt install linux-image-6.8.0-40-generic, помечается как установленное вручную, поэтому autoremove никогда не будет его удалять, независимо от того, насколько старым оно стало.

apt-mark showmanual | grep -E '^linux-'

Любое ядро с указанием версии в этом выводе невидимо для autoremove. Удалите его вручную, используя строки версий из вашего собственного списка:

sudo apt-mark auto linux-image-6.8.0-40-generic linux-modules-6.8.0-40-generic
sudo apt autoremove --purge --dry-run

Оставьте метапакеты помеченными как установленные вручную. Они должны иметь такой статус, так как это именно те пакеты, которые вы запрашивали.

Принудительное удаление конкретной версии ядра

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

sudo apt purge linux-image-6.8.0-40-generic

apt выводит список удаляемых пакетов перед выполнением операции, так как linux-modules-extra-* зависит от пакета образа и должен быть удален в рамках той же транзакции. Этот список — ваша основная проверка безопасности; по нему можно понять, не удаляется ли метапакет вместе с версией, которую вы хотели убрать. Если в списке есть что-то непредвиденное, ответьте n. После этого выполните sudo apt autoremove --purge, чтобы удалить пакеты модулей и заголовков, которые потеряли смысл существования.

Почему нельзя удалять работающее ядро

Ядро, уже находящееся в оперативной памяти, продолжает работать после удаления файлов, поэтому на первый взгляд ничего не ломается. Проблемы возникают со всем, что ядро еще не успело загрузить. Удаление linux-modules-$(uname -r) приводит к удалению /lib/modules/$(uname -r)/, из-за чего следующая попытка загрузки модуля завершается ошибкой:

modprobe: FATAL: Module nf_tables not found in directory /lib/modules/6.8.0-64-generic

С этого момента перезагрузка межсетевого экрана завершается неудачей, как и монтирование файловой системы того типа, с которым ядро не работало с момента загрузки. Тем временем /boot/vmlinuz-$(uname -r) удален, поэтому в меню загрузки больше нет того ядра, которое вы используете, и следующая перезагрузка приведет к непредсказуемому результату. Сервер продолжает обрабатывать трафик, но уже не может загрузиться. Всегда сверяйте uname -r со списком удаляемых пакетов.

Когда раздел /boot переполнен и apt не запускается

Это состояние вынуждает пользователей искать данную страницу. apt autoremove требует dpkg для завершения настройки пакета ядра, который находится в полурабочем состоянии. Этот этап пересобирает initramfs, для чего требуется место в /boot, которого нет. Разорвите этот цикл вручную, один раз.

uname -r
ls -1 /boot/initrd.img-*

Выберите один initrd, версия которого не совпадает со строкой, выданной uname -r, и удалите этот единственный файл.

sudo rm /boot/initrd.img-6.8.0-40-generic
sudo apt --fix-broken install
sudo apt autoremove --purge
sudo update-grub

У каждой строки есть причина. rm — это намеренное исключение, из-за которого dpkg считает, что файл существует, хотя это не так. apt --fix-broken install завершает настройку, которая ранее завершилась ошибкой, так как теперь появилось место для initramfs. Затем autoremove --purge удаляет пакет, чей файл вы удалили, вместе с другими старыми версиями, что приводит состояние dpkg в соответствие с диском. update-grub пересобирает меню на основе фактически существующих файлов. Не перезагружайтесь между rm и update-grub, так как в этот промежуток времени меню может по-прежнему указывать на файл, который вы только что удалили. Если dpkg сообщает о прерывании работы, sudo dpkg --configure -a выполняет то же восстановление, что и apt --fix-broken install.

Аналогичная задача в системах на базе dnf

Если ваш VPS работает под управлением Fedora или одного из дистрибутивов, основанных на RHEL, например Rocky Linux, механизм работает иначе. В Debian и Ubuntu ядра защищены правилами автоудаления apt, а очистка остается на ваше усмотрение или запускается через unattended-upgrades. В то же время dnf принудительно ограничивает количество ядер параметром installonly_limit и автоматически удаляет самое старое ядро, как только установка нового превышает этот лимит. Проверьте текущее значение с помощью grep installonly_limit /etc/dnf/dnf.conf и man 5 dnf.conf, а для очистки накопившихся старых версий используйте sudo dnf remove --oldinstallonly. Запущенное в данный момент ядро также защищено от удаления. Подробную таблицу соответствия команд для обоих пакетных менеджеров см. в разделе эквиваленты команд dnf и apt.

Предотвращение повторения проблемы

Очистка, которая зависит от того, вспомните ли вы о ней, рано или поздно не сработает, поэтому добавьте её в процесс установки ядер. Откройте /etc/apt/apt.conf.d/50unattended-upgrades и найдите следующие ключи, которые уже присутствуют в поставляемом файле в виде закомментированных строк:

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Раскомментируйте их, вместо того чтобы добавлять вторую копию в конец файла. В конфигурации apt последнее присвоение ключа имеет приоритет, поэтому дубликат делает файл противоречивым и скрывает, какое значение является актуальным. Проверьте, что в итоге получилось у парсера, и проследите за выполнением команды, которая ничего не меняет:

apt-config dump | grep -i 'Unattended-Upgrade::Remove'
sudo unattended-upgrade --dry-run --debug
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Лог — это доказательство. Он записывает каждый запуск, поэтому обновление, которое не удалось из-за нехватки места, появится там задолго до того, как кто-то заметит, что сервер отстал от графика обновлений. Остальная часть этой конфигурации описана в автоматических обновлениях безопасности в Ubuntu.

Перед тем как появится следующее ядро, нужно проверить одно число; это та же пара команд, что была в начале руководства:

df -h /boot
ls -lh /boot/initrd.img-$(uname -r)

Если Avail не будет с запасом превышать размер этого файла, следующее ядро не установится точно так же, как описано выше, поэтому исправьте это сейчас, а не во время обновления. Эта проверка стоит минуты времени наряду с другими проверками состояния диска на VPS. Это особенно важно непосредственно перед обновлением дистрибутива, так как переход с Ubuntu 24.04 на 26.04 устанавливает новое ядро в самом начале процесса, и do-release-upgrade откажется продолжать работу, если в /boot недостаточно места. Если ваш LTS-сервер ещё не получил предложение об обновлении, причина в сроках, а не в ошибке: Ubuntu задерживает обновления между LTS-версиями до выхода точечного релиза 26.04.1, что даёт вам понятный временной интервал для приведения /boot в порядок.

FAQ

Почему Ubuntu сохраняет старые ядра вместо их удаления?

Потому что если новое ядро не загрузится, у вас не останется других вариантов выбора. Сохранение предыдущей версии означает, что неудачное обновление можно исправить через меню GRUB, а не через консоль восстановления провайдера. apt поэтому защищает набор пакетов ядра от автоматического удаления, всегда включая ту версию, которая запущена в данный момент. Выполните apt-config dump | grep -i neverautoremove, чтобы увидеть точные шаблоны, защищаемые в вашем релизе, так как политика менялась от версии к версии.

Безопасно ли запускать apt autoremove --purge на рабочем сервере?

Да, при условии, что вы сначала ознакомились с результатами пробного запуска. Выполните sudo apt autoremove --purge --dry-run, который ничего не удаляет, и изучите выведенный список. Остановитесь, если в нем присутствуют метапакеты, такие как linux-generic или linux-image-generic, так как их удаление прекратит получение будущих обновлений ядра. Также остановитесь, если в списке присутствует версия, которую выводит uname -r. Если ничего из этого нет, то к удалению предлагаются только старые ядра и осиротевшие зависимости.

apt autoremove ничего не удалил, а раздел /boot всё ещё переполнен. Что делать?

Старые ядра почти наверняка помечены как установленные вручную, а autoremove затрагивает только пакеты, помеченные как автоматические. Выполните apt-mark showmanual | grep -E '^linux-'. Любое ядро с указанием версии, которое там появится, было когда-то установлено вручную. Пометьте его как автоматическое с помощью sudo apt-mark auto linux-image-<version> и снова запустите пробный запуск, либо удалите эту конкретную версию напрямую командой sudo apt purge linux-image-<version>.

Можно ли удалять файлы из /boot вручную?

Только в качестве исключительной разовой меры, когда раздел /boot настолько переполнен, что apt не может сконфигурировать поврежденный пакет ядра. Удалите один файл initrd.img-<version>, версия которого не совпадает с выводом uname -r, затем немедленно выполните sudo apt --fix-broken install, sudo apt autoremove --purge и sudo update-grub. Удаление файлов без этих последующих шагов приведет к тому, что dpkg будет учитывать пакеты, файлы которых отсутствуют, а в меню GRUB останутся записи, указывающие на несуществующие файлы. В результате система выйдет из строя при следующей перезагрузке, а не в момент совершения ошибки.