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 conserva los anteriores. Por eso, una partición /boot pequeña se llena y apt ya no puede completar una instalación. La reparación consta de dos pasos. Determine qué paquetes del sistema son kernels y cuál está en ejecución. Después, elimine los demás con apt autoremove --purge.

El orden es importante. No debe eliminar el paquete correspondiente al kernel en ejecución. Además, el sistema puede encontrarse en un estado en el que apt ya 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 crea 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 compilación falla y el paquete también queda en estado fallido.

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 lo que una imagen reciente puede llamarse zstd, mientras que una anterior puede llamarse 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 configurado parcialmente. 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). Esta es la consecuencia 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 no relacionada que intente realizar fallará con la misma línea, y la causa parecerá ser el componente que estaba añadiendo en ese momento. Por eso conviene leer una instalación de Tailscale que falla en Ubuntu primero 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 y nombra el sistema de archivos que contiene realmente /boot. Si ambos nombran 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 las posibles causas. En ese caso, sudo apt clean, que vacía 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 ningún espacio allí, porque la caché está en otro sistema de archivos.

Ahora obtenga el valor con el que va a 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 tanto, si Avail es menor que el initrd actual, la próxima actualización ya va a fallar.

Buscar 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á actualmente en memoria. Copie esa cadena en algún lugar. Es la única versión que no debe tocar.

El segundo archivo sólo existe cuando un paquete solicita reiniciar el sistema. Una línea linux-image en ese archivo indica que hay un kernel más reciente instalado en el disco pero no utilizado, 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 lo que limpiar mientras ejecuta un kernel antiguo deja fijada 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 que el paquete está instalado y configurado. iF significa que está instalado, pero configurado sólo parcialmente. Esto es exactamente lo que deja la actualización fallida anterior. rc significa que el paquete se eliminó, pero su configuración sigue en el disco. No ocupa espacio en /boot y se puede purgar de forma segura.

El segundo campo indica qué tipo de paquete es. Un nombre que contiene una versión, como linux-image-6.8.0-64-generic, corresponde a un kernel específico. Un nombre sin versión, como linux-image-generic, linux-headers-generic o linux-generic, corresponde a un metapaquete. No contiene ningún kernel. Su única función es depender del kernel con versión más reciente para que apt upgrade instale los kernels nuevos. Si elimina un metapaquete, la máquina deja de recibir actualizaciones del kernel y después no se muestra ninguna advertencia.

Las familias se dividen de la siguiente forma. 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 resto de una eliminación manual de archivos.

Cómo decide apt qué kernels conservar

apt autoremove no eliminará un kernel que considere protegido. El conjunto protegido incluye el kernel que está ejecutando ahora. La política de retención ha cambiado entre las versiones de Ubuntu. Por eso, consúltela en su propio equipo en lugar de confiar en un número anotado en otro lugar.

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 utiliza para identificar inicialmente los paquetes de kernel versionados. En las versiones que generan /etc/apt/apt.conf.d/01autoremove-kernels, /etc/kernel/postinst.d/apt-auto-removal reescribe ese archivo cada vez que se instala un paquete de kernel. Por tanto, editarlo manualmente no sirve: la siguiente instalación de un kernel sobrescribe los cambios. En las versiones en las que el archivo no existe, apt aplica la misma protección internamente. En ambos casos, apt-config dump muestra las reglas activas en su equipo. Esa salida es la respuesta correcta para su versión.

Limpieza 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. Revise la lista. Hay dos elementos 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 interrumpe 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 residual, 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 inexistente puede convertir un servidor operativo en uno que se detiene en el indicador de GRUB. Esta es una de las formas de terminar con un VPS que no arranca después de una actualización del kernel, y es mucho más difícil solucionarlo desde una consola de rescate que evitarlo 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 queda marcado 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. Vuelva a marcarlo como automático 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 metapaquetes marcados como manuales. Deben ser manuales porque son los paquetes que solicitó instalar.

Eliminar de forma intencionada 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 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 realizar cambios, porque linux-modules-extra-* depende del paquete de imagen y debe eliminarse en la misma transacción. Esa lista es su comprobación de seguridad real. Ahí puede detectar que se elimina un metapaquete junto con la versión que quería quitar. Responda n si contiene algún elemento inesperado. Después, ejecute sudo apt autoremove --purge para recopilar los paquetes de módulos y cabeceras que ya no tienen ninguna razón para permanecer instalados.

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

El kernel que ya está cargado en memoria sigue funcionando después de eliminar sus archivos, por lo que al principio no parece que nada falle. Lo que falla es todo lo que el kernel aún no ha cargado. La purga de 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, la recarga del firewall falla, al igual que el montaje de un tipo de sistema de archivos que este kernel no ha utilizado desde el arranque. Mientras tanto, /boot/vmlinuz-$(uname -r) ha desaparecido, por lo que el menú de arranque ya no ofrece 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. Compruebe 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 que dpkg termine primero de configurar el paquete del kernel que quedó configurado a medias. Ese paso vuelve a generar un initramfs y necesita espacio en un /boot que no tiene espacio disponible. 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 proporcionó 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 crea 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. Después, autoremove --purge elimina el paquete cuyo archivo eliminó, junto con las demás versiones antiguas. Así, dpkg vuelve a coincidir con el contenido del disco. update-grub vuelve a generar 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 informa de que está interrumpido, sudo dpkg --configure -a realiza la misma reparación que apt --fix-broken install.

El mismo trabajo en sistemas dnf

Si su VPS ejecuta Fedora o una de las reconstrucciones de RHEL, como Rocky Linux, el mecanismo es el inverso. Debian y Ubuntu protegen los kernels con reglas de autoremove de apt y dejan que usted o unattended-upgrades activen la limpieza, mientras 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 antiguos acumulados con sudo dnf remove --oldinstallonly. El kernel en ejecución también está protegido. Para consultar la correspondencia general entre ambos gestores de paquetes, consulte las equivalencias entre los comandos de dnf y apt.

Evite que vuelva a ocurrir

La limpieza que depende de que alguien la recuerde acabará 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 proporcionado 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. Por tanto, un duplicado hace que el archivo se contradiga y oculta qué valor está activo. 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 haya fallado por falta de espacio aparece allí mucho antes de que alguien advierta que la máquina no tiene instalados los últimos parches. El resto de esa configuración se explica en actualizaciones de seguridad automáticas en Ubuntu.

Antes de instalar el siguiente kernel, debe comprobar un valor. Es el mismo par de comandos del principio de esta guía:

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

Si Avail no es considerablemente mayor que ese archivo, el siguiente kernel fallará exactamente como se ha descrito arriba. Corríjalo ahora y no durante la actualización. Esta comprobación sólo requiere un minuto junto con las demás comprobaciones de estado del disco en un VPS. Es especialmente importante justo antes de una actualización de versión, porque actualizar Ubuntu 24.04 a 26.04 instala pronto un kernel nuevo durante el proceso y do-release-upgrade no continuará cuando /boot no tenga suficiente espacio.

FAQ

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

Porque un kernel que no arranca te deja sin ninguna otra opción para seleccionar. Conservar la versión anterior permite recuperar una actualización defectuosa desde el menú de GRUB, en lugar de hacerlo desde una 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. Ejecuta apt-config dump | grep -i neverautoremove para ver los patrones exactos que protege tu 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 leas primero la simulación. Ejecuta sudo apt autoremove --purge --dry-run, que no escribe nada, y revisa la lista mostrada. Detente si contiene un metapaquete como linux-generic o linux-image-generic, porque eliminar uno de ellos impide futuras actualizaciones del kernel. Detente también si contiene la cadena de versión que muestra uname -r. Si no aparece ninguno de los dos, 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. Ejecuta apt-mark showmanual | grep -E '^linux-'. Cualquier kernel con versión que aparezca allí se instaló manualmente en algún momento. Márcalo como automático con sudo apt-mark auto linux-image-<version> y vuelve a ejecutar la simulación, o elimina directamente esa versión con sudo apt purge linux-image-<version>.

¿Puedo eliminar manualmente los archivos de /boot?

Sólo como acción puntual y deliberada, cuando /boot está tan lleno que apt no puede configurar el paquete de kernel defectuoso. Elimina un único archivo initrd.img-<version> cuya versión no sea la que muestra uname -r y ejecuta inmediatamente sudo apt --fix-broken install, sudo apt autoremove --purge y sudo update-grub. Si eliminas archivos sin realizar estos pasos posteriores, dpkg seguirá registrando paquetes cuyos archivos ya no existen y las entradas del menú de GRUB seguirán apuntando a archivos ausentes. La máquina fallará en el siguiente reinicio, en lugar de hacerlo en el momento en que cometiste el error.