Pasos esenciales para reparar un sistema Linux que no arranca

Cuando vienes de años de trastear con Windows y te pasas a una distro basada en Debian (Zorin, Ubuntu, Linux Mint, etc.), lo normal es que te preguntes qué hacer el día que, tras una actualización o un cambio de configuración, el sistema simplemente deja de arrancar. En Windows solemos tener clara la hoja de ruta: modo seguro, chkdsk, reparación automática, restaurar sistema y, si no hay más remedio, formateo y reinstalación.

En Linux la película es distinta: el sistema suele ser más robusto y recuperable, y antes de llegar al “borrón y cuenta nueva” casi siempre se puede rescatar el arranque desde un TTY, desde el modo recuperación o usando una distro Live. Eso sí, hay que conocer bien el orden de actuación para no perder el tiempo dando palos de ciego cuando estás con prisas y con el equipo “muerto” delante.

Por qué puede dejar de arrancar un sistema Linux

Lo primero es entender que, aunque Linux tenga fama de muy estable frente a Windows, no es infalible. La mayoría de problemas de arranque no se deben a que “Linux sea malo”, sino a una combinación de errores humanos, hardware tocado o configuraciones poco afortunadas.

Los fallos más habituales que impiden que tu distro levante son, en esencia, dos grandes bloques: problemas de disco/particiones y problemas de gestor de arranque (GRUB). A partir de ahí hay matices:

Partición de arranque dañada o inaccesible: la partición donde está instalado Linux o la partición /boot se ha corrompido, o la BIOS/UEFI no arranca desde el disco correcto.
Actualización de kernel fallida: el nuevo núcleo se ha instalado mal, no es compatible con tu hardware o has eliminado un kernel que seguía en uso.
Parche o actualización a medias: un corte de luz, apagar a lo bruto o un error al actualizar puede dejar paquetes a medio configurar y servicios esenciales sin arrancar.
Drivers problemáticos: aunque muchos controladores vengan integrados en el kernel, los drivers privativos (sobre todo de gráfica) pueden romper el arranque si algo va mal.
Dual boot con Windows: Windows puede reescribir el MBR/EFI y “comerse” GRUB, o Fast Boot/hibernación híbrida puede dejar el disco bloqueado.
Configuración de GRUB mal tocada: entradas erróneas, rutas a kernels que ya no existen o parámetros inadecuados.
Ajustes de BIOS/UEFI: arranque desde el disco equivocado, Secure Boot incompatible con tu distro o modos UEFI/Legacy mal elegidos.

En entornos con máquinas virtuales, a veces el problema es tan simple (y dramático) como que se ha borrado el directorio de la VM, con lo que ya no hay nada que arrancar ni que reparar.

Primera parada: descartar problemas de hardware

Antes de lanzarte a reparar el sistema como loco, conviene asegurarse de que no estás intentando arreglar por software un hardware roto. Un disco con sectores reasignados a mansalva o una RAM con errores va a seguir dando guerra aunque dejes el sistema “fino”.

El orden lógico es:

Comprobar en la BIOS/UEFI que el disco aparece: entra en el menú de firmware (Supr/Del, Esc, F2, F10, etc., según fabricante) y revisa el apartado de Boot/Arranque. Si el SSD/HDD donde está Linux no sale por ningún lado, o está fuera del orden de arranque, ahí tienes el primer problema.
Revisar el orden de arranque: asegúrate de que el disco con Linux (o la entrada correspondiente en UEFI) está antes que otros discos o dispositivos USB que puedan estar “pillando el turno”.

Si el disco sí se ve, toca evaluar la salud de la RAM y la unidad de almacenamiento:

1. Probar la memoria RAM con MemTest86+
Si al encender el equipo alcanzas GRUB, suele aparecer una entrada tipo “Memory test (memtest86+)”. Lánzala y deja el test al menos 8 pasadas completas. Si empiezan a salir líneas rojas, tienes errores en la RAM y lo más sensato es cambiar los módulos afectados.

2. Revisar el estado del disco con SMART
Para no tocar todavía tu Linux roto, puedes iniciar un Live USB de Ubuntu u otra distro y, una vez arrancado el entorno Live (desde RAM), instalar y usar smartmontools:

Valores críticos: Reallocated_Sector_Ct (sectores reasignados) y Current_Pending_Sector_Ct (sectores inestables).
Si cualquiera de los dos es mayor que 0, el disco ya está avisando de problemas serios. Cuanto más suban, más cerca estás del fallo definitivo.
El campo Power_On_Hours indica las horas de vida. Muchas horas no es igual a fallo inmediato, pero sí aumenta la probabilidad de avería.

Si el hardware canta, la prioridad es salvar datos y planificar un reemplazo. Si parece sano, seguimos por la ruta de software.

Identificar el origen del fallo de arranque en Linux

Una vez descartado (o controlado) el hardware, hay que localizar en qué punto se atasca el arranque. Aquí Linux da mucha ventaja respecto a Windows, porque casi siempre puedes conseguir algún tipo de consola o modo de recuperación desde donde meter mano.

Las dos herramientas clave para entender qué está pasando son el modo verbose de arranque y los ficheros de log del sistema.

Activar el arranque en modo “verbose”
Muchas distros muestran una animación o logo durante el arranque (el famoso “splash”), que queda muy bonito pero oculta mensajes de error importantes. La idea es que el kernel y systemd vayan mostrando en pantalla cada servicio que se carga y sepas dónde se queda pillado.

Cuando el sistema aún arranca (o consigues entrar en modo recuperación), puedes editar la configuración de GRUB en /etc/default/grub y modificar la línea:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

por una sin esos parámetros silenciosos:

GRUB_CMDLINE_LINUX_DEFAULT=""

Después ejecutas update-grub y, a partir del siguiente reinicio, verás todos los mensajes de arranque corriendo por pantalla, ideal para detectar el servicio o punto exacto en el que se cuelga.

Revisar los logs de sistema
Si ni siquiera ves bien los mensajes, o quieres algo más estructurado, tienes varios ficheros de log muy útiles. Desde una sesión normal, modo recuperación o una distro Live que monte tu disco, puedes ojear:

/var/log/boot.log: recoge los mensajes generados específicamente al arrancar. Es el primer sitio a revisar cuando el problema es claramente de “boot”.
/var/log/messages: registro general del sistema, con errores y avisos de distintos servicios.
dmesg: muestra los mensajes del kernel. Si el problema es del núcleo o del hardware, aquí suele aparecer bien claro.
journalctl: interfaz para leer el registro de systemd (Systemd Journal), con filtros, rangos de tiempo, etc.

Si el sistema no arranca, inicia un Live CD/USB, monta la partición raíz de tu Linux y entra en /var/log de esa partición para revisar todo esto con calma.

GRUB y arranque: reparar el gestor antes de tocar el sistema

GRUB es el pequeño programa que se carga justo después del firmware y que decide qué sistema operativo arrancar y con qué kernel. En instalaciones duales con Windows es muy habitual que, tras una actualización de Windows, el arranque vuelva a apuntar al cargador de Microsoft y GRUB “desaparezca” de la ecuación.

Hay dos casos típicos: GRUB aparece pero alguna entrada no arranca, o directamente GRUB ni se muestra y el equipo se va a otro sistema o a un error de arranque.

Acceder al menú de GRUB

Si tienes BIOS Legacy, durante el arranque pulsa y mantén Shift. Si es un sistema con UEFI, normalmente se usa Esc para que aparezca el menú de GRUB en lugar de entrar directo a la distro.

En ese menú podrás:

Elegir entre varios kernels de la misma distro (por ejemplo, una versión nueva y otra anterior).
Acceder a las “Opciones avanzadas” y, dentro, seleccionar el modo Recovery de un kernel concreto.
Elegir otra distro o Windows si tienes arranque dual.

Si al probar con un kernel anterior sí arranca, ya sabes que el problema ha venido con la actualización del núcleo. En muchos casos con volver temporalmente al kernel viejo te da margen para actualizar de nuevo o revisar el error con calma.

Cuando GRUB no aparece o está roto

Si la máquina arranca directamente a Windows, a un mensaje de “no hay sistema” o se queda en negro sin mostrar GRUB, es probable que el gestor de arranque esté dañado o que el MBR/EFI apunte a otro sitio. Aquí entra en juego un clásico: Boot-Repair.

La idea es arrancar con una distro Live (por ejemplo, Ubuntu o cualquier derivada), instalar Boot-Repair y dejar que rehaga el GRUB por ti:

Inicia desde el USB/CD en modo “Probar sin instalar”.
Abre una terminal y añade el PPA de Boot-Repair (en derivadas de Ubuntu) o instala el paquete correspondiente.
Ejecuta boot-repair con sudo.

La herramienta analiza los discos, detecta sistemas instalados y te propone una “Reparación recomendada” que suele bastar en la mayoría de casos: reinstala GRUB, reconfigura las entradas y asegura que el cargador se escriba en el disco correcto.

Si el problema es más fino (varios discos, varios Linux, orden de entrada, etc.), Boot-Repair permite entrar en opciones avanzadas: limpiar y restaurar GRUB, instalarlo en un disco concreto, editar parámetros, reparar el sistema de archivos e incluso restaurar el MBR.

Una vez aplicado, reinicias el PC y, si todo ha ido bien, deberías volver a ver un menú GRUB limpio con todas las entradas a sistemas detectados.

Usar el modo recuperación para reparar el sistema

Si GRUB funciona pero el sistema se cuelga al cargar servicios o al entrar al entorno gráfico, lo ideal es aprovechar el modo de recuperación (Recovery Mode) que traen la mayoría de distribuciones basadas en Debian/Ubuntu.

Desde el menú de GRUB, entra en “Opciones avanzadas para…” y selecciona la entrada que incluya (recovery mode) para el kernel que quieras usar (normalmente el más reciente, aunque también puedes probar con uno anterior).

Tras unos segundos, verás un menú con varias opciones de mantenimiento. Las más útiles para recuperar un sistema que no arranca son:

fsck: comprueba el sistema de archivos de la partición y repara errores. Es, salvando las distancias, el equivalente a chkdsk en Windows.
clean: elimina ficheros temporales y limpia espacio inutilizado. Útil si el sistema se quedaba sin espacio en disco.
dpkg: repara paquetes rotos o a medio configurar, reinstala dependencias necesarias y limpia estados colgantes tras una actualización fallida.
grub: actualiza y reescribe el cargador de arranque desde el propio sistema.
network: habilita la red, lo que permite actualizar paquetes o descargar correcciones si hace falta.
root: abre una shell como root, desde donde puedes tocar ficheros de configuración a mano, revisar logs o lanzar comandos avanzados.

Un recorrido típico cuando el sistema no pasa del arranque sería ejecutar, por este orden, fsck, dpkg y grub, comprobando que no hay errores graves y reiniciando después para ver si ya sube en modo normal.

Ajustes de BIOS/UEFI, Secure Boot y Fast Boot

En equipos modernos con UEFI hay dos elementos que interfieren con Linux con bastante frecuencia: Secure Boot y el Fast Boot de Windows. Si la distro no está preparada para Secure Boot o el firmware del equipo tiene un comportamiento un poco peculiar, puedes encontrarte con que simplemente no arranca el kernel.

En la mayoría de distros grandes actuales (Ubuntu, Debian, Fedora y muchas derivadas) el soporte de Secure Boot está bastante pulido, pero distribuciones más raras o muy ligeras pueden no funcionar con él activado.

Las medidas típicas a revisar en la UEFI son:

Probar a activar el modo Legacy o CSM si la distro no soporta del todo UEFI.
Desactivar Secure Boot temporalmente para comprobar si el bloqueo viene de ahí.
Comprobar que no hay opciones de “Fast Boot” en la propia UEFI que salten pasos clave del arranque.

En configuraciones de arranque dual con Windows, además hay que tener en cuenta el Inicio rápido (Fast Startup) de Windows: una especie de hibernación parcial que deja parte del kernel volcado en disco. Eso bloquea el acceso en condiciones a las particiones NTFS desde Linux, y en algunos equipos la BIOS puede “amarrar” el disco al arranque de Windows.

La solución pasa por:

Desactivar Fast Startup en las opciones de energía de Windows (desmarcando la opción de “Activar inicio rápido”).
Desactivar, si existe, el Fast Boot de la UEFI.

Ten en cuenta que desactivar Secure Boot no sienta bien a Windows 11 si compartes máquina, porque es uno de sus requisitos. En esos casos interesa usar una distro compatible con Secure Boot para no andar cambiando la configuración cada vez que quieras arrancar un sistema u otro.

Reparar particiones y sistemas de archivos con fdisk y fsck

Cuando el problema de arranque viene de una partición tocada (apagado brusco, corte de luz, errores de disco), una herramienta clave en Linux es fsck, que revisa y repara sistemas de archivos (y problemas de superblock). Suele combinarse con fdisk, que sirve para listar y gestionar particiones.

La manera habitual de proceder es arrancar el equipo desde un Live CD/USB para no montar la partición dañada en uso. Una vez en el entorno Live, abres un terminal y ejecutas:

fdisk -l

Con eso verás todas las particiones de todos los discos. Tienes que identificar cuál es la que contiene la instalación de Linux: en muchos casos será algo como /dev/sda1 (primera partición del primer disco), pero en equipos con varias unidades o EFI puede variar.

Cuando la tengas localizada, puedes lanzar fsck:

sudo fsck /dev/sda1

Este comando analiza el sistema de archivos, detecta inconsistencias y propone corregirlas. Normalmente irás respondiendo “yes” o “y” a las reparaciones que sugiera.

Advertencia importante: tanto fdisk como fsck pueden modificar de forma irreversible la estructura de particiones y los sistemas de archivos. Un uso inadecuado puede provocar pérdida total de datos. Antes de lanzarte, asegúrate de tener copia de seguridad de lo importante o, como mínimo, de identificar con total seguridad la partición correcta.

Errores initramfs y kernel panic: qué significan y cómo actuar

Hay dos tipos de fallos que asustan bastante al usuario medio pero que tienen explicación clara: los errores relacionados con initramfs y el famoso “kernel panic”.

Problemas con initramfs

initramfs es la “mini-imagen” que el sistema carga en memoria justo antes de montar el sistema de archivos real. Si se daña o si el sistema de archivos está roto, puedes acabar en una consola de recuperación con mensajes del tipo “initramfs” pidiéndote que ejecutes un fsck manual.

La forma típica de salir de este atolladero es:

Escribir exit en la consola para que el sistema indique qué partición necesita corrección.
Tomar nota del dispositivo (por ejemplo, /dev/sda2) y ejecutar un fsck manual sobre él siguiendo el formato que te sugiera en el mensaje.
Una vez que fsck termine y corrija todo lo que pueda, escribir reboot y cruzar los dedos para que arranque de nuevo.

Si el problema es solamente un sistema de archivos “sucio” por un apagado brusco, suele quedar resuelto sin necesidad de reinstalar.

¿Qué es un kernel panic?

Un kernel panic es, simplificando, el equivalente al pantallazo azul de Windows: el núcleo se encuentra con un error tan grave que no puede seguir funcionando y se detiene para evitar daños mayores. Puede deberse a drivers defectuosos, corrupción seria del sistema, fallos de hardware no manejados, etc.

La receta para abordarlo pasa por:

Probar a arrancar con otro kernel desde GRUB (por ejemplo, una versión anterior que antes funcionara bien).
Usar el modo Recovery para ejecutar fsck, dpkg y revisar los logs del kernel con dmesg y journalctl.
Si sospechas de un driver concreto (por ejemplo, un controlador gráfico privativo recién instalado), desactivarlo temporalmente o revertir la configuración desde la consola root.

En muchos casos, arrancar con un kernel anterior que sepas que iba fino es la forma más rápida de recuperar la máquina y, desde ahí, decidir si vuelves a actualizar el núcleo o te quedas en la versión estable que te funciona.

Casos especiales: máquinas virtuales y pérdida de la VM

Si utilizas Linux dentro de una máquina virtual (VirtualBox, VMware, etc.), hay un tipo de problema que no tiene solución técnica dentro del propio Linux invitado: que te hayas cargado el directorio de la VM creyendo que era “basura” porque ocupaba mucho.

Por defecto, en Windows las VMs se almacenan en rutas tipo:

VirtualBox: C:/Usuarios/tu_usuario/VirtualBox VMs/nombre_de_la_maquina
VMware: C:/Usuarios/tu_usuario/VMware/nombre_de_la_maquina

Si esos directorios desaparecen, lo que suele quedar es poco o nada que recuperar. A veces puedes sacarlos de la papelera si no eran demasiado grandes, pero lo normal es que se hayan borrado directamente. En ese caso, toca crear una nueva VM desde cero.

Para minimizar disgustos, conviene tener instaladas las Guest Additions (VirtualBox) o VMware Tools y guardar los documentos de trabajo en una carpeta compartida con el sistema anfitrión. Así, aunque la VM muera, los datos siguen accesibles en Windows u otro host.

Reinstalar Linux sin perder tus datos (y cómo prepararte para la próxima)

Llega un punto en el que, después de intentar todas las vías razonables, puede que tengas que asumir que reinstalar la distro es lo más rápido y limpio. Lo bueno es que muchas distribuciones permiten reinstalar el sistema manteniendo datos personales e incluso aplicaciones.

En versiones recientes de Ubuntu, por ejemplo, el instalador detecta que ya hay un sistema en el disco y ofrece la opción de reinstalar conservando tu carpeta personal. Aun así, siempre es recomendable, antes de tocar nada, arrancar con una distro Live y copiar a un disco externo todo lo importante, por si acaso.

Una estrategia muy recomendable para futuras emergencias es separar el sistema y los datos en distintas particiones desde el principio:

Una partición para / (sistema).
Otra (o varias) para /home o para los datos.
Opcionalmente, una partición /boot y/o EFI bien localizada.

Así, si un día hay que reinstalar recalibrando el sistema, puedes borrar y formatear únicamente las particiones de arranque y sistema, dejando intacta la de datos. Durante la instalación manual (opción “Más opciones” o similar en el asistente), asignas los puntos de montaje correspondientes sin marcar formato en la partición de datos.

Si todo falla, siempre quedará la opción de, desde un Live USB, montar la partición vieja y copiar los datos a un disco externo antes de formatear. Es más lento y aparatoso, pero suele salvar mucha información que, de otra forma, se perdería.