---
Resumen del Proceso de Recuperaci�n del Sistema (Arch / Garuda)
Vamos a detallar los pasos seguidos para solucionar un bloqueo cr�tico en el arranque del sistema operativo Garuda Linux, debido a un conflicto con los drivers de la tarjeta gr�fica, que suced�an en la fase del initial ramdisk. Espero que sirva para demostrar que aunque la l�gica nos dicta que reinstalar en algunos casos es la opci�n r�pida, en este caso se buscaba m�s el conocimiento que se adquiere en el proceso.
1. S�ntomas Iniciales y Diagn�stico
- Intento de arranque en modo texto:
- Uso de consola m�nima (`init=/bin/bash`):
- Bloqueo en el Initramfs:
- Cambio de kernel activo:
- Reinstalaci�n limpia de los drivers de Nvidia:
- Reconstrucci�n del Initramfs mediante Dracut:
- Actualizaci�n del gestor de arranque (otra vez):
- Restaurar el entorno gr�fico predeterminado:
Se intent� iniciar el sistema en modo multiusuario sin entorno gr�fico (Runlevel 3), modificando los par�metros de GRUB a�adiendo 3 (que no funcion�) y text (que s� que lo hizo). Una vez iniciado, el sistema se congelaba, esta vez tras el chequeo de archivos (en pantalla sal�a File System Check del disco duro donde se encuentra el sistema instalado). Un avance es un avance.
Se logr� acceso a una shell de root b�sica. Sin embargo, en este entorno m�nimo no se cargaban los m�dulos de red (la interfaz f�sica no aparec�a, s�lo lo) debido a la falta de inicializaci�n de `systemd` y `udev`.
Tras cambiar el target predeterminado a texto (systemctl set-default multi-user.target), el sistema comenz� a congelarse de manera inmediata en la pantalla Cargando Linux linux-zen... Cargando imagen de memoria inicial... Shit, esto huele a fallo en el kernel.
Viendo que el kernel usado es el paso donde se queda clavado todo, usaremos un Live USB de alguna distro con Arch de base para hacer chroot y cambiarlo.
Diagn�stico:
Conflicto cr�tico o corrupci�n entre el kernel (en combinaci�n con `linux-zen` o el stock) y los m�dulos propietarios de Nvidia al mapear la memoria en el arranque temprano. Es lo que pasa cuando sufres FOMO e instalas los �ltimos drivers en fase experimental, para ver si puedes ganar algo de rendimiento a costa de jugarte la estabilidad.
2. Preparaci�n del Entorno de Rescate (Live USB & Chroot)
Tal y como se indica arriba, al no poder iniciar el kernel base, se procedi� a utilizar un Live USB para reparar el entorno desde fuera.
Paso 1: Montaje correcto del sistema de archivos Btrfs
El sistema base utiliza Btrfs organizado por subvol�menes. El montaje directo de la partici�n ra�z (`/dev/sda1`) muestra la estructura de subvol�menes (y he aqu� nuestro primer aprendizaje pr�ctico): `@`, `@home`, `@cache`, `@log`, `@root` en lugar del �rbol del sistema.
Para preparar el chroot de manera adecuada, se ejecut�:
# Desmontar el directorio si estaba mal mapeado
umount /mnt
# Montar espec�ficamente el subvolumen ra�z (@)
mount -o subvol=@ /dev/sda1 /mnt
# Montar la partici�n de arranque EFI correspondiente
mount /dev/sda2 /mnt/bootPaso 2: Entrada al entorno mediante chroot
arch-chroot /mntY una vez hecho, procedimos a actualizar el sistema y a instalar el kernel gen�rico:
# Actualizar
pacman -Syu --noconfirm && pacman -S linux linux-headers
# Cargar el kernel gen�rico en el GRUB
update-grub3. Mitigaci�n del Cuelgue en GRUB
Dado que la regeneraci�n est�ndar segu�a bloque�ndose en el paso del ramdisk, se utilizaron par�metros de exclusi�n agresivos en el men� de edici�n de GRUB (tecla `e` sobre la opci�n del kernel):
nomodeset acpi=off`nomodeset`: Desactiva el Kernel Mode Setting (KMS), impidiendo que el driver de v�deo intente inicializarse antes de tiempo.
`acpioff`:= Desactiva la interfaz avanzada de configuraci�n y energ�a, solucionando la colisi�n de asignaci�n de memoria PCI producida por la gr�fica en el firmware. Este m�todo permiti� el acceso exitoso a la terminal tty nativa del sistema instalado con conectividad a red. A tener en cuenta que esto es un mazo, no un bistur�: al desactivarlo, se desactiva la gesti�n de energ�a, la suspensi�n del sistema, lectura de sensores no triviales tales como los de temperatura de la CPU/GPU, velocidad de los ventiladores (�se ve por donde vamos?), etc... No hay que dejarlo como configuraci�n definitiva, s�lo para reparar lo que sea que se rompi� y luego se deja como estaba.
4. Saneamiento y Soluci�n Definitiva en Garuda Linux
Una vez dentro de la terminal con los privilegios y la red restaurados, se realizaron las siguientes tareas de reparaci�n:
Se opt� por la rama DKMS para asegurar que los m�dulos de la gr�fica se compilen din�micamente y de forma correcta con cualquier versi�n del kernel en uso (los m�dulos DKMS se recompilan tras actualizaciones):
pacman -S nvidia-dkms nvidia-utilsAl ser Garuda el sistema base, se utiliz� su automatizaci�n nativa basada en `dracut` en lugar de `mkinitcpio`:
dracut-rebuild update-grub systemctl set-default graphical.target5. Post-Configuraci�n y Verificaci�n
Tras reiniciar el equipo de forma normal (sin par�metros adicionales en GRUB), el sistema carg� de manera limpia directamente a la pantalla de login gr�fico.
Finalmente, se restableci� la resoluci�n nativa y la tasa de refresco del monitor utilizando la herramienta arandr, confirmando el correcto funcionamiento del driver propietario de Nvidia.
En conclusi�n, �se podr�a haber reinstalado un sistema de nuevo y volver a montarlo todo? Si, claro... �Ha valido la pena perder una tarde tontamente buscando en internet y preguntando a Gemini cuando la respuesta no era la m�s obvia? �Absolutamente! Ni recordaba qu� era [[https://es.wikipedia.org/wiki/Dracut_(software)][dracut]], ni que darse contra un muro era a la vez frustrante y reconfortante a la vez.