Eliminar kernels antiguos en Ubuntu y liberar /boot

Por qué apt deja de funcionar cuando /boot se llena de kernels antiguos

En Ubuntu, cada actualización del kernel escribe un nuevo conjunto de archivos en /boot y deja los anteriores en su lugar. Por eso, una partición /boot pequeña se llena y apt ya no puede completar una instalación. La reparación tiene dos pasos. Determine qué paquetes del sistema corresponden a kernels y con cuál inició el sistema. Después, elimine los demás con apt autoremove --purge.

El orden es importante. El kernel en ejecución es el único paquete que no debe eliminar. Además, el sistema puede estar ya en un estado en el que apt no pueda ejecutarse. Diagnostique primero.

Qué aspecto tiene realmente el fallo

Una versión del kernel instala dos archivos grandes en /boot: el kernel comprimido (vmlinuz-<version>) y el initramfs (sistema de archivos RAM inicial, initrd.img-<version>, el archivo pequeño que el kernel descomprime antes de montar la raíz real). El initramfs se genera en el equipo durante la instalación. Por eso, la instalación necesita espacio libre, no sólo ancho de banda para la descarga. Si no queda espacio, la generación falla y el paquete también queda afectado.

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

La cadena de versión será la de su sistema. El nombre del compresor procede de COMPRESS= en /etc/initramfs-tools/initramfs.conf. Por eso, una imagen reciente puede llamarse zstd, mientras que una más antigua se llama gzip. Las dos líneas que identifican este problema son No space left on device y la línea dpkg: error processing package que aparece debajo.

Después, el paquete queda parcialmente configurado. Cada ejecución posterior de apt intenta configurarlo de nuevo, falla de la misma forma y termina con E: Sub-process /usr/bin/dpkg returned an error code (1). Esto es lo importante más allá del espacio en disco: unattended-upgrades se ejecuta según su temporizador, encuentra el mismo error y se detiene. El servidor parece estar sano, pero deja de aplicar silenciosamente los parches de seguridad. Además, cualquier instalación independiente que intente realizar falla con esa misma línea, y la responsabilidad parece recaer en lo que estuviera añadiendo en ese momento. Por eso conviene leer primero una instalación de Tailscale que falla en Ubuntu como un error de apt. Si apt update falla antes de llegar a este punto, se trata de otro problema, a menudo una entrada duplicada después de la migración de fuentes a deb822.

Compruebe si /boot es una partición independiente

Antes de eliminar nada, averigüe qué espacio está liberando realmente.

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

El primer comando muestra una línea sólo si /boot es su propio punto de montaje. El segundo siempre muestra una línea e indica el sistema de archivos que contiene realmente /boot. Si ambos indican el mismo sistema de archivos que /, /boot es sólo un directorio del sistema de archivos raíz y no puede llenarse por separado: el sistema de archivos raíz está lleno, y los kernels antiguos son sólo una de varias causas. En ese caso, sudo apt clean, que elimina los archivos .deb descargados en /var/cache/apt/archives, libera espacio. En una máquina con una partición /boot real, apt clean no libera espacio allí, porque la caché está en otro sistema de archivos.

Ahora obtenga el valor con el que trabajará.

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

Compare la columna Avail con el tamaño de esos dos archivos. El initrd es el más grande. La próxima actualización del kernel necesita espacio para otro par de aproximadamente ese tamaño, por lo que si Avail es menor que el initrd actual, la próxima actualización ya va a fallar.

Identifique el kernel en ejecución

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

uname -r muestra la cadena de versión del kernel que está cargado actualmente en memoria. Copie esa cadena en algún lugar. Es la única versión que no debe eliminar.

El segundo archivo sólo existe cuando un paquete solicita reiniciar el sistema. Una línea linux-image indica que hay un kernel más reciente instalado en disco, pero que no se está utilizando porque la máquina no se ha reiniciado desde su instalación. Si es posible, reinicie antes de limpiar. apt protege el kernel en ejecución y el más reciente. Por tanto, si limpia mientras ejecuta un kernel antiguo, se conservará una versión adicional que no necesita.

Enumere los paquetes del kernel y consulte sus estados

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

El primer campo es el código de estado de dpkg. ii significa instalado y configurado. iF significa instalado, pero con la configuración incompleta, que es exactamente lo que deja la actualización fallida anterior. rc significa eliminado, pero con su configuración aún en el disco. No ocupa espacio en /boot y se puede purgar sin riesgos.

El segundo campo indica qué tipo de paquete es. Un nombre que incluye una versión, como linux-image-6.8.0-64-generic, identifica un kernel concreto. Un nombre sin versión, como linux-image-generic, linux-headers-generic o linux-generic, corresponde a un meta paquete. No contiene ningún kernel. Su única función es depender de la versión más reciente del kernel para que apt upgrade instale nuevos kernels. Si elimina un meta paquete, el equipo deja de recibir actualizaciones del kernel y no se muestra ningún aviso posterior.

Las familias se dividen de la siguiente manera. linux-image-* contiene la imagen comprimida del kernel en /boot. linux-modules-* y linux-modules-extra-* contienen los controladores en /lib/modules. linux-headers-* contiene las cabeceras de compilación en /usr/src. Por tanto, purgar las cabeceras libera espacio en el sistema de archivos raíz, no espacio en /boot. Si el problema es una partición /boot llena, debe buscar los paquetes de imágenes.

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

Estas dos listas deberían coincidir entre sí y con la salida de dpkg --list. Un directorio en /lib/modules que no tenga ningún paquete instalado correspondiente es un residuo que quedó después de eliminar archivos manualmente.

Cómo decide apt qué kernels conservar

apt autoremove no elimina un kernel que considera protegido, y el conjunto protegido incluye el kernel que está ejecutando ahora. La política de retención ha cambiado entre versiones de Ubuntu, así que consúltela en su propio equipo en lugar de confiar en un número escrito en otro sitio.

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 es la lista de patrones de nombres de paquetes que apt autoremove se niega a modificar. APT::VersionedKernelPackages es la lista de prefijos de nombres que apt trata inicialmente como paquetes de kernel versionados. En las versiones que generan /etc/apt/apt.conf.d/01autoremove-kernels, /etc/kernel/postinst.d/apt-auto-removal vuelve a escribir ese archivo cada vez que se instala un paquete de kernel, por lo que editarlo manualmente no sirve: la siguiente instalación de un kernel sobrescribe los cambios. En las versiones en las que falta el archivo, apt aplica internamente la misma protección. En cualquier caso, apt-config dump muestra las reglas activas en su equipo, y esa salida es la respuesta correcta para su versión.

La limpieza que es segura de ejecutar

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

--dry-run no cambia nada en el disco e imprime exactamente lo que eliminaría la ejecución real. Lea la lista. Hay dos situaciones que deben hacerle detenerse. Un metapaquete como linux-generic o linux-image-generic en la lista de eliminación significa que algo lo marcó como automático, y eliminarlo detiene las actualizaciones del kernel. La cadena de uname -r en la lista de eliminación significa que el kernel en ejecución no está protegido. Esto no debería ocurrir y debe investigarse antes de continuar.

Si la lista es correcta, ejecútelo de verdad.

sudo apt autoremove --purge
df -h /boot

La opción --purge también elimina la configuración restante, además del paquete. Libera poco espacio adicional y evita que dpkg --list acumule líneas rc, lo que facilita la siguiente auditoría.

Después, confirme que se haya reconstruido el menú de arranque. Al eliminar un paquete del kernel se ejecuta update-grub automáticamente, por lo que el menú sólo debería hacer referencia a archivos que todavía existan.

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

Cada versión de la primera salida debe aparecer en la segunda. Una entrada del menú que apunte a un archivo que ya no existe puede hacer que un servidor operativo se detenga en el indicador de GRUB. Esta es una de las causas de un VPS que no arranca después de una actualización del kernel, y es mucho más difícil corregirla desde una consola de rescate que evitarla aquí.

Por qué apt autoremove a veces no elimina nada

apt autoremove sólo elimina paquetes marcados como automáticos, es decir, paquetes instalados como dependencia de otro paquete. Un kernel que instaló manualmente con apt install linux-image-6.8.0-40-generic se marca como manual, y autoremove nunca lo eliminará, por antiguo que sea.

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

Cualquier kernel con versión que aparezca en esa salida es invisible para autoremove. Márquelo de nuevo como manual usando las cadenas de versión de su propia lista:

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

Deje los meta paquetes marcados como manuales. Deben ser manuales porque son los paquetes que solicitó.

Eliminar intencionadamente un kernel concreto

A veces necesita eliminar una versión concreta de inmediato, en lugar de esperar a que la política lo permita. Indique el paquete de la imagen y deje que apt resuelva el resto.

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

apt muestra una lista de eliminación antes de hacer nada, porque linux-modules-extra-* depende del paquete de la imagen y debe eliminarse en la misma transacción. Esa lista es su comprobación de seguridad real. Revísela para detectar si se va a eliminar un metapaquete junto con la versión que quería quitar. Responda n si contiene algún elemento inesperado. Después, use sudo apt autoremove --purge para recopilar los paquetes de módulos y encabezados que ya no tienen ninguna dependencia que justifique su existencia.

Por qué nunca debe eliminar el kernel en ejecución

El kernel que ya está en memoria sigue ejecutándose después de eliminar sus archivos, por lo que al principio no parece que nada falle. El problema afecta a todo lo que el kernel todavía no haya cargado. Purgar linux-modules-$(uname -r) elimina /lib/modules/$(uname -r)/, por lo que la siguiente carga de módulos falla:

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

A partir de ese momento falla la recarga del firewall y también el montaje de un tipo de sistema de archivos que este kernel no haya utilizado desde el arranque. Además, /boot/vmlinuz-$(uname -r) ya no existe, por lo que el menú de arranque deja de ofrecer el kernel en ejecución y el siguiente reinicio inicia otro kernel. La máquina sigue atendiendo tráfico, pero ya no se puede arrancar. Compare uname -r con la lista de elementos que se van a eliminar cada vez.

Cuando /boot está demasiado lleno para que apt se ejecute

Este es el estado que lleva a buscar esta página. apt autoremove necesita dpkg para terminar de configurar primero el paquete del kernel que quedó configurado a medias, y ese paso vuelve a generar un initramfs, que necesita espacio en un /boot que no tiene ninguno. Rompa el ciclo manualmente, una sola vez.

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

Elija un initrd cuya versión no sea la cadena que le mostró uname -r y elimine sólo ese archivo.

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

Cada línea tiene un motivo. rm es una excepción deliberada que hace que dpkg siga creyendo que existe un archivo cuando en realidad no existe. apt --fix-broken install completa la configuración que falló, ahora que hay espacio para el initramfs. A continuación, autoremove --purge elimina el paquete cuyo archivo borró junto con las demás versiones antiguas, lo que vuelve a sincronizar dpkg con el contenido del disco. update-grub reconstruye el menú a partir de los archivos que realmente existen. No reinicie entre rm y update-grub, porque durante ese intervalo el menú todavía puede apuntar al archivo que acaba de eliminar. Si dpkg indica que está interrumpido, sudo dpkg --configure -a realiza la misma reparación que apt --fix-broken install.

El mismo trabajo en sistemas con dnf

Si su VPS ejecuta Fedora o una de las reconstrucciones de RHEL, como Rocky Linux, el mecanismo es diferente. Debian y Ubuntu protegen los kernels con reglas de autoremove de apt y dejan que usted o unattended-upgrades ejecuten la limpieza, mientras que dnf aplica un límite llamado installonly_limit y elimina automáticamente el kernel más antiguo cuando una instalación nueva supera ese límite. Consulte el valor vigente con grep installonly_limit /etc/dnf/dnf.conf y man 5 dnf.conf, y elimine los kernels acumulados con sudo dnf remove --oldinstallonly. El kernel en ejecución también está protegido. Para consultar la correspondencia más amplia entre ambos gestores de paquetes, consulte las equivalencias de comandos entre dnf y apt.

Evite que vuelva a ocurrir

La limpieza que depende de que alguien la recuerde terminará fallando. Por eso, configúrela en el componente que instala los kernels. Abra /etc/apt/apt.conf.d/50unattended-upgrades y busque estas claves. El archivo distribuido ya las incluye como líneas comentadas:

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

Quite los comentarios en lugar de añadir una segunda copia al final. En la configuración de apt, prevalece la última asignación de una clave. Una clave duplicada hace que el archivo se contradiga y oculta cuál es el valor efectivo. Compruebe el resultado del análisis y supervise una ejecución que no cambie nada:

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

El registro es la prueba. Registra cada ejecución. Por eso, una actualización que falló por falta de espacio aparece allí mucho antes de que alguien advierta que el equipo está atrasado con los parches. El resto de esa configuración se explica en las actualizaciones de seguridad automáticas en Ubuntu.

Antes de que se instale el siguiente kernel, debe comprobar un valor. Es el mismo par de comandos del inicio de esta guía:

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

Si Avail no es claramente mayor que ese archivo, el siguiente kernel fallará exactamente como se describió anteriormente. Corríjalo ahora, no durante la actualización. Esta comprobación requiere un minuto y complementa las demás comprobaciones del estado del disco en un VPS. Es especialmente importante justo antes de una actualización de versión, porque pasar Ubuntu 24.04 a 26.04 instala un kernel nuevo al principio del proceso. do-release-upgrade no continuará si /boot no tiene suficiente espacio. Si su servidor LTS todavía no ha recibido esa actualización, se debe al calendario y no a un fallo. Ubuntu retrasa las actualizaciones entre versiones LTS hasta que se publique la versión 26.04.1, lo que le proporciona un plazo conocido para preparar /boot.

FAQ

¿Por qué Ubuntu conserva los kernels antiguos en lugar de eliminarlos?

Porque un kernel que no arranca no deja ninguna otra opción para seleccionar. Conservar la versión anterior permite recuperar el sistema desde el menú de GRUB si una actualización falla, en lugar de usar la consola de rescate del proveedor. apt protege por tanto un conjunto de paquetes de kernel frente a la eliminación automática e incluye siempre el que está en ejecución. Ejecute apt-config dump | grep -i neverautoremove para ver los patrones exactos que protege su versión, ya que la política ha cambiado entre versiones.

¿Es seguro ejecutar apt autoremove --purge en un servidor de producción?

Sí, siempre que revise primero la ejecución de prueba. Ejecute sudo apt autoremove --purge --dry-run, que no escribe nada, y compruebe la lista mostrada. Deténgase si contiene un metapaquete como linux-generic o linux-image-generic, porque eliminar uno de ellos impide futuras actualizaciones del kernel. Deténgase también si contiene la cadena de versión que muestra uname -r. Si no aparece ninguna de las dos cosas, los paquetes que se eliminarán son kernels antiguos y dependencias huérfanas.

apt autoremove no eliminó nada y /boot sigue lleno. ¿Qué hago ahora?

Casi con toda seguridad, los kernels antiguos están marcados como instalados manualmente, y autoremove sólo afecta a los paquetes marcados como automáticos. Ejecute apt-mark showmanual | grep -E '^linux-'. Cualquier kernel con versión que aparezca en esa lista se instaló manualmente en algún momento. Márquelo como automático con sudo apt-mark auto linux-image-<version> y vuelva a ejecutar la prueba, o elimine directamente esa versión con sudo apt purge linux-image-<version>.

¿Puedo eliminar manualmente los archivos de /boot?

Sólo como medida puntual y deliberada, cuando /boot está tan lleno que apt no puede configurar el paquete de kernel con errores. Elimine un único archivo initrd.img-<version> cuya versión no sea la que muestra uname -r y ejecute inmediatamente sudo apt --fix-broken install, sudo apt autoremove --purge y sudo update-grub. Eliminar archivos sin realizar esos pasos posteriores deja a dpkg registrando paquetes cuyos archivos ya no existen y deja entradas del menú de GRUB que apuntan a archivos ausentes. La máquina fallará en el siguiente reinicio, en lugar de hacerlo en el momento en que se cometió el error.