Diagnóstico de problemas de arranque en Linux y fallos de hardware

Informatec Digital » Recursos » Diagnóstico de problemas de arranque en Linux y fallos de hardware

Cuando un sistema Linux deja de arrancar o empieza a comportarse de forma rara, lo normal es pensar que “Linux se ha roto”. En la práctica, la mayoría de las veces lo que hay detrás son errores de configuración, discos llenos, corrupción del sistema de archivos o problemas de hardware que se pueden localizar con un poco de método. La idea de este artículo es precisamente esa: mostrar un procedimiento claro, apoyado en comandos concretos, para diagnosticar y reparar los problemas de arranque y de hardware más habituales en Linux, tanto en máquinas físicas como en máquinas virtuales.

Si te encuentras con mensajes como “no se encuentra el sistema de archivos raíz”, “No space left on device”, “EXT4-fs error”, “XFS: Metadata CRC error” o un temido Kernel Panic, aquí vas a ver cómo interpretarlos, qué comandos usar y en qué orden actuar. También veremos cómo comprobar si el marrón viene realmente del software o si es el hardware (RAM, SSD/HDD, tarjeta de red, etc.) el que está pidiendo la jubilación, y cómo minimizar el riesgo de perder datos mientras trasteas.

Causas típicas de problemas de arranque en Linux

Antes de liarte a tocar cosas sin ton ni son, conviene tener claro cuáles son las causas más frecuentes de que Linux no arranque o arranque mal. Entender el origen te evita perder horas probando soluciones que no van a ningún lado.

Un primer grupo de problemas viene del gestor de arranque y la configuración de la BIOS/UEFI: entradas de GRUB mal generadas, MBR sobrescrito tras instalar Windows en dual boot, Secure Boot incompatible con tu distro o la BIOS intentando arrancar desde el disco equivocado. En estos casos suele pasar que ni siquiera ves el menú de GRUB o que, al elegir tu Linux, se queda colgado o vuelve al firmware.

Otro bloque importante tiene que ver con el disco y el sistema de archivos: particiones dañadas, sectores defectuosos, corrupción de EXT4 o XFS, discos del sistema llenos o errores de LVM. Esto suele manifestarse con mensajes durante el arranque del tipo “Failed to mount /…”, “EXT4-fs error”, “XFS: Unmount and run xfs_repair” o incluso acabar en modo de emergencia pidiéndote que ejecutes journalctl -xb.

También son muy frecuentes los problemas tras una actualización de kernel o un parche mal aplicado. Descargas incompletas, módulos no cargados, drivers que dejan de ser compatibles con tu hardware o cambios en el initramfs pueden provocar que el sistema se quede bloqueado a mitad de arranque o que aparezca un Kernel Panic nada más iniciar.

No hay que olvidar el apartado de la configuración del propio sistema: reglas de arranque seguro demasiado estrictas (por ejemplo auditd configurado con HALT cuando /var/log/audit se llena), servicios críticos que fallan por falta de espacio, o cambios en ficheros de configuración que impiden levantar demonios esenciales (red, systemd, cloud-init en nubes como Azure, etc.).

Por último, está la capa de hardware: discos con SMART rojo, RAM con errores ECC, tarjetas de red que pierden paquetes o SSD que se calientan demasiado. Muchas veces la pista está en los mensajes del kernel (dmesg) o en los contadores SMART y EDAC, así que veremos cómo leerlos con calma.

Cómo identificar el origen del fallo de arranque

La clave para no ir a ciegas es activar el modo detallado de arranque y revisar los logs. Por defecto muchas distros muestran un splash bonito que tapa los mensajes, lo cual queda muy aparente pero no ayuda nada cuando algo va mal.

En sistemas con GRUB puedes desactivar el modo silencioso editando /etc/default/grub. Busca la línea:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

y cámbiala por:

GRUB_CMDLINE_LINUX_DEFAULT=""

Después ejecuta update-grub (o el comando equivalente en tu distro) para que se regenere la configuración. En el siguiente arranque verás desfilar todos los mensajes del kernel y de systemd, lo que permite detectar en qué punto y con qué error exacto se para el sistema.

Si el sistema llega a arrancar parcialmente o puedes acceder desde un Live, tendrás a mano varios logs clave en /var/log:

• /var/log/boot.log: registra todo lo que ocurre durante la fase de arranque; si el fallo está en esta etapa, es el primer sitio donde mirar.
• /var/log/messages o /var/log/syslog (según distro): eventos generales del sistema, muy útiles para ver errores de servicios, demonios, etc.
• dmesg: muestra los mensajes del kernel, incluidos fallos de hardware, problemas de módulos, errores en buses, PCI, etc.
• journalctl: en sistemas con systemd, es la herramienta base para recorrer el registro completo; con journalctl -xb ves el último arranque con todo lujo de detalles.

Si el sistema no llega al escritorio pero sí a un TTY o modo de recuperación, puedes ejecutar journalctl -xb directamente desde ahí. Si ni eso, te toca iniciar con un Live USB, montar el disco del sistema y leer esos ficheros desde el entorno en vivo.

Comprobar si el problema es de hardware o de software

Antes de romperte la cabeza editando configuraciones, conviene asegurarse de si lo que falla no es directamente el hardware: disco, memoria, CPU, placa o fuente. Muchas instalaciones que se corrompen de forma “aleatoria” en realidad están delatando un SSD que empieza a morirse o una RAM con errores.

El primer paso, si el equipo ni siquiera reconoce el disco, es entrar en la BIOS/UEFI y confirmar que la unidad aparece listada. Si el disco no sale por ningún lado, o sale de forma intermitente, revisa conexiones, cables SATA y alimentación, o asume que el disco puede estar ya para reciclar.

Si llegas al GRUB o a un Live, puedes lanzar MemTest86+ desde el propio menú de GRUB para verificar la RAM. Déjalo correr al menos 8 pasadas; si ves líneas rojas, esa memoria está dañada y hay que sustituir módulos. Una RAM con fallos es una fábrica de corrupción de datos.

Para comprobar el estado de los discos en Linux, la referencia es smartmontools. Tras instalarlo, activa SMART y revisa los atributos más sensibles:

• Reallocated_Sector_Ct: número de sectores reasignados; si es mayor que 0, ese disco ya ha empezado a tener sectores malos.
• Current_Pending_Sector_Ct: sectores pendientes de reasignar; cualquier valor mayor que 0 indica riesgo alto de fallo inminente.
• Power_On_Hours: horas de uso acumuladas; cuanto más alto, más probabilidades de que el disco casque.

Con smartctl -H /dev/sdX puedes ver de forma rápida si el disco “pasa” o “no pasa” el test de salud. Si el resultado no es PASSED, toca hacer copia de seguridad cuanto antes y pensar en reemplazo.

Si sospechas de temperaturas elevadas, instala lm-sensors y ejecuta sensors (o watch -n 2 sensors para verlo en tiempo real). Para SSDs y discos SATA, hddtemp te muestra la temperatura actual, y así puedes detectar unidades que se disparan de grados incluso en reposo, útil para la optimización de servidores.

Diagnóstico especializado de hardware en Linux

Además de CPU, RAM y disco, Linux tiene herramientas específicas para evaluar memoria ECC, tarjetas de red, GPU y otros componentes. Dedicar unos minutos a revisar estos puntos te puede ahorrar muchas horas de debug.

Si tu servidor o estación de trabajo tiene memoria ECC, el kernel suele registrar los errores corregidos o no corregidos mediante EDAC. Un simple:

dmesg | grep EDAC

te permite ver si hay CE (Corrected Error) o UE (Uncorrected Error). Los CE indican que la RAM ha tenido fallos pero el hardware ha podido corregirlos; conviene vigilar esos módulos porque normalmente es cuestión de tiempo que pasen a errores no corregibles. Los UE suelen terminar en Kernel Panic para evitar corrupción grave de datos.

Para revisar la estructura y capacidad de la memoria, dmidecode -t memory te enseña el tipo de módulos (DDR3, DDR4, DDR5), capacidades, bancos ocupados y demás. Y con dmidecode -t 16 puedes ver la capacidad máxima de RAM que soporta la placa, algo útil si estás pensando en ampliarla.

En el terreno de la temperatura y monitorización visual, puedes apoyar los datos de sensors y hddtemp con herramientas gráficas como psensor o xsensors, que trazan la temperatura en el tiempo para detectar picos raros o equipos que van perpetuamente al límite de calor.

Para el diagnóstico de discos y memorias USB, además de lsblk y fdisk -l para listar dispositivos, es muy útil combinar:

• df -h y df -i: porcentaje de uso de espacio y de inodos; puedes tener gigas libres pero 100% de inodos ocupados y el sistema se seguirá quejando de “no hay espacio”.
• fsck /dev/sdXN -y: busca y repara errores lógicos en sistemas de archivos (EXT2/3/4, entre otros).
• badblocks /dev/mi_disco: escanea sectores defectuosos y los marca para que el sistema no los use (muy recomendable hacer copia de seguridad antes de esto).

En el caso de la tarjeta de red, los síntomas típicos son desconexiones, latencias o pérdidas de paquetes inexplicables. Con ethtool puedes revisar estadísticas y con netstat -ni comprobar tasas de paquetes perdidos (RX-DRP y TX-DRP). Si el porcentaje de pérdidas supera aproximadamente 0,2%, el rendimiento de red se resiente claramente y puede ser que la NIC esté defectuosa o mal soportada por el driver.

Disco lleno y errores de espacio: el clásico “No space left on device”

En muchas máquinas (especialmente en servidores y máquinas virtuales) uno de los problemas más recurrentes es que el disco del sistema se llena completamente. Cuando eso pasa, empiezan a fallar servicios, logs, el arranque e incluso el propio kernel lanza errores de E/S.

En entornos como Azure es habitual ver en consola o en los diagnósticos de arranque mensajes tipo:

• No space left on device en cloud-init, lo que puede impedir que la VM termine de arrancar.
• Mensajes repetidos de “No queda espacio en el dispositivo” que afectan a servicios críticos, incluyendo el agente de la nube.
• Errores en los logs del sistema indicando que no se pueden escribir registros de auditoría o de red.

Para localizar rápidamente qué está ocupando el espacio, puedes usar comandos como:

• du -ks /* | sort -n: lista los directorios de la raíz ordenados por tamaño; repite dentro de los más pesados hasta encontrar el verdadero culpable.
• ls -altSr /var/log: muestra los ficheros de log ordenados por tamaño, del menor al mayor; muchas veces verás logs antiguos enormes que se pueden rotar o eliminar.
• find / -size +500M -exec ls -alFh {} \;: busca archivos individuales grandes; ajusta ese 500M según te convenga.

Además del típico llenazo de /var/log o /tmp, hay configuraciones de seguridad como auditd que pueden provocar que una máquina se apague o no arranque cuando se queda sin espacio en /var/log/audit. Si en /etc/audit/auditd.conf tienes:

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

el sistema puede apagarse de forma controlada o negarse a arrancar si no puede escribir en los logs de auditoría. Una solución temporal es cambiar esos valores a SUSPEND, IGNORE u otras opciones válidas (nunca SINGLE en este contexto) para permitir que el sistema arranque y puedas liberar espacio. Después de solucionar el problema, deberías volver a la política original si la necesitas por cumplimiento.

Cuando no hay manera de borrar cosas porque literalmente el sistema no arranca, puedes recurrir a modos de rescate: comando de reparación automática de la nube (por ejemplo az vm repair en Azure), máquina virtual de recuperación o modo de usuario único para montar el disco y eliminar archivos innecesarios hasta dejar al menos un 10% de espacio libre en el sistema de archivos que aloja /var/log y el resto de directorios críticos.

Corruptelas en EXT4 y XFS: cómo reparar sistemas de archivos dañados

Si en el arranque ves cosas como “EXT4-fs error (device sda1)”, “bad extra_isize”, “no journal found” o mensajes de XFS del tipo “Metadata CRC error detected… Unmount and run xfs_repair”, no estás ante algo puntual: el sistema de archivos está corrupto y hasta que no lo repares, la máquina no va a arrancar con normalidad.

Lo primero es identificar qué dispositivo está afectado. En los logs de arranque, fíjate en el texto que aparece entre paréntesis en los mensajes del kernel: sda1, sdc1, dm-0, dm-2, /dev/mapper/vgname/lvname, etc. Eso te dirá si estás ante una partición directa (sdXN) o ante un volumen lógico LVM (dm-N, /dev/vgname/lvname).

Una vez tengas acceso a un shell (modo de emergencia, single user o máquina de rescate), ejecuta lsblk -f para ver la estructura completa: discos, particiones, LVM y tipos de sistemas de archivos. Es muy importante confirmar aquí si esa partición es realmente ext4, xfs, vfat, LVM2_member, etc., y no fiarte al 100% sólo de lo que dice /etc/fstab si sospechas que puede estar mal configurado.

Para reparar sistemas de archivos EXT4 se utiliza fsck. Como regla general:

• Asegúrate de que el sistema de archivos está desmontado (si es un disco de datos) o de que estás trabajando desde un entorno de rescate donde no está en uso.
• Lanza fsck /dev/sdXN o fsck /dev/vgname/lvname. Te irá preguntando si quieres corregir inconsistencias, recrear el inode de resize, ajustar contadores de bloques, etc.
• Si salen muchas preguntas, interrumpe con CTRL+C y vuelve a ejecutar con fsck -y para que responda “sí” automáticamente; así no te dejas nada sin corregir.
• Si mueve ficheros a lost+found, tendrás que revisarlos después y recolocarlos donde corresponda.
• Vuelve a ejecutar fsck hasta que la salida indique que el sistema de ficheros está clean.

En el caso de XFS, la herramienta es xfs_repair. Aquí el flujo típico es:

• Primero un chequeo en seco: xfs_repair -n /dev/vgname/homelv para ver qué daños hay sin modificar nada.
• Si el análisis es razonable, repite sin -n para que intente corregir: xfs_repair /dev/vgname/homelv.
• Si el comando se queja de que el sistema de archivos tiene “valiosos cambios de metadatos en un journal que necesita ser reproducido”, intenta montarlo: en sistemas XFS muchos cambios pendientes se aplican precisamente al montar. Si estás en una VM de rescate, puedes hacerlo en un punto como /recovery.
• Si no hay manera y los errores de journal no se solucionan, el último recurso es usar xfs_repair -L para descartar el journal y forzar el montaje como si todos los cambios se hubieran aplicado. Esto puede implicar pérdida de datos recientes, así que sólo hazlo cuando no te quede otra.

En todos los casos es fundamental entender que fsck y xfs_repair no son magia: arreglan la estructura del sistema de archivos, pero no siempre pueden recuperar todo el contenido. Por eso es tan crítico tener copias de seguridad previas y, si estás en nube o VM, trabajar sobre una instantánea del disco o una copia adjunta a una máquina de rescate.

GRUB, UEFI, Secure Boot y otros clásicos del arranque

Cuando al encender el equipo ni siquiera ves el menú de GRUB, o la BIOS/UEFI lanza errores tipo “Error al abrir \EFI\ubuntu\grubx64.efi – No encontrado” y entra en un bucle intentando arrancar siempre desde esa entrada, el problema está casi seguro en el gestor de arranque o en la configuración del firmware.

Estos fallos pueden aparecer tras instalar Windows en dual boot (que a menudo se adueña del MBR o reescribe entradas de UEFI), tras borrar una partición EFI sin querer, o después de toquetear el orden de arranque en la BIOS. En portátiles modernos no es raro que, si la entrada UEFI “ubuntu” apunta a un archivo que ya no existe, la máquina se reinicie en bucle intentando cargarlo.

La forma más cómoda de reparar un GRUB roto es arrancar con una distro Live (por ejemplo, Ubuntu) y utilizar la herramienta Boot-Repair. El procedimiento típico es:

• Iniciar desde un USB Live y abrir un terminal.
• Añadir el repositorio y actualizar: sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• Instalar la herramienta: sudo apt install -y boot-repair.
• Ejecutarla con boot-repair y escoger la opción de “reparación recomendada”.

Boot-Repair analiza las particiones, localiza sistemas instalados, reconfigura GRUB, regenera el fichero de configuración y, si hace falta, ajusta entradas UEFI para que el equipo vuelva a arrancar desde el gestor adecuado.

En sistemas con UEFI, Secure Boot y Fast Boot activados, hay una serie de incompatibilidades que conviene conocer. No todas las distros soportan Secure Boot correctamente, y algunas pensadas para hardware antiguo ni siquiera se llevan bien con UEFI. Si tu distribución no está firmada o el shim de arranque no es compatible, la UEFI puede negarse a cargar el kernel.

En esos casos, la solución suele pasar por entrar a la configuración de la UEFI, activar el modo Legacy/CSM para permitir arranques estilo BIOS clásico y desactivar Secure Boot. Eso sí, si también usas Windows 11 en ese equipo o quieres migrar de Windows a Linux, desactivar Secure Boot puede romper los requisitos de arranque de Windows, así que hay que valorar qué sistema prima o buscar una distro Linux compatible con Secure Boot para no tener que estar entrando en la BIOS cada vez.

El Fast Boot o inicio rápido de Windows también da guerra en escenarios de dual boot. Al apagar con Fast Boot activado, Windows no apaga del todo: deja parte del kernel hibernado en disco, bloqueando el acceso completo al sistema de archivos NTFS. Cuando Linux intenta montar esas particiones, pueden aparecer errores o directamente dejar el sistema atascado. Es recomendable desactivar el inicio rápido tanto en las opciones de energía de Windows como, si tu UEFI lo permite, en la propia BIOS.

Uso de modos de recuperación y herramientas de reparación integradas

Si GRUB aparece pero tu Linux no termina de arrancar, o si sospechas que un paquete se ha quedado a medias o que el sistema se ha roto tras una actualización, puedes aprovechar las opciones avanzadas de GRUB y los modos de recuperación que incluyen la mayoría de distros.

En el menú de GRUB suele existir una entrada “Advanced options” o similar. Dentro verás normalmente todas las versiones de kernel disponibles y, para cada una, un modo Recovery. Selecciona el recovery de la versión más reciente (y si falla, prueba con la anterior).

El modo de recuperación te muestra un menú de utilidades muy útil para:

• fsck: revisar y reparar el sistema de archivos (similar a chkdsk en Windows).
• clean: liberar espacio borrando ficheros temporales y otros residuos.
• dpkg: corregir paquetes rotos, dependencias incumplidas o instalaciones atascadas.
• grub: regenerar la configuración del gestor de arranque.

Ejecutar estas opciones en orden suele resolver muchos problemas derivados de cortes de luz durante actualizaciones, paquetes corruptos o discos que estaban a punto de llenarse. Al terminar, el sistema suele ofrecerte reiniciar para comprobar si el arranque vuelve a la normalidad.

En nubes como Azure, además de los modos de emergencia y usuario único, tienes herramientas específicas como Azure Linux Automatic Repair (ALAR) y el comando az vm repair, que automatizan parte del proceso: montan el disco del sistema en una VM de rescate, ejecutan acciones como “auditd” para arreglar configuraciones típicas y te permiten revertir fácilmente si algo sale mal.

Estrategias para reinstalar Linux sin perder datos

Hay situaciones en las que, por mucho que investigues, el sistema está tan destrozado o tu hardware es tan peculiar (como esa HP N150 o portátiles modernos con controladoras exóticas) que lo más sensato es reinstalar la distro. Eso sí, no tiene por qué implicar perder todos tus datos.

Muchas distribuciones, como Ubuntu y derivadas, ofrecen durante la instalación una opción del estilo “reinstalar el sistema operativo conservando documentos y configuraciones”. Esto reinstala el sistema base pero intenta respetar tu directorio /home y, en ocasiones, hasta algunas aplicaciones ya instaladas. Es una opción cómoda, aunque no infalible, por lo que conviene hacer copia de seguridad manual de aquello que no quieras perder.

La forma más robusta de blindarse ante reinstalaciones futuras es tener el disco organizado en varias particiones separadas:

• Una para / (raíz): sistema base.
• Otra para /boot (y /boot/efi en UEFI) si quieres más control sobre el arranque.
• Una partión exclusiva para /home o para datos.

Así, si tu Linux se queda inutilizable, podrás formatear sólo las particiones de sistema y de arranque, dejando intacta la de datos. Incluso si tienes una sola partición para todo, puedes arrancar desde una Live, montar el disco, copiar documentos a un disco externo o a la nube y, una vez a salvo, hacer una instalación limpia.

En máquinas virtuales, sean de VirtualBox, VMware o en la nube, es buena idea separar también los discos de datos del disco del sistema. En Azure, por ejemplo, se recomienda que los volúmenes LVM de datos no se mezclen en el mismo grupo de volúmenes que el disco del sistema para evitar que un fallo del OS se lleve por delante también los datos.

Buenas prácticas para evitar que los problemas se repitan

Una vez que te has peleado con un arranque roto y has recuperado el sistema (o al menos los datos), lo inteligente es tomar algunas medidas para que la próxima vez el susto sea menor o directamente no llegue a producirse.

La primera es mantener el sistema y el software actualizados, pero con cabeza. En distros rolling como Arch, las actualizaciones frecuentes son imprescindibles; en otras más conservadoras (Debian estable, Ubuntu LTS) puedes espaciar un poco, pero no conviene dejarlas años sin tocar. Antes de grandes cambios de kernel o versiones, haz siempre una copia de seguridad decente.

Otra costumbre muy sana es documentar cualquier cambio importante en la configuración: qué fichero tocaste, qué línea cambiaste y cómo estaba antes. Un truco sencillo es guardar siempre una copia del archivo original con sufijo .bak (por ejemplo, sshd_config.bak) para poder restaurarlo fácilmente si la lías.

Respecto a los datos, lo fundamental son las copias de seguridad periódicas. Puedes usar rsync para backups incrementales, tar para empaquetar directorios enteros o soluciones en la nube y NAS. Si además tus datos están en una partición distinta a la del sistema, podrás reinstalar sin tanto drama incluso si el disco no arranca.

Por último, no está de más vigilar la salud del sistema con cierta regularidad: revisar SMART mensualmente, monitorizar inodos y espacio libre en particiones críticas (/, /var, /home), echar un ojo a los logs en busca de mensajes repetitivos y mantener a raya la temperatura y el polvo en equipos físicos. Una pequeña rutina de mantenimiento ahorra muchos madrugones arreglando máquinas que “de repente” han dejado de arrancar.

Con todo este arsenal de técnicas, comandos y buenas prácticas, diagnosticar y reparar problemas de arranque y errores de hardware en Linux deja de ser un acto de fe para convertirse en un proceso bastante razonable: primero identificas si el fallo es de disco, sistema de archivos, GRUB, kernel, configuración o hardware; después aplicas la herramienta adecuada (fsck, xfs_repair, Boot-Repair, smartctl, MemTest, modos de recuperación, etc.), y, en el peor de los casos, tienes un plan B bien montado con particiones separadas y copias de seguridad que te permiten reinstalar sin que se te hunda el mundo.