SSD Nodes Learn 🎉 VPS от $5.50/мес
Руководства Matt ConnorАвтор: Matt Connor · Обновлено 2026-08-15

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

Если раздел /boot переполнен старыми пакетами linux-image, apt выдает ошибку нехватки места. Узнайте, как безопасно удалить ненужные ядра, сохранив текущую версию системы.

Почему 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 удаляет не только пакет, но и оставшиеся конфигурационные файлы. Это освобождает немного дополнительного места и позволяет избежать накопления строк rc в dpkg --list, что упрощает чтение последующих отчетов аудита.

Затем убедитесь, что загрузочное меню было перестроено. Удаление пакета ядра автоматически запускает 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 недостаточно свободного места.

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 будут указывать на несуществующие файлы, из-за чего система не загрузится при следующей перезагрузке, а не в момент совершения ошибки.