Проблемы с /boot: переполнение и корневой раздел

24.09.2026 · ~7 минут чтения

boot grub kernel uefi cleanup filesystem

/boot переполняется незаметно: обновления идут неделями гладко, а потом в один день pacman -Syu валится с No space left on device прямо на пакете ядра. Разберём, какие бывают схемы размещения /boot, сколько весят ядра и почему они тянут за собой корень, и пройдём путь от диагностики до чистки. Мелкий раздел, старые ядра и забитый /, вот герой этого материала; чистка EFI-раздела и кэша пакетов разобраны в отдельных статьях.

Где живёт /boot: отдельный раздел или корень

/boot: точка монтирования, а не волшебная папка. В Arch встречаются три схемы, и от них зависит, что именно переполнится.

Отдельный раздел /boot на BIOS/MBR. На старых машинах с MBR под загрузку отрезали отдельный раздел ext4 размером 200–500 МБ: туда клали ядра, initramfs и файлы GRUB. Корень в такой схеме не трогают, но и запас скромный: пара ядер с fallback-образами забивает раздел почти полностью.

ESP смонтирован в /boot (UEFI). Так настраивают большинство установок Arch по умолчанию: EFI System Partition (FAT32, обычно 100–512 МБ) монтируется прямо в /boot, и на одном разделе рядом с .efi-файлами лежат vmlinuz, initramfs и grub.cfg. Здесь переполнение /boot и переполнение ESP: одно и то же событие.

/boot внутри корня, ESP в /efi. Современный вариант: на ESP живёт только загрузчик, а образы ядер на корневом разделе. Узкое место исчезает, зато /boot теперь ест место с корня: кончился /, и mkinitcpio некуда писать новый образ.

Посмотри, что у тебя настроено:

findmnt /boot
grep '/boot' /etc/fstab

Если findmnt показывает /dev/sdaX с файловой системой ext4, у тебя отдельный раздел или каталог в корне, зависит от того, что в fstab. Если там vfat, это ESP, и дальше речь пойдёт про маленький FAT32-раздел.

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

Симптомы почти одинаковы для всех схем:

pacman -Syu падает на пакете linux с No space left on device: новые файлы ядра не записались;
mkinitcpio завершается ошибкой записи, initramfs-linux.img не обновился: хук обновления прерывается;
grub-mkconfig не может перезаписать grub.cfg, новые ядра не попадают в меню;
после перезагрузки GRUB грузит старое ядро или уходит в rescue, потому что свежий vmlinuz доехал не до диска.

Отдельный признак для схемы «ESP в /boot»: grub-install тоже начинает падать с той же ошибкой, ведь ему некуда копировать модули.

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

Причина №1: старые ядра никто не удаляет за тебя. pacman при обновлении пакета linux оставляет предыдущие файлы, и комплекты складываются рядом. Порядок разбора этого сценария есть в статье «Чистка старых ядер и initramfs в Arch Linux».

Причина №2: размер. Полный комплект одного ядра весит около 400–500 МБ: само vmlinuz, обычный initramfs, fallback-образ и дерево модулей в /usr/lib/modules/<версия>. В схеме с отдельным /boot или ESP наружу выдаваются только образы (десятки мегабайт), зато модули оседают в корне. В схеме «/boot внутри корня» всё вместе.

Причина №3: несколько семейств сразу. Поставил linux + linux-lts ради запасного варианта: расход утроился. Добавь linux-zen для экспериментов, и корень потянет на пару гигабайт только модулями. Плюс в /var/cache/pacman/pkg продолжают копиться архивы старых версий пакетов.

Так что переполнение бывает разным: маленький /boot забивается образами ядер, а корень, деревьями модулей и кэшем. Лечатся обе беды по-разному.

Что показывает диагностика

Три команды, минута времени:

df -h /boot
ls -lh /boot
pacman -Q linux*

df -h /boot показывает занятость точки монтирования: если Use% близок к 100%, всё ясно. Запомни один нюанс: когда /boot просто каталог внутри корня, df выдаст статистику корневого раздела, и картина переполнения проявится уже по ls.

ls -lh /boot покажет, что именно лежит: несколько vmlinuz-* и initramfs-*.img, может быть старые grub.bak или забытые memtest86+. Каждый лишний комплект минус сотня мегабайт.

pacman -Q linux* перечислит установленные семейства ядер вместе с версиями. Этот запрос из семьи обычных запросов pacman: он перечисляет установленные пакеты по маске, и такие же маски работают в pacman -Rs. Сверь список с uname -r: текущее ядро оставляем, всё ненужное, кандидат на удаление.

Как освободить место, если /boot забит

Шаг 1: убери лишние семейства ядер через pacman. Не rm вручную, а именно pacman, чтобы удалились пакет, файлы и хуки:

sudo pacman -Rsn linux-zen

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

Шаг 2: подчисти кэш пакетов в корне. Команда paccache -rk1 оставляет только одну последнюю версию каждого пакета, архивы остальных уходят из /var/cache/pacman/pkg. Часто на этом экономятся сотни мегабайт корня, при этом откат через pacman -U из свежего архива остаётся доступным. Тонкости настройки в статье «Чистка кэша пакетов: paccache».

Шаг 3: если ESP смонтирован отдельным пунктом в /boot/efi. Загляни внутрь: там нередко откладываются старые EFI-записи Windows после переустановок и .efi-хвосты от прошлых загрузчиков. Каталог вида EFI/Microsoft на давно снесённой Windows занимает место понапрасну. Полный разбор этой зачистки в статье «EFI-раздел переполнен: чистка и рост».

Шаг 4: перегенерируй меню загрузчика. После освобождения места GRUB нужно обновить, чтобы исчезли записи удалённых ядер:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Проверь результат повторно: df -h /boot должен показывать запас хотя бы 30-40%, иначе следующее обновление ядра снова упрётся в стену.

Как не допустить переполнения снова

Держи максимум два ядра. Рабочее и запасное, например, linux и linux-lts. Четыре-пять семейств подряд не спасут от апокалипсиса, а место съедят всё.
Не выпиливай fallback вручную. Он входит в пакет ядра, весит немного и выручает после смены диска или контроллера. Оставляй комплект «ядро + fallback» целиком, но не плоди дубли комплектов.
Раз в месяц смотри на занятость. df -h /boot и ls -lh /boot отнимают пять секунд и показывают проблему за месяц до неё.
Заложи запас при разметке. Под UEFI нормальный ESP: 512 МБ и больше, отдельный /boot на BIOS от 500 МБ. Если раздел уже мелкий и расти некуда рядом, его пересоздают через gparted или parted с копированием содержимого; правки fstab и переустановка GRUB после такой операции обязательны.
Если корень маленький, меняй схему размещения. Перенос ESP в /efi с ядрами на корне снимает проблему переполненного /boot, но перекладывает ответственность на размер /. Перед таким переходом сначала оцени свободное место: df -h /.

Частые вопросы

Чем /boot отличается от EFI-раздела?

/boot: точка монтирования, которую ты выбираешь сам. На UEFI в неё часто монтируют ESP целиком, тогда каталог и раздел: одно и то же место. На BIOS бывает отдельный ext4-раздел, а бывает просто папка в корне. EFI-раздел при этом всегда FAT32 и всегда маленький.

Почему pacman падает с No space left on device, хотя df / показывает место?

Потому что df / смотрит на корень, а писать нужно в /boot. Когда это отдельный раздел или ESP, узкое место видно только из df -h /boot. Поэтому проверять надо точку монтирования, а не корень.

Можно ли удалить файлы старого ядра руками из /boot?

Технически можно, но pacman продолжит считать пакет установленным и при следующем обновлении вернёт всё на место. Правильный путь, pacman -Rsn <пакет>: так удалятся и файлы, и запись из системы пакетов.

Что делать, если переполнился корень, а /boot в порядке?

Сначала df -h / и pacman -Q linux*, посмотри, сколько семейств ядер сидит в системе. Затем paccache -rk1 для архивов и pacman -Rsn для лишних ядер. Если виновник не ядра, смотри, что ещё ест место: ncdu / разберётся быстрее всего.

Стоит ли увеличивать /boot или переехать на другую схему?

Если места мало, а расти вокруг нет, выгоднее переехать: ESP в /efi, ядра на корень. Если раздел растягивается соседним незанятым местом, увеличивай через gparted, это проще, чем миграция. Оба пути требуют правки fstab и перегенерации конфига GRUB.

Полезные ресурсы

EFI system partition, ArchWiki: требования к размеру, разметке и точкам монтирования ESP.
Pacman, Querying package lists: запросы pacman -Q для проверки установленных ядер.

Заключение

Переполнение /boot не поломка системы, а вопрос разметки и привычек. Выясни, где у тебя живёт каталог (findmnt /boot), замерь занятость (df -h /boot), посмотри, сколько ядер установлено (pacman -Q linux*), и убери лишние семейства через pacman -Rsn, подчистив кэш командой paccache -rk1. Два ядра вместо пяти, ежемесячная проверка df и запас на разделе при разметке, и тема переполненного /boot больше не вернётся. А если диск маленький по всей поверхности, глянь, как растить EFI-раздел, в статье про его чистку и увеличение.

Не получилось? Поможем настроить

Задай вопрос в чате — отвечаем быстро, по делу и без воды.

Telegram Max