Hoy les voy a contar la historia del güevón que se cargó Wayland sin tener otro protocolo de visualización como Xorg. El resultado, desde luego fue un sistema que no arrancaba, la horrible pantalla negra y, debajo de ella, todos los datos, los archivos, los documentos, el trabajo, etcétera. Conozco muy bien esta historia porque el pendejo que se cargó Wayland soy yo.
¿Wayland?
Esto no tiene misterio para los usuarios de GNU/Linux. Wayland es el protocolo de visualización que gestiona la interfaz gráfica del usuario (GUI). En lenguaje mundano lo que hace es gestionar los elementos gráficos de su interfaz como ventanas, botones y otros elementos para que usted pueda interactuar con ellos en su escritorio.
OJO: Wayland NO ES el entorno de escritorio. Los entornos serían Gnome, KDE, XFCE, etc. Wayland es más bien aquello que dibuja las aplicaciones del usuario en su entorno de escritorio para que las pueda usar.
Wayland no es una aplicación que se descargue y se instale como Gimp o Thunderbird. Ya viene incluida en su DE (desktop environment). No obstante, si bien no la podemos descargar de la tienda o de Github, sí la podemos desactivar y, si no tenemos un protocolo de visualización alternativo, nuestra maquinita quedará en negro.
Eso fue lo que paso con el pendejo que se cargó Wayland, o sea yo: que desactivé Wayland para usar Xorg sin percatarme de que no tenía Xorg 🙄 Por fortuna pude resolverlo.
Todo por un juego.
Estaba bobeando con un sistema GNU/Linux Fedora 41 y no lograba hacer correr un juego en Steam que corría perfectamente en otra máquina con Ubuntu 24.04. Ya había hecho la configuración de compatibilidad en Steam con Proton Experimental (la capa de compatibilidad que nos permite usar aplicaciones de Mierdasoft en sistemas operativos para Homo sapiens) pero seguía sin funcionar. Buscando en foros llegué a uno donde un usuario (gracias malparido) decía que se debía editar el archivito de configuración de GDM (Gnome Display Manager) para anular el inicio con Wayland y forzar al inicio con Xorg.
Esto, pensándolo bien, no tiene mucho sentido. Si quiero arrancar en Xorg lo único que debo hacer es elegir esa opción en la pantalla de inicio. Claro, eso en caso de que tenga Xorg. Si anula Wayland y no tiene Xorg no arranca ni por el putas. Créame, ni-por-el-pu-tas.
Y ahí estuvo el error. O, mejor dicho, los errores pues fueron dos: no analizar la solución dada en el foro y no comprobar que tuviera otro protocolo de visualización en el sistema. La primera fue por güevón, la segunda por confiado pues en otros sistemas como Ubuntu siempre tuve la opción de arrancar, a gusto o conveniencia, con Wayland o con Xorg.
Los pasos que seguí para cargarme Wayland fueron los siguientes:
sudo nano /etc/gdm/custom.conf #Abrí el archivo de configuración con el editor nano. #WaylandEnable=false #Descomenté esta línea (quité el #). sudo systemctl restart gdm #Reinicié el display manager de Gnome.
Y al reiniciar todo quedó en negro como la puta noche o como la conciencia de cualquier Secretario de Planeación tropical (o sea dotor) que extorsiona a los campesinos para darles permiso de construir su bañito con pozo séptico para que dejen de cagar a la intemperie mientras las gallinas ansiosas les picotean las nalgas.
¿Qué otra cosa podría pasar? Si enable=false entonces es disable. Eso lo sabe cualquier idiota (incluso yo). Repito: esto no tendría la menor importancia si el sistema tuviera otro protocolo de visualización pero, en mi caso, no lo tenía.
Lo que no sirvió.
Buscando resolver el problema sin tener que instalar de nuevo el SO, hice la mar de pendejadas que no sirvieron. A continuación algunas de ellas para que sepan lo que no me funcionó y no pierdan el tiempo:
Restaurar desde el grub.
Fue lo primero que intenté. En ese momento me pareció sensato restaurar mi sistema desde su propio gestor de arranque (Grub). Supongo que alguien con más y mejores conocimientos que los míos podría restaurarlo desde allí pero yo no pude. Lo pasos que seguí fueron los siguientes:
normal #Para salir del prompt Grub> y volver al menú normal. #Esto no funcionó por lo cual volví a Grub>... ls #Para ver que dispositivos había. La respuesta fue: (memdisk) (proc) (hd0) (hdc,gpt3) (hdc,gpt2) (hdc,gpt1) #Donde cada hdc es una partición. Ahora debía ver qué había en cada una: ls (hdc,gpt1)/ ls (hdc,gpt2)/ ls (hdc,gpt3)/ #Buscaba una partición que tuviera un directorio /boot o un archivo como initramfs-6.x.x-x.fc41.x86_64.img. En mi caso fue la hdc,gpt2. Acto seguido: set root=(hd0,gpt2) #Para establecer la partición. linux /vmlinuz-6.13.9-200.fc41.x86_64 root=/dev/sda3 ro #Para cargar el kernel. initrd /initramfs-6.13.9-200.fc41.x86_64.img #Para cargar el init. boot #Para iniciar. #Pero no inició nada. O sí, me inició un fuerte dolor de cabeza :-x . #Al darle boot se quedaba congelado y decía: A start job is running for /dev/sda3. #Traducción: no puede montar la raíz del sistema en /dev/sda3, porque no encuentra el sistema de archivos ahí.
Y como yo soy terco lo intenté con sda2, sda1 y demás. El resultado: otra hora perdida y el dolor de cabeza a punto de convertirse en aneurisma. Hora de intentar otra solución. Spoiler: tampoco funcionó.
RESTAURAR DESDE UN DISCO LIVE DE OTRA DISTRO.
Esto lo pensé por dos razones: uno, porque si podía acceder a una shell podría acceder al archivo custom.conf y arreglar el cagadón que hice y, dos, porque ya era tarde, solo tenía un disco live de Kali Linux y me daba pereza crear uno de Fedora.
Cancelé la instalación de Kali Linux y en las opciones que me daba abrí una shell. Convencido de que ya estaba cerca de resolver la burrada que hice por pendejo. El rollo es que al usar el comando cat /etc/os-release la respuesta era: PRETTY_NAME="Kali GNU/Linux Rolling" lo que indicaba que estaba en una shell de Kali, no de Fedora. Por lo que se me ocurrió montar el sistema Fedora desde aquí y acceder con chroot. ¡Qué gran idea! Lo que hice fue:
which mount which chroot which nano #Para ver si tenía las herramiemtas necesarias. #Pero no tenía nada :/ busybox #Para ver si me encontraba en un entorno BusyBox. #Aquí sí tuve respuesta entonces pensé que podía seguir adelante. ls /dev/sd* #Buscando la partición raíz, algo como /dev/sda /dev/sda1 /dev/sda2 /dev/sda3. #Pero la respuesta fue: ls: /dev/sd*: No such file or directory #Traducción: BusyBox ni siquiera detecta el disco duro por lo cual no podré montar nada.
Esta es la versión simplificada. Lo cierto es que tardé más de una hora intentando restaurar mi sistema Fedora desde una shell limitada de Kali Linux. El perezoso trabaja doble o, en mi caso, triple. Ahora veamos lo que sí funcionó y, a ojos de cualquier conocedor, es lo que debí hacer desde el principio.
Lo que sí funcionó.
Lo que debí hacer desde un principio fue montar un disco live de Fedora, arrancar desde USB, darle en try en lugar de instalar y una vez en el escritorio conectarme al host y arreglar el cagadón que torpemente cometí. Entonces, desde otro equipo creé un disco de Fedora 41 con Balena Etcher y lo arranqué en la máquina problema. Los pasos fueron:
lsblk -f #Para listar las particiones disponibles. #Necesitaba encontrar la partición con el sistema de archivos btrfs. #En la salida encontré: nvme0n1p3 btrfs # :) #Ahora debía montar en el entorno live (el del USB). sudo mkdir -p /mnt/fedora sudo mount -o subvol=@ /dev/nvme0n1p3 /mnt/fedora #El subvolumen @ es estándar en instalaciones de Fedora con btrfs. #Lastimosamente aquí me dio error: System call failed: no such file or directory. #Como me dice que no existe debía ver qué sí existe: sudo btrfs subvolume list /dev/nvme0n1p3 #La salida fue: ID 256 gen 6248 top level 5 path home ID 257 gen 6249 top level 5 path root ID 258 gen 6248 top level 257 path root/var/lib/machines #Con esto ya tenía lo necesario: sudo mkdir -p /mnt/fedora sudo mount -o subvol=root /dev/nvme0n1p3 /mnt/fedora sudo mount --bind /dev /mnt/fedora/dev sudo mount --bind /proc /mnt/fedora/proc sudo mount --bind /sys /mnt/fedora/sys sudo mount --bind /run /mnt/fedora/run #Como no dio errores ya podía entrar al sistema con: sudo chroot /mnt/fedora nano /etc/gdm/custom.conf WaylandEnable=false #Volví a ponerla la almohadilla #. #Guardé el archivo .conf y cerré el editor. exit sudo umount -Rl /mnt/fedora reboot #Y crucé los dedos...
Retiré la unidad USB, esperé al reinició y todo volvió a la normalidad. Tras 3 horas de prueba y error mi Fedora 41 arrancó con Wayland como si nada hubiera pasado. ¿Y el juego? Una maravilla, corriendo como en nativo:
Conclusiones.
Todo esto pude ahorrármelo comprobando cuáles GDM tenía mi sistema. Esto se puede hacer de dos formas: o bien en la pantalla de inicio antes de introducir la contraseña, o bien verificándolo a través de la terminal con los siguientes comandos:
ls /usr/share/xsessions #Salida: gnome-classic.desktop gnome-xorg.desktop ls /usr/share/wayland-sessions #Salida: gnome.desktop
Eso bastaría para saber sí tenía Xorg en cuyo caso podría desabilitar Wayland o no. En caso de no tener Xorg (como en efecto ocurrió), bastaba instalarlo con el comando: sudo dnf install gnome-session-xsession. Eso era todo lo que tenía que hacer al comprobar que no tenía lo que necesitaba.
Después, al tratar de resolver el problema intenté soluciones que no podían funcionar y dejé de lado la única que sabía que podía resolverlo: iniciar desde un live de la misma distribución. ¿Para qué reinventar la rueda? Olvidé el principio KISS (Keep it simple, stupid) y me embrollé varias horas haciendo tonterías sin sentido.
Al final seré conocido como el pendejo que se cargó Wayland pero siendo justos también seré el pendejo que sin ser un informático de oficio lo resolvió. Esto es apenas un hobbie y hasta aquí llega el post porque me voy a jugar Doorways: The Underworld (2014). Hasta la próxima.
