Tre anni fa, ho scritto un articolo che spiegava come eseguire il ripristino da un avvio non riuscito a seguito di un importante aggiornamento di versione in Fedora. A quel tempo stavo lavorando con Fedora 25 e all'improvviso non ero più in grado di accedere al desktop. Il problema si è rivelato essere un buggy initramfs, un problema che ho riscontrato solo una volta in passato, in Ubuntu, nel 2009. Da allora, è stato tranquillo.
Ebbene, la ruota del tempo ci ha riportato indietro all'inizio. Lo stesso problema si è verificato di nuovo. Ho (in qualche modo) aggiornato di recente un'istanza di Fedora 29 a Fedora 30, ed ecco, mi sono ritrovato ad affrontare lo stesso problema. Quasi. Avevo una schermata nera e un messaggio che diceva:Impossibile aprire l'accesso alla console, l'account di root è bloccato. A questo punto, provare a fare qualsiasi cosa non ha prodotto alcun risultato. Potevo solo riavviare. Ho provato un altro kernel e questo ha aiutato:sono arrivato al mio desktop. Anche se il problema sembra essere simile, ho dovuto adottare un modo leggermente diverso per risolverlo.
Sintomi del problema in modo più dettagliato
Mi sono trovato piuttosto perplesso dalla mancanza di strumenti diagnostici accessibili o di un ambiente utilizzabile in cui avrei potuto risolvere il problema. Riavviare significa perdere informazioni possibilmente preziose. Per lo meno, potevo avviare altri kernel, il che significava che avevo qualcosa con cui lavorare.
Nell'ultimo kernel, ho provato per la prima volta a seguire il mio consiglio di due anni fa, ma il comando systemctl status boot-efi.mount non ha mostrato nulla di utile. Rimango sempre perplesso da quanto sia fragile, complesso e non proprio adatto all'uomo il nuovo e moderno sistema di avvio. Il numero precedente mi ha spinto a scrivere il mio articolo Progress attraverso la complessità, e le sue conclusioni sono ancora valide, anni dopo.
L'ostacolo più semplice è la disponibilità di informazioni in /var/log. Ai vecchi tempi di init, in genere si trovavano i seguenti file:syslog/messages, boot, old boot e log del kernel. Si trattava di file di testo che potevi ispezionare facilmente e istantaneamente con cat, less, qualunque cosa.
In Fedora, ne ottieni alcuni, ma non tutti questi file. Ad esempio, c'è boot.log, ma poi:
sudo less boot.log
"boot.log" potrebbe essere un file binario. Lo vedi comunque?
Stranamente, è un file di testo (con alcuni caratteri strani) e puoi effettivamente visualizzarlo con cat. Ma questo file non ha fornito alcuna informazione utile che mi avrebbe aiutato a individuare il problema.
Ho quindi trascorso un po 'più di tempo a leggere diverse opzioni per journalctl e ti dà la possibilità di vedere i registri di avvio precedenti. Puoi farlo fornendo un valore intero negativo per vedere i vecchi log. Questo non è molto intuitivo, ma almeno mi ha dato ciò di cui avevo bisogno, anche se in linea di principio mi risento dell'idea del formato del registro binario. L'hai visto di recente quando ho eseguito il debug del problema del laptop bloccato. Tema simile.
journalctl --boot=-1
Qui, ho esaminato le righe, alla ricerca di errori. Anche se la cosa systemctl non ha aiutato prima, con questo comando alla fine mi sono imbattuto nel problema di avvio critico:
11 luglio 13:55:07 tester systemd[1]:montaggio /boot/efi...
11 luglio 13:55:07 tester mount[899]:mount:/boot/efi:filesystem sconosciuto tipo 'vfat '.
11 luglio 13:55:07 tester systemd[1]:boot-efi.mount:processo di montaggio terminato, code=exited, status=32/n/a
11 luglio 13:55:07 tester systemd[1]:boot-efi.mount:non riuscito con il risultato 'exit-code'.
11 luglio 13:55:07 tester systemd[1]:impossibile montare /boot/efi.
11 luglio 13:55:07 tester systemd[1]:dipendenza non riuscita per i file system locali.
11 luglio 13:55:07 tester systemd[1]:local-fs.target:lavoro local-fs.target/start non riuscito con risultato 'dipendenza'.
11 luglio 13:55:07 tester systemd[1]:local-fs.target:Triggering OnFailure=dependencies.
Molto simile a quello che è successo tre anni fa. Quindi, ancora una volta, sembra che abbiamo un initramfs mal assemblato, cosa che sembra accadere troppo spesso per i miei gusti. Inoltre, è correlato all'aggiornamento della versione. Mi chiedo cosa possa esserci di così complicato nel modulo FAT32, ma poi, questa è una domanda per qualcun altro. Per quanto riguarda i file initramfs, ho avuto quanto segue in /boot:
ls -ltr initramfs*
-rw-------. 1 radice radice 73443963 19 maggio 2018 initramfs-0-rescue-efe3eec4bb6646fe864735812f4d094b.img
-rw-------. 1 radice radice 22953495 2 aprile 15:54 initramfs-5.0.4-200.fc29.x86_64.img
-rw-------. 1 radice radice 22961687 20 maggio 13:11 initramfs-5.0.16-200.fc29.x86_64.img
-rw-------. 1 radice radice 23015208 20 maggio 21:17 initramfs-5.0.16-300.fc30.x86_64.img
L'ultimo è stato il colpevole, mentre quello prima (sopra) ha funzionato bene. Qualunque cosa sia accaduta durante l'aggiornamento ha reso corrotto il secondo initramfs, senza il modulo vfat per consentire il corretto montaggio del filesystem. Per curiosità, ho deciso di estrarre le immagini per vedere le differenze, il che ha confermato il mio sospetto. Anche in questo caso, questo non è stato l'esercizio più banale, perché non puoi usare zcat e cpio per estrarre i file initarmfs come in passato, hai bisogno di una combo più complessa:
/usr/lib/dracut/skipcpio initramfs-"versione".img | zcat | cpio -id
Soluzione
Bene, hai diverse opzioni qui. Uno, se hai una seconda copia di Fedora sulla stessa scatola e funziona, puoi copiare il suo file initramfs e usarlo, come ho fatto in Ubuntu in passato. Questa non è un'opzione banale, ma se ce l'hai, sei fortunato!
In caso contrario, i kernel più vecchi dovrebbero aiutare, come hanno fatto nel mio scenario. Quindi, puoi eseguire un aggiornamento del sistema o ricreare manualmente i file initramfs. Puoi leggere il mio articolo sull'avvio lento di Ubuntu per i dettagli su come farlo. Se non riesci ad eseguire l'avvio in nessun altro kernel e non hai altre istanze Linux sull'host, l'ultima opzione è utilizzare la sessione live e quindi eseguire il ripristino lì o reinstallare.
Conclusione
Sono sorpreso e in qualche modo costernato da questa situazione - tutto questo. L'errore stesso, l'impossibilità di eseguire il debug in tempo reale, il fatto che mi sia successo dopo un aggiornamento di Fedora (di nuovo), il fatto che ho finito con una distribuzione non avviabile dopo le normali attività di sistema, la complessità complessiva di systemd. Tutto ciò mi lascia con un senso di disagio.
Nel 2020, il mondo della tecnologia non è più astratto, robusto o resiliente di quanto non fosse dieci anni fa. Al contrario, gli errori continuano a verificarsi e, quando si manifestano, l'ecosistema circostante è molto più difficile da utilizzare e da utilizzare rispetto al passato. Ciò rende la risoluzione dei problemi e la risoluzione dei problemi più frustranti. Quindi sì, l'ho aggiustato, e forse è quello che conta, ma poi no, non è quello che conta. Un'esperienza utente senza interruzioni è l'obiettivo finale. Purtroppo, giorno dopo giorno, il desktop Linux si sta lentamente allontanando da questa nobile missione, diventando sempre più irrilevante nel più ampio schema delle cose. Comunque, dal punto di vista tecnico, spero che questo articolo sia stato utile. Abbi cura di te.