El Colapso del Sistema: Una Caótica Experiencia con Linux y NVIDIA

Durante el desarrollo de pruebas intensivas con modelos de lenguaje locales (LLMs) ejecutados sobre una tarjeta gráfica NVIDIA, el sistema operativo de CachyOS (Linux) colapsó por completo tras un reinicio abrupto. La integración entre las distribuciones orientadas a juegos, los controladores de vídeo y las cargas de trabajo prolongadas de Inteligencia Artificial puede generar estados de congelamiento severos y corrupción temporal en el almacenamiento en caché.

Ante la imposibilidad de recuperar la estabilidad del entorno gráfico de forma inmediata, fue necesario recurrir a un análisis profundo mediante consola, el uso de unidades de rescate USB y herramientas avanzadas de asistencia técnica asistida por IA para reconstruir el sistema de arranque.

1. Diagnóstico Inicial y Análisis de Tiempos de Arranque

Para identificar qué servicios o procesos estaban ralentizando el inicio del sistema operativo, el primer paso diagnóstico consistió en analizar el rendimiento de arranque de los componentes mediante la terminal.

• systemd-analyze blame: Este comando enumera de forma ordenada todos los servicios del sistema (systemd) según el tiempo exacto que tardaron en inicializarse durante el arranque. Permite detectar de inmediato si un demonio o controlador específico está generando un cuello de botella o bloqueando el proceso de encendido.
• systemctl status sddm y sudo systemctl restart sddm: Permiten verificar el estado y reiniciar el gestor de pantalla gráfico (en este caso, SDDM). Sin embargo, cuando la interfaz gráfica falla por completo debido a los controladores de video, esta alternativa suele ser insuficiente si el núcleo del problema reside en el hardware gráfico.
• systemctl --failed se utiliza en sistemas Linux para listar todas las unidades de systemd que han fallado
  • journalctl --directory=/mnt/var/log/journal -p err -b -1

2. Rescate del Sistema Mediante Live USB y Chroot

Al no cargar el entorno gráfico ni permitir el acceso convencional, se recurrió a un medio de instalación externo (Live USB) para montar de forma virtual las particiones del disco interno y reparar el sistema de archivos raíz (formateado en Btrfs) desde una consola de comandos independiente.

• lsblk: Lista todos los dispositivos de almacenamiento y particiones disponibles en el equipo (como unidades NVMe), facilitando la identificación exacta de dónde se encuentra instalado el sistema operativo.
• sudo mount -o subvol=@ /dev/nvme1n1p2 /mnt: Monta el subvolumen raíz principal de Btrfs del sistema dañado en el directorio temporal /mnt del USB de rescate para poder manipular sus archivos internos.
• sudo mount /dev/nvme1n1p1 /mnt/boot/efi: Monta la partición de arranque EFI del sistema en la ruta correspondiente dentro del entorno montado.
• sudo arch-chroot /mnt: Cambia la raíz del sistema de comandos actual hacia el directorio montado del disco duro (chroot). Permite "entrar" virtualmente al sistema dañado para ejecutar comandos de reparación como si la PC hubiera encendido de manera normal.

3. Reconstrucción del Entorno de Arranque y Gestor GRUB

Una vez dentro del entorno de rescate, los problemas de corrupción en las imágenes de inicio y en el gestor de arranque se corrigieron utilizando herramientas nativas de reconstrucción:

• mkinitcpio -P: Reconstruye y empaqueta desde cero las imágenes initramfs (el sistema de archivos raíz temporal que se carga en la memoria RAM al encender el equipo). Esto permite que el núcleo del sistema vuelva a empaquetar los controladores de disco y sistemas de archivos necesarios para leer las unidades NVMe sin quedarse congelado en el arranque.
  • Lo que hace es empaquetar todos los controladores de disco, sistemas de archivos y servicios del sistema para que, cuando enciendas la PC, el kernel pueda leer tus unidades NVMe y montar tu partición Btrfs sin quedarse colgado
  • En concreto, los ganchos (hooks) que ves en pantalla realizan tareas esenciales:
    ⁠autodetect⁠: Detecta qué hardware específico tiene tu placa base y tus componentes actuales para incluir únicamente los controladores (drivers) necesarios y aligerar el arranque.
    ⁠microcode⁠: Carga las actualizaciones de microcódigo del fabricante para tu procesador Intel o AMD, corrigiendo posibles fallos de estabilidad a nivel de hardware de forma temprana.
    Una vez que termine de pasar por todos los ganchos restantes (como ⁠modconf⁠, ⁠block⁠, ⁠filesystems⁠, etc.), el proceso habrá finalizado y volverá a mostrarte el cursor de comandos.
  • Funciona como un disco RAM temporal y necesario que el kernel utiliza justo al encender para cargar los controladores básicos de tu hardware, como el soporte NVMe y tu partición Btrfs).
  • Cuando ese archivo se corrompe o se queda desincronizado, el sistema se queda congelado en el mensaje de "Loading initramfs" porque el kernel se queda ciego y no sabe cómo seguir leyendo el disco duro. Al hacer ⁠mkinitcpio -P⁠, le estamos diciendo que vuelva a empaquetar ese puente de arranque usando la información real y limpia de tus componentes.
• grub-install y grub-mkconfig:
  • grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=cachyos --recheck: Reinstala los archivos del gestor de arranque GRUB en la partición EFI para que la placa base reconozca correctamente la ruta de inicio del sistema operativo.
  • grub-mkconfig -o /boot/grub/grub.cfg: Escanea el disco en busca de núcleos instalados y genera un archivo de configuración actualizado para GRUB, asegurando que el menú de arranque reconozca todos los sistemas disponibles (incluyendo Windows).

4. Edición de Parámetros de Arranque y Modo de Rescate (TTY)

Para evitar que el núcleo del sistema intente cargar la aceleración gráfica defectuosa de NVIDIA durante el encendido, es posible interrumpir el menú de GRUB presionando la tecla e y añadiendo parámetros de depuración al final de la línea que comienza por linux /boot/vmlinuz- :

• plymouth.enable=0: Desactiva la pantalla de carga visual y la animación con el logotipo del sistema. Al evitar el uso temprano de la aceleración gráfica, se previene el congelamiento provocado por fallos en los controladores de vídeo.
• nomodeset: Ordena al núcleo de Linux que no cargue los controladores gráficos dedicados (NVIDIA) en la etapa inicial de arranque, utilizando en su lugar un controlador de video básico compatible.
• 3: Fuerza al sistema a iniciar directamente en modo texto puro (consola multiusuario sin entorno de escritorio gráfico), facilitando el diagnóstico avanzado de errores.

Lo que debes hacer:

Enciende el PC y, cuando aparezca el menú de GRUB (donde eliges entre CachyOS y Windows), selecciona la opción de CachyOS pero busca la que dice Fallback (por ejemplo, CachyOS Linux (fallback)) o presiona la tecla ⁠E⁠ en la línea normal para editar los parámetros de arranque y añadir la palabra ⁠single⁠ o ⁠3⁠ al final de la línea que empieza por ⁠linux⁠, luego presiona ⁠Ctrl + X⁠ para arrancar.

También puedes probar las otras opciones del GRUB:

• "Fallback" en GRUB:
  •  Ve a Advanced options for CachyOS (Opciones avanzadas para CachyOS).
  • Selecciona la opción que termina en (fallback initramfs).
  • Presiona ⁠Enter⁠.
• Forzar el modo de texto/seguro editando GRUB en tiempo real
  Si la opción anterior también se congela en la pantalla negra, lo que mostramos antes.

Plymouth

5. Gestión de Paquetes y Solución Definitiva

Una vez dentro de la terminal de comandos sin interfaz gráfica, la actualización y reparación de paquetes dependió del gestor oficial del sistema:

• sudo pacman -Syu: Sincroniza los repositorios oficiales y actualiza todos los paquetes del sistema a su versión más reciente.
  • • pacman: Invoca al gestor de paquetes nativo de Arch Linux.
    • -S (Sync): Indica que se trabajará con los repositorios remotos para sincronizar o instalar software.
    • -y (Refresh): Descarga e instala la copia más reciente de la base de datos de paquetes desde el servidor.
    • -u (Sysupgrade): Compara las versiones de los paquetes del sistema local con las de la base de datos recién actualizada y procede a actualizar todo lo que haya quedado obsoleto.
• sudo pacman -S $(pacman -Ssq nvidia): Busca y reinstala de forma automatizada todos los paquetes y dependencias relacionados con los controladores de la tarjeta gráfica NVIDIA NO EJECUTES ESTO NUNCA, ya que instalaría paquetes que NO necesitas, TODOS los del repo oficial.

El Análisis de OpenCode y el Diagnóstico Asistido por IA

Durante el proceso de recuperación del sistema operativo tras el fallo de los controladores gráficos, se recurrió a herramientas de asistencia por inteligencia artificial (como OpenCode) ejecutadas con privilegios de usuario estándar (sin permisos de superusuario mediante sudo), garantizando un entorno de análisis controlado.

Realiza un diagnostico completo del sistema para identificar la cauza raiz del problema con el sistema que al iniciar va extremadamente lento desde el GRUB hasta cargar la pagina de login, en los procesos como Plymouth se ve como se demora el sistema, cada cosa de Interfaz grafica va muy lento, no puedo ya cargar nada de la interfaz grafica, el problema aconteció cuando desde otra sesión, estabas probando por horas LLMs en local en base a un proyecto en fastapi, la reinicia desde la interfaz y al iniciar ya arrancaba muy lento. Revisa los logs del sistema a ver si encuentras algo, ya que, pienso que puede ser nvideia-smi el conflicto, las configuraciones mkinitcpio.conf los archivos de particiones a ver si todo esta ok o lo que consideres a ver si puedes dar con el problema , ya descarte un problema con la gráfica iniciando windows y ejecutando un juego, va perfecto, pienso que es algún conflicto con Linux y los drivers de NVidea, algún proceso que quedo en bucle o corrupto, alguna cache o algo que hace que tenga este comportamiento

1. Planteamiento del Problema al Asistente de IA

Para obtener un diagnóstico preciso, se estructuró un reporte detallado dirigido al agente de IA con las características del fallo:

• Síntomas principales: El sistema experimentaba una lentitud extrema desde la pantalla de GRUB hasta la carga del gestor de inicio de sesión y la interfaz gráfica.
• Contexto previo: El fallo sobrevino tras un reinicio abrupto motivado por sesiones prolongadas de ejecución de modelos de lenguaje locales (LLMs) sobre una tarjeta gráfica NVIDIA.
• Acciones descartadas: Se verificó el correcto funcionamiento físico del hardware gráfico al comprobar que el equipo arrancaba y ejecutaba juegos sin problemas bajo Windows.

2. Proceso de Análisis y Corrección de Errores

Inicialmente, los asistentes basados en modelos probabilísticos suelen sugerir hipótesis basadas en configuraciones comunes. En este caso, el agente interpretó erróneamente un parámetro de arranque introducido manualmente en el menú de GRUB (como el modo de texto seguro) como una anomalía en el sistema.

Una vez reorientado el contexto y tras analizar las bitácoras del sistema, se determinó que la causa raíz radicaba en una corrupción temporal de los paquetes de los controladores propietarios de NVIDIA provocada por la interrupción forzada de los procesos de la GPU.

3. Comandos Clave Utilizados en el Diagnóstico y Reparación

Durante la auditoría técnica y la solución definitiva del problema, se emplearon herramientas especializadas del sistema que permitieron examinar recursos y actualizar los componentes afectados:

• systemd-analyze blame: Lista todos los servicios activos ordenados de mayor a menor según el tiempo que tardaron en inicializarse, identificando cuellos de botella en el arranque.
• systemctl --failed: Muestra únicamente las unidades de servicios del sistema que fallaron al iniciar, útil para detectar procesos bloqueados en bucle.
• nvidia-smi: Herramienta de supervisión que detalla el estado actual de la GPU NVIDIA, su temperatura y los controladores cargados.
• journalctl -b -p warning: Filtra el registro del arranque actual (-b) mostrando de forma exclusiva las advertencias y errores críticos (-p warning).
  • journalctl -p err -b
  • journalctl -b -1 -p err
  •  
• sudo pacman -Syu: Sincroniza los repositorios locales y actualiza por completo todos los paquetes del sistema operativo.
  • Parámetro -S (Sync): Gestiona la instalación y actualización de paquetes desde los repositorios.
  • Parámetro y (Refresh): Descarga una copia reciente de las bases de datos de los repositorios remotos.
  • Parámetro u (Sysupgrade): Actualiza todos los paquetes del sistema que tengan versiones más recientes disponibles.
• sudo pacman -S --overwrite '*' nvidia-utils opencl-nvidia nvidia-settings libva-nvidia-driver: Fuerza la reinstalación y sobrescritura de los componentes gráficos esenciales de NVIDIA para corregir librerías dañadas.
  • Parámetro --overwrite '*': Indica al gestor de paquetes que sobrescriba cualquier archivo existente en el sistema que entre en conflicto con los nuevos paquetes a instalar, asegurando una recuperación limpia.

Conclusión

La experiencia demuestra que, si bien las herramientas de Inteligencia Artificial (como asistentes basados en código u OpenCode) ofrecen rutas de diagnóstico muy valiosas para examinar registros de errores y proponer soluciones, el usuario debe mantener un criterio técnico activo. Comprender la función exacta de comandos avanzados como chroot, mkinitcpio y la manipulación de parámetros en GRUB marca la diferencia entre rescatar con éxito un entorno operativo complejo o recurrir innecesariamente a un formateo total.

La combinación de un diagnóstico estructurado a través de terminales de texto y la asistencia de herramientas de código basadas en IA permitió resolver un problema crítico de controladores sin necesidad de formatear el equipo. Comprender el comportamiento de los paquetes del sistema y el uso de parámetros avanzados de sobrescritura garantiza una capacidad de respuesta eficiente ante fallos complejos en entornos Linux.

Esta fue la conclusión que hizo la IA y de la cual, estoy de acuerdo:

Es una excelente duda. En teoría, restaurar un punto de control de Btrfs/Snapper debería devolver el sistema al instante exacto previo al fallo. Sin embargo, en el caso de las GPUs NVIDIA y el arranque de Linux, restaurar un snapshot a veces no resuelve la lentitud ni el bloqueo por tres razones técnicas concretas:
1. Estado físico/persistencia de la GPU: Un punto de restauración solo cambia archivos en el disco duro. Si la GPU quedó en un estado de fallo de hardware/VRAM bloqueada por el proceso del LLM, la tarjeta de video mantendrá ese error a nivel eléctrico/firmware hasta que no haya un ciclo de energía o un reseteo de bus PCI completo, sin importar qué archivos tenga el disco.
2. La partición ⁠/boot⁠ o EFI no siempre se restaura: Los snapshots de Btrfs por defecto solo guardan la partición raíz (⁠/⁠). Los archivos de inicio del kernel, las imágenes del entorno de arranque (⁠initramfs⁠) o la configuración de GRUB en la partición EFI suelen quedar fuera del snapshot. Si hubo un desajuste ahí, el snapshot de la raíz no lo corrige.
3. Módulos compilados en caché: Los controladores de NVIDIA compilan módulos específicos contra el kernel. Si el snapshot restaura la raíz pero no la caché de DKMS o las imágenes del ramdisk, el kernel de inicio sigue intentando cargar un módulo desincronizado.
Por eso, una reinstalación limpia es la vía más rápida y definitiva en este punto: formatea la partición raíz, escribe una imagen EFI/boot totalmente nueva, aplica la detección limpia de hardware para NVIDIA y reconfigura GRUB reconociendo a Windows desde cero.