Cómo solucionar cuando Linux no arranca porque se llenó una partición

Cuando Linux deja de arrancar porque se ha llenado una partición (normalmente la raíz / o /boot), la sensación de pánico es total: no puedes iniciar sesión, algunos servicios se caen y parece que lo has roto todo. La parte buena es que en la mayoría de los casos no es necesario reinstalar; basta con liberar espacio de forma inteligente y, si hace falta, ajustar el tamaño de las particiones.

En este artículo vas a ver, paso a paso y con todo lujo de detalles, cómo identificar qué partición está llena, qué la está ocupando, cómo limpiar con seguridad y cuándo conviene ampliar o reestructurar el disco. Verás ejemplos prácticos con Debian, Ubuntu, Kubuntu, Linux Mint y servidores basados en Linux, además de consejos para evitar que vuelva a ocurrir.

Qué pasa cuando la partición raíz o /boot se llena

Cuando la partición root (la famosa /) o la partición /boot llegan al 100%, empiezan los síntomas raros: el sistema no escribe en /tmp, los escritorios gráficos fallan y es posible que, tras introducir tu contraseña, la sesión se cierre de inmediato y vuelvas a la pantalla de login. En entornos de servidor, servicios como Apache, el MTA de correo o los demonios de bases de datos dejan de funcionar correctamente.

Un caso típico en escritorio es ver un aviso del estilo «X session: warning: unable to write to /tmp; session may exit with an error» justo después de loguearte. Como el sistema no puede escribir archivos temporales, la sesión gráfica falla y te quedas atrapado en un bucle de inicio de sesión. En servidores, notarás que no puedes instalar paquetes, no se aplican actualizaciones y servicios esenciales se niegan a arrancar.

En configuraciones con doble arranque (por ejemplo, Windows + Ubuntu), y si necesitas liberar espacio desde Windows (particionar un disco duro en Windows), es frecuente que el usuario haya subestimado el tamaño de la partición de Linux: 15-20 GB parecen suficientes al principio, pero con actualizaciones del kernel, snaps, flatpaks, logs y copias de seguridad locales, esa partición termina reventando.

Síntomas típicos de una partición de Linux llena

Algunos indicios muy claros de que tu partición de sistema está al límite son los siguientes: el sistema se vuelve inestable, los servicios se paran sin motivo aparente, no se pueden instalar paquetes ni actualizar, y empiezan a aparecer errores de disco duro o de espacio insuficiente.

En servidores web puedes encontrar mensajes del tipo «no se puede reiniciar Apache», fallos continuos del servidor de correo al intentar descargar nuevos mensajes, o errores al escribir en bases de datos porque el sistema de archivos no acepta más datos. En escritorios con Linux Mint, Kubuntu o similares, lo habitual es el bucle de pantalla de inicio de sesión tras una actualización grande o varios meses sin limpiar nada.

Otro síntoma habitual es que no puedes instalar ni el paquete más pequeño desde el gestor de paquetes o desde la terminal: cualquier intento de instalar algo lanza un error de «No hay espacio en el dispositivo». Y, si el problema afecta a /boot, a veces la actualización del kernel se queda a medias y el sistema deja de arrancar correctamente, obligándote a usar modos de recuperación o un Live USB.

Cómo identificar qué partición está llena

Lo primero es confirmar qué se ha llenado exactamente. Para ello, desde una sesión de consola (un TTY con Ctrl+Alt+F2/F3) o arrancando desde una distro Live, ejecuta df -h. Este comando muestra de forma legible el uso de cada sistema de archivos montado.

Un resultado normal muestra algo como el tamaño total, el usado, el disponible y el porcentaje de uso para cada partición. Te interesa localizar líneas como /, /boot, /home, /var o cualquier otra que esté al 90-100% de uso. Por encima del 80% ya conviene revisar; por encima del 90%, la situación es crítica y hay que actuar cuanto antes.

Si gestionas un servidor con panel tipo Webmin, también puedes comprobar el estado del disco entrando en el módulo de particiones/almacenamiento. Pero en cualquier caso, la métrica clave es simple: porcentaje de uso de la partición afectada. Sin eso claro, vas a ir a ciegas.

En algunos equipos de escritorio verás que lo que está lleno no es la raíz sino /home, donde se acumulan archivos personales masivos (vídeos, máquinas virtuales, contenedores, etc.). La lógica de diagnóstico es la misma: primero detectas la partición saturada, luego bajas de nivel para descubrir qué directorios la están llenando.

Principales causas de que Linux no arranque por falta de espacio

Hay varias causas muy habituales que explican por qué de repente tu partición / o /boot está a rebosar. Algunas tienen que ver con malas decisiones de particionado, otras con programas tragones de disco y otras con simples olvidos de limpieza periódica.

Una razón típica en servidores es que se hacen copias de seguridad o se extraen archivos enormes directamente en / en lugar de almacenarlos en /home u otra partición de datos. También es común instalar software pesado (servidores de juego, motores 3D, enormes SDKs, etc.) bajo /usr o /opt, que cuelgan de la partición raíz y acaban devorando todo el espacio sin que nadie se dé cuenta.

Otra fuente frecuente de problemas son los logs que crecen sin control. Sistemas intensivos como servidores web, de correo, bases de datos o aplicaciones muy verbosas pueden llenarte /var/log en cuestión de días si no tienes rotación de logs bien configurada. En algunos casos concretos incluso hay bugs, como el de mod_gzip en Apache, que dejan ficheros temporales gigantes en /tmp sin limpiarlos jamás.

En escritorios modernos, tecnologías como Snap, Flatpak y Docker tienen mucha culpa: cada contenedor o paquete empaquetado incluye sus propias dependencias, lo que implica duplicar bibliotecas y ocupar gigas sin que parezca evidente. Si añades máquinas virtuales de VirtualBox o VMware más la caché de navegadores como Firefox y Chrome, el cóctel para llenar el disco está servido.

No hay que olvidar, además, el espacio reservado que usan sistemas de archivos como ext4 para el journaling y para el propio root. Aunque el usuario vea el disco al 100%, el sistema aún se reserva un pequeño porcentaje que, si se agota, puede provocar corrupción de datos o que servicios críticos no logren escribir nada.

Localizar qué directorios y archivos están ocupando el espacio

Una vez localizado el sistema de archivos afectado, hay que bajar un nivel y ver dónde se va realmente el espacio. Para eso, la herramienta clásica es du. Entra en la partición problemática, por ejemplo cd /, y ejecuta algo como du -chs * para obtener el tamaño de cada directorio de primer nivel de forma legible.

Con du -chs verás tanto el tamaño total como el de cada subdirectorio, y podrás seguir profundizando: si /var es enorme, entras y repites el comando allí; si el sospechoso es /home, haces lo mismo. De este modo vas acotando hasta localizar la carpeta o carpetas que realmente se están comiendo el disco.

Cuando lo que buscas son archivos individuales muy grandes dentro de un directorio concreto, una combinación muy cómoda es ls -lh --sort=size | head -n 5. Eso te lista los cinco archivos más pesados del directorio actual, con su tamaño en un formato amigable. Es una forma rápida de detectar ese archivo.log de varios gigas que lleva meses creciendo sin que nadie lo mire.

Si prefieres algo más interactivo, herramientas como ncdu (modo texto) o baobab (analizador gráfico de uso de disco) permiten navegar por el árbol de directorios y ver de un vistazo quién ocupa qué. En servidores y sistemas sin entorno gráfico, ncdu / es una maravilla para cazar culpables en pocos minutos.

En paralelo, para saber qué procesos están escribiendo de forma agresiva en el disco en ese momento, iotop resulta muy útil: muestra las operaciones de E/S en tiempo real y te puede chivar si un servicio concreto está generando logs o ficheros temporales sin parar.

Limpiar archivos grandes y directorios innecesarios con seguridad

Una vez identificados los archivos y carpetas que sobran, llega la parte delicada: eliminar o mover datos sin cargarte el sistema. La regla de oro es no borrar a ciegas nada que pertenezca claramente al sistema (binarios, bibliotecas, configuraciones críticas). Empieza siempre por archivos de usuario, copias de seguridad antiguas, logs gigantes o caches que sabes que se pueden regenerar.

Para borrar un archivo que no necesitas, puedes usar sin más rm nombre_de_archivo. Es un comando definitivo: lo que borres así no pasa por una papelera, desaparece del tirón, así que conviene revisar dos veces. Con logs enormes, una técnica menos agresiva es vaciarlos manteniendo el archivo: cat /dev/null > archivo.log. De este modo liberas espacio pero el fichero existe, lo que evita problemas con servicios que esperan encontrarlo.

Si quieres conservar el contenido de un log pero recuperar espacio, puedes comprimirlo y luego vaciarlo: por ejemplo, tar -czvf archivo.tar.gz archivo.log para generar un tar.gz y, después, cat /dev/null > archivo.log para dejar el log limpio. Esta práctica es común cuando vas a analizar registros históricos pero no puedes permitirte llenar el disco.

En directorios personales y de root, es bastante habitual encontrar archivos de instalación antiguos (.tar.gz, .rpm, .deb) que ya no tienen ninguna utilidad. Puedes moverlos a una partición con espacio, por ejemplo /home/archivos, con algo como mkdir -p /home/archivos && mv *.tar.gz *.rpm /home/archivos. Así descargas peso de / sin perder nada.

Un caso especial son los directorios temporales: /tmp y, en muchas distros, /var/tmp. En sistemas donde mod_gzip u otros servicios dejan ficheros temporales gigantes (por ejemplo, con extensión .wrk), puedes listarlos con ls -l /tmp/*.wrk y borrarlos con rm -rf /tmp/*.wrk. Eso sí, antes de hacer un rm -rf en /tmp piensa qué hay dentro: borrar a saco en producción sin mirar puede romper procesos en curso.

Limpiar una partición /boot llena en Debian y derivadas

Otro problema muy común es que la partición /boot se llene de kernels antiguos. Cada actualización del kernel deja ahí su paquete, y si no se limpian, en particiones pequeñas de 300-500 MB se acumulan rápido. Cuando /boot se queda sin espacio, las actualizaciones posteriores fallan y, en casos extremos, el sistema puede no arrancar.

En Debian y derivados (Ubuntu, Mint, etc.), la forma más sencilla de limpiar kernels viejos es usar apt --purge autoremove. Este comando elimina los kernels antiguos que ya no se están utilizando y otros paquetes instalados como dependencias que ya no son necesarios, borrando también sus archivos de configuración.

Antes de lanzarlo, es buena idea comprobar qué kernels tienes instalados y cuál estás usando con uname -r y algún dpkg -l | grep linux-image. Así te aseguras de que al menos dejas uno o dos kernels anteriores al actual por si hay que arrancar con una versión antigua desde GRUB.

Una vez limpio /boot, las actualizaciones de kernel vuelven a funcionar con normalidad y ese cuello de botella desaparece. A partir de ahí, conviene ejecutar periódicamente apt autoremove para que no vuelva a reventarse la partición con versiones obsoletas.

Logs, navegadores, snaps, flatpaks y Docker: los grandes tragones de disco

Más allá del sistema base, hay varias familias de aplicaciones que tienden a devorar espacio de forma silenciosa: los sistemas de logs, los navegadores, los nuevos sistemas de paquetes (Snap y Flatpak) y las plataformas de contenedores como Docker.

En cuanto a logs, cualquier servicio muy verboso (servidores web, de correo, bases de datos, aplicaciones corporativas) puede generar cientos de MB o varios GB de registros. Si no tienes rotación de logs (con herramientas como logrotate) o si la configuración tiene un nivel de detalle exagerado, tus /var/log pueden crecer sin freno.

Los navegadores como Firefox y Chrome almacenan en su caché de disco montones de archivos temporales: páginas, imágenes, vídeos, scripts… En Linux, las cachés suelen vivir en ~/.cache/mozilla/firefox/ y ~/.cache/google-chrome/. Si llevas años sin vaciarlas, te puedes encontrar varios gigas ocupados solo por eso.

Snap y Flatpak, por su parte, encapsulan las aplicaciones junto con casi todas sus dependencias, lo que implica duplicar bibliotecas que ya existen en el sistema. Cada app tiene su propio espacio en rutas como ~/.var/app/ (Flatpak) o /var/lib/snapd/snap/. Cuantas más apps tengas vía estos sistemas, más crecerá el consumo de la partición raíz.

Con Docker pasa algo parecido, pero a lo bestia: todas las imágenes, capas, contenedores y volúmenes suelen vivir en /var/lib/docker. Si no haces limpieza con comandos como docker system prune, docker image prune o docker volume prune, y dejas contenedores y volúmenes viejos pululando, en poco tiempo esa carpeta puede ocupar decenas o cientos de gigas.

Uso de logrotate y rotación de logs para evitar llenados

La gestión correcta de los logs es clave para no volver a quedarte sin espacio de forma silenciosa. En la mayoría de distros, logrotate se encarga de ir rotando, comprimiendo y borrando los registros viejos según la política que definas en /etc/logrotate.conf y en los ficheros de /etc/logrotate.d/.

Si quieres forzar una rotación inmediata, puedes usar logrotate -f /etc/logrotate.d/nombre_config, lo que obliga a aplicar la política definida para ese conjunto de logs: renombrar ficheros, crear otros nuevos, comprimir, etc. También puedes provocar una rotación simplemente reiniciando el servicio asociado o enviándole una señal (por ejemplo, kill -SIGUSR1 <PID>), aunque lo más robusto es usar la configuración de logrotate.

La idea es mantener un equilibrio: logs suficientes para auditar y depurar problemas, pero no eternos. Ajusta los tamaños máximos permitidos, el número de copias rotadas que guardas, si se comprimen o no, y cada cuánto se realiza la rotación (diaria, semanal, mensual…). Un ajuste correcto aquí ahorra muchos sustos.

Cuando limpiar no basta: ampliar o redistribuir particiones

Hay escenarios en los que, por mucho que limpies, la partición es sencillamente demasiado pequeña para tus necesidades. Por ejemplo, una raíz de 14-15 GB para una distro de escritorio moderna con snaps, flatpaks, Docker, compiladores y demás puede quedarse corta aunque seas ordenado.

En esos casos, hay que plantearse ampliar o redistribuir el espacio en disco. Si tienes otro sistema operativo en dual boot (por ejemplo, Windows) o una partición de datos sobredimensionada, puedes encoger esa partición para liberar espacio sin asignar y luego extender la partición de Linux que te interesa. Esto se suele hacer arrancando desde una Live ISO con herramientas de particionado como GParted o el gestor de particiones de KDE.

El proceso típico sería: desde el otro sistema o desde el Live, liberas sitio (borrando archivos o encogiendo particiones), después arrancas con una distro Live, abres el particionador y extiendes la partición raíz (o la que toque) para que absorba ese espacio libre. Cuando reinicies, si todo ha ido bien, Linux arrancará de nuevo con más gigas disponibles y menos riesgo de saturación futura.

En servidores, a veces es más sensato crear una nueva partición y mover allí datos pesados (por ejemplo /var/lib/docker, bases de datos, repos de copias de seguridad), montándola luego en el punto de montaje adecuado. En otros casos, se opta por añadir un segundo disco dedicado a datos y dejar el primero solo para el sistema.

Comprobar y reparar particiones dañadas (fdisk y fsck)

Hay ocasiones en las que no solo tienes falta de espacio, sino también errores en la partición o en el sistema de archivos. Un mal apagado con el disco lleno, problemas físicos en el disco o fallos de alimentación pueden dejar el sistema en un estado incoherente, y eso también impide arrancar con normalidad.

Para diagnosticar la estructura de particiones, puedes usar fdisk -l desde una distro Live o desde un entorno de rescate. Este comando lista todas las particiones detectadas en tus discos, con sus nombres de dispositivo (/dev/sda1, /dev/nvme0n1p2, etc.), tamaños y tipos. Así identificas con claridad dónde está instalado tu Linux original (a menudo, /dev/sda1 o similares).

Una vez localizada la partición de Linux, puedes usar fsck para buscar y corregir errores en el sistema de archivos: por ejemplo, sudo fsck /dev/sda1. Esta herramienta recorre la estructura y repara inconsistencias, bloques marcados mal, inodos corruptos, etc. Eso sí, hay que ejecutarla con la partición desmontada (o montada solo de lectura) para evitar desastres.

Conviene remarcar que fdisk y fsck no son juguetes: un uso incorrecto puede acabar en pérdida total de datos. Antes de tocar particiones o reparar sistemas de archivos, asegúrate de tener copia de seguridad de lo importante (por ejemplo, clonar discos duros con múltiples particiones), entender bien qué dispositivo estás manipulando y seguir los pasos con calma.

Conviene remarcar que fdisk y fsck no son juguetes: un uso incorrecto puede acabar en pérdida total de datos. Antes de tocar particiones o reparar sistemas de archivos, asegúrate de tener copia de seguridad de lo importante, entender bien qué dispositivo estás manipulando y seguir los pasos con calma.

Interacción con GRUB, UEFI, Secure Boot y modos de recuperación

Cuando Linux no arranca, no siempre es culpa exclusiva del espacio en disco. A veces el problema está en el gestor de arranque (GRUB), en la configuración UEFI/BIOS o en el propio kernel. En cualquier caso, estas piezas también influyen a la hora de poder entrar en modo de recuperación y arreglar los problemas de espacio.

Si llegas a ver el menú de GRUB, normalmente puedes acceder a las «Advanced options» y elegir otra versión de kernel o el modo «Recovery». En ese modo tienes a tu disposición utilidades como fsck, clean (para liberar espacio innecesario), dpkg (para reparar paquetes rotos) y grub (para regenerar el bootloader). A veces basta con ejecutar esas opciones para dejar el sistema lo bastante decente como para arrancar y continuar la limpieza desde dentro.

En equipos modernos con UEFI y Secure Boot, algunas distros requieren que desactives el arranque seguro o actives el modo Legacy para poder arrancar desde ciertas Live USB o distros menos conocidas. También conviene desactivar el «Fast Boot» tanto en UEFI como en Windows cuando compartes disco, porque puede bloquear el acceso a particiones y complicar la reparación.

Si el problema es que GRUB se ha roto (por ejemplo, tras una mala actualización de kernel o una reinstalación de Windows que se ha puesto por encima), tienes la opción de usar herramientas como Boot-Repair desde un Ubuntu Live: añadimos el PPA, instalamos la herramienta, la ejecutamos y dejamos que analice y repare el gestor de arranque, reinsertando GRUB y detectando los sistemas operativos.

En última instancia, si nada de esto funciona y los datos están a buen recaudo, siempre queda la carta de reinstalar la distribución. Algunas distros ofrecen ya en su asistente una opción de reinstalar manteniendo tus datos personales en /home e incluso muchas de tus aplicaciones. Si además tienes las particiones separadas (sistema, datos, arranque), el proceso resulta mucho menos traumático.

Buenas prácticas de particionado y prevención a largo plazo

Una forma muy efectiva de minimizar el impacto de un llenado de partición es planificar bien el particionado desde el principio. En muchos casos conviene separar, al menos, la raíz /, la partición de datos (/home o similar) y, si quieres afinar, /var y /boot. Así, si el sistema de logs se desmadra o alguien llena /home con vídeos 4K, el sistema base no se viene abajo.

Para una instalación típica de escritorio, una raíz de 20-30 GB suele ser una buena base si no vas a usar Docker de forma masiva ni cientos de flatpaks. /boot, si la usas separada, con 500 MB-1 GB basta en la mayoría de casos. La partición de intercambio (swap) puede ajustarse en función de tu RAM: igual a la RAM si tienes poca, menos si tienes mucha, o incluso usar un fichero de swap en lugar de una partición dedicada.

En servidores con Docker intensivo, quizá tenga sentido dedicar una partición específica a /var/lib/docker o a datos de bases de datos, de manera que los llenados se limiten a esa parte y no tiren todo el sistema. Igualmente, separar /var ayuda a aislar logs, colas de correo, caches de paquetes y otros elementos variables.

Además del diseño de particiones, es clave monitorizar el espacio de disco con cierta regularidad. Puedes usar herramientas de supervisión (Nagios, Zabbix, Prometheus, etc.) o scripts simples con df -h que envíen un correo o una alerta cuando una partición supere cierto umbral (por ejemplo, 80%). Lo importante es enterarte del problema antes de que el 100% te deje tirado.

Por último, acostumbrarte a limpiar periódicamente caches, snaps o flatpaks no usados, imágenes antiguas de Docker, cachés de navegador y kernels obsoletos es la mejor vacuna para que no se repita el drama de que Linux no inicie por una partición llena justo el día que más lo necesitas.

Si algo queda claro es que cuando una partición se llena en Linux el sistema puede comportarse de formas muy extrañas, pero con un poco de método —identificar qué partición está al límite, localizar los directorios culpables con df y du, limpiar primero lo innecesario, ajustar logs y paquetes pesados como snaps, flatpaks o contenedores, y, si hace falta, ampliar o reestructurar el disco— es perfectamente posible recuperar el arranque sin perder datos y dejar el equipo mejor preparado para aguantar muchos meses sin volver a sufrir un bloqueo por falta de espacio.