Як безпечно видалити старі ядра Ubuntu та звільнити /boot

Чому apt припиняє працювати, коли /boot заповнюється старими ядрами

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

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

Як саме виглядає помилка

Під час встановлення версії kernel у /boot записуються два великі файли: стиснений kernel (vmlinuz-<version>) і initramfs (initial RAM filesystem, initrd.img-<version> — невеликий архів, який kernel розпаковує перед монтуванням справжньої root-файлової системи). 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, наступне оновлення вже завершиться помилкою.

Знайдіть kernel, під яким працює система

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

uname -r виводить release string kernel, який зараз завантажений у пам’ять. Скопіюйте цей рядок в окреме місце. Це та версія, яку не можна видаляти.

Другий файл існує лише тоді, коли пакет запросив перезавантаження. Рядок linux-image у ньому означає, що новіший kernel уже встановлено на диску, але він не використовується, оскільки після його встановлення машину не перезавантажували. Якщо це можливо, перезавантажте систему перед очищенням. apt захищає kernel, під яким працює система, і найновіший kernel. Тому під час очищення старий kernel залишатиметься закріпленим довше, ніж потрібно.

Перелік пакетів ядра та перевірка їхніх станів

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

Перше поле — це код стану dpkg. ii означає, що пакет встановлено й налаштовано. iF означає, що пакет встановлено, але налаштовано лише частково. Саме такий стан залишає невдале оновлення вище. rc означає, що пакет видалено, але його конфігурацію залишено на диску. Вона не займає місця в /boot, тому такий пакет можна безпечно очистити.

Друге поле показує тип пакета. Назва з версією, наприклад linux-image-6.8.0-64-generic, позначає конкретну версію ядра. Назва без версії, наприклад linux-image-generic, linux-headers-generic або linux-generic, позначає meta package. Він не містить ядра. Його єдине завдання — залежати від найновішої версії ядра, щоб apt upgrade встановлював нові ядра. Видалення meta package припиняє отримання оновлень ядра. Після цього система не показує жодного попередження.

Пакети поділяються на такі сімейства. linux-image-* містить стиснене ядро в /boot. linux-modules-* і linux-modules-extra-* містять драйвери в /lib/modules. linux-headers-* містить заголовки для збирання в /usr/src. Тому очищення заголовків звільняє місце у файловій системі root, а не місце в /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, який не завантажується після оновлення ядра. Виправити таку проблему з rescue console набагато складніше, ніж запобігти їй на цьому етапі.

Чому 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

Залиште meta-пакети позначеними як встановлені вручну. Саме так і має бути, оскільки ви встановили їх явно.

Навмисне видалення певного kernel

Іноді потрібно негайно видалити певну версію, а не чекати, доки це дозволить policy. Вкажіть пакет image, а apt виконає решту роботи.

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

apt спочатку виводить список на видалення, а вже потім виконує операцію, оскільки linux-modules-extra-* залежить від пакета image і має бути видалений у тій самій транзакції. Цей список є фактичною перевіркою безпеки. Саме тут можна виявити, що разом із потрібною версією видаляється meta package. Введіть n, якщо список містить щось неочікуване. Після цього виконайте sudo apt autoremove --purge, щоб видалити пакети модулів і заголовків, які більше не потрібні.

Чому не можна видаляти kernel, який зараз працює

Kernel, уже завантажений у пам’ять, продовжує працювати після видалення його файлів, тому спочатку нічого не ламається. Ламається все, що kernel ще не встиг завантажити. Очищення linux-modules-$(uname -r) видаляє /lib/modules/$(uname -r)/, тому наступне завантаження модуля завершується помилкою:

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

Після цього не вдається перезавантажити firewall. Також не вдається змонтувати тип файлової системи, до якого цей kernel не звертався після завантаження. Водночас /boot/vmlinuz-$(uname -r) видалено, тому меню завантаження більше не пропонує kernel, під яким працює система, а після наступного перезавантаження система завантажиться з іншим kernel. Машина продовжує обробляти network traffic, але вже не може завантажитися. Щоразу звіряйте 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, а не через rescue console провайдера. apt тому захищає набір kernel packages від автоматичного видалення та завжди включає до нього версію, яку ви використовуєте. Виконайте apt-config dump | grep -i neverautoremove, щоб переглянути точні шаблони, які захищає ваш release, оскільки політика змінювалася між release.

Чи безпечно виконувати apt autoremove --purge на production server?

Так, якщо спочатку переглянути dry run. Виконайте sudo apt autoremove --purge --dry-run — ця команда нічого не записує — і перевірте виведений список. Зупиніться, якщо в ньому є meta package, наприклад linux-generic або linux-image-generic, оскільки видалення одного з них припинить майбутні оновлення ядра. Також зупиніться, якщо список містить рядок версії, який виводить uname -r. Якщо немає жодного з цих елементів, видалятися будуть старі ядра та orphaned dependencies.

apt autoremove нічого не видалив, а /boot досі заповнений. Що робити?

Найімовірніше, старі ядра позначені як manual, а autoremove обробляє лише пакети, позначені як automatic. Виконайте apt-mark showmanual | grep -E '^linux-'. Будь-яке versioned kernel у цьому списку колись було встановлено вручну. Позначте його як automatic за допомогою sudo apt-mark auto linux-image-<version> і знову виконайте dry run або безпосередньо purge цю версію за допомогою sudo apt purge linux-image-<version>.

Чи можна вручну видалити файли з /boot?

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