Hace tres años, escribí un artículo que explicaba cómo recuperarse de un arranque fallido luego de una actualización de versión principal en Fedora. En ese momento, estaba trabajando con Fedora 25 y, de repente, ya no podía acceder al escritorio. El problema resultó ser un initramfs defectuoso, que es un problema que solo encontré una vez en el pasado, en Ubuntu, en 2009. Desde entonces, ha estado tranquilo.
Bueno, la rueda del tiempo nos ha devuelto al principio. El mismo problema volvió a ocurrir. Recientemente actualicé (algo) una instancia de Fedora 29 a Fedora 30, y he aquí que me encontré enfrentando el mismo problema. Casi. Tenía una pantalla negra y un mensaje que decía:No se puede abrir el acceso a la consola, la cuenta raíz está bloqueada. En este punto, tratar de hacer cualquier cosa no dio ningún resultado. Solo pude reiniciar. Probé con otro núcleo, y esto ayudó:llegué a mi escritorio. Si bien el problema parece ser similar, tuve que tomar una forma ligeramente diferente para solucionarlo.
Síntomas del problema con más detalle
Me encontré bastante perplejo por la falta de herramientas de diagnóstico accesibles o un entorno utilizable en el que pudiera solucionar el problema. Tener que reiniciar significa perder información posiblemente valiosa. Como mínimo, podía arrancar en otros núcleos, lo que significaba que tenía algo con lo que trabajar.
En el último kernel-1, primero traté de seguir mi propio consejo de hace dos años, pero el comando systemctl status boot-efi.mount no mostró nada útil. Siempre me sorprende lo frágil, complejo y poco amigable que es el nuevo y moderno marco de arranque. El número anterior me impulsó a escribir mi artículo Progreso a través de la complejidad, y sus conclusiones aún se mantienen, años después.
El obstáculo más simple es la disponibilidad de información en /var/log. En los buenos días de inicio, normalmente encontraría lo siguiente allí:syslog/messages, boot, old boot y kernel logs. Estos eran archivos de texto que podía inspeccionar fácil e instantáneamente con cat, menos, lo que sea.
En Fedora, obtiene algunos, pero no todos estos archivos. Por ejemplo, boot.log está ahí, pero luego:
sudo menos boot.log
"boot.log" puede ser un archivo binario. ¿Lo ves de todos modos?
Curiosamente, ES un archivo de texto (con algunos caracteres raros) y puedes mostrarlo con cat. Pero este archivo no proporcionó ninguna información útil que pudiera ayudarme a identificar el problema.
Luego pasé un poco más de tiempo leyendo las diferentes opciones para journalctl, y te da la opción de ver los registros de arranque anteriores. Puede hacerlo proporcionando un valor entero negativo para ver los registros antiguos. Esto no es muy intuitivo, pero al menos me dio lo que necesitaba, aunque en principio me molesta la idea del formato de registro binario. Has visto esto recientemente cuando depuré el problema de la computadora portátil borrada. Tema similar.
diarioctl --boot=-1
Aquí, revisé las líneas, buscando errores. Si bien systemctl no ayudó antes, con este comando, finalmente me encontré con el problema crítico de arranque:
11 de julio 13:55:07 tester systemd[1]:Montaje de /boot/efi...
11 de julio 13:55:07 tester mount[899]:montaje:/boot/efi:tipo de sistema de archivos desconocido 'vfat '.
11 de julio 13:55:07 tester systemd[1]:boot-efi.mount:proceso de montaje finalizado, código=salido, estado=32/n/a
11 de julio 13:55:07 tester systemd[1]:boot-efi.mount:error con el resultado 'código de salida'.
11 de julio 13:55:07 tester systemd[1]:no se pudo montar /boot/efi.
11 de julio 13:55:07 tester systemd[1]:la dependencia falló para los sistemas de archivos locales.
11 de julio 13:55:07 tester systemd[1]:local-fs.target:El trabajo local-fs.target/start falló con el resultado 'dependencia'.
11 de julio 13:55:07 tester systemd[1]:local-fs.target:activación de dependencias OnFailure=.
Muy similar a lo que sucedió hace tres años. Entonces, nuevamente, parece que tenemos un initramfs mal ensamblado, lo que parece estar sucediendo con demasiada frecuencia para mi gusto. Además, está relacionado con la actualización de la versión. Me pregunto qué puede ser tan complicado con el módulo FAT32, pero esa es una pregunta para otra persona. En lo que respecta a los archivos initramfs, tenía lo siguiente en /boot:
ls -ltr initramfs*
-rw-------. 1 root root 73443963 19 de mayo de 2018 initramfs-0-rescue-efe3eec4bb6646fe864735812f4d094b.img
-rw-------. 1 raíz raíz 22953495 2 de abril 15:54 initramfs-5.0.4-200.fc29.x86_64.img
-rw-------. 1 raíz raíz 22961687 20 de mayo 13:11 initramfs-5.0.16-200.fc29.x86_64.img
-rw-------. 1 raíz raíz 23015208 20 de mayo 21:17 initramfs-5.0.16-300.fc30.x86_64.img
El último fue el culpable, mientras que el anterior (arriba) funcionó bien. Independientemente de lo que sucedió durante la actualización, el segundo initramfs se corrompió, sin el módulo vfat para permitir el montaje correcto del sistema de archivos. Por curiosidad, decidí extraer las imágenes para ver las diferencias, lo que confirmó mi sospecha. Nuevamente, este no fue el más trivial de los ejercicios, porque no puedes usar zcat y cpio para extraer los archivos initarmfs como en el pasado, necesitas un combo más complejo:
/usr/lib/dracut/skipcpio initramfs-"versión".img | zcat | cpio-id
Solución
Bueno, aquí tienes varias opciones. Primero, si tiene una segunda copia de Fedora en la misma caja y está funcionando, entonces puede copiar su archivo initramfs y usarlo, como lo hice en Ubuntu en el pasado. Esta no es una opción trivial, pero si la tienes, ¡tienes suerte!
Si no lo hace, entonces los núcleos más antiguos deberían ayudar, como lo hicieron en mi escenario. Luego, puede ejecutar una actualización del sistema o recrear manualmente los archivos initramfs. Puede leer mi artículo de arranque lento de Ubuntu para obtener detalles sobre cómo hacer esto. Si no puede iniciar en ningún otro kernel y no tiene otras instancias de Linux en el host, entonces su última opción es usar la sesión en vivo y luego realizar la recuperación allí, o reinstalar.
Conclusión
Estoy sorprendido y algo consternado por esta situación, todo. El error en sí, la incapacidad de depurar en vivo, el hecho de que esto me sucedió después de una actualización de Fedora (nuevamente), el hecho de que terminé con una distribución que no se puede iniciar después de las actividades ordinarias del sistema, la complejidad general de systemd. Todo esto me deja con una sensación de inquietud.
En 2020, el mundo de la tecnología no es más abstracto, sólido o resistente que hace diez años. Por el contrario, los errores siguen ocurriendo y, cuando se producen, el ecosistema circundante es mucho más difícil de usar y trabajar que en el pasado. Esto hace que la resolución de problemas y la resolución de problemas sean más frustrantes. Así que sí, lo arreglé, y tal vez eso es lo que cuenta, pero entonces no, eso no es lo que cuenta. Una experiencia de usuario perfecta es el objetivo final. Por desgracia, día tras día, el escritorio de Linux se está alejando lentamente de esta noble misión, volviéndose cada vez más irrelevante en el esquema general de las cosas. De todos modos, en el aspecto técnico, espero que este artículo haya sido útil. Cuídate.