Il y a trois ans, j'ai écrit un article expliquant comment récupérer d'un démarrage raté suite à une mise à jour majeure de la version de Fedora. A cette époque, je travaillais avec Fedora 25, et du coup, je n'arrivais plus à accéder au bureau. Le problème s'est avéré être un bogue initramfs, qui est un problème que je n'ai rencontré qu'une seule fois dans le passé, de retour dans Ubuntu, en 2009. Depuis, c'est calme.
Eh bien, la roue du temps nous a renvoyés au début. Le même problème s'est reproduit. J'avais (un peu) récemment mis à niveau une instance de Fedora 29 vers Fedora 30, et voilà, je me suis retrouvé face au même problème. Presque. J'ai eu un écran noir, et un message qui disait :Impossible d'ouvrir l'accès à la console, le compte root est verrouillé. À ce stade, essayer de faire quoi que ce soit n'a donné aucun résultat. Je n'ai pu que redémarrer. J'ai essayé un autre noyau, et cela m'a aidé - je suis arrivé sur mon bureau. Bien que le problème semble être similaire, j'ai dû adopter une méthode légèrement différente pour le résoudre.
Symptômes du problème plus en détail
Je me suis retrouvé assez perplexe face au manque d'outils de diagnostic accessibles ou d'un environnement utilisable dans lequel je pourrais résoudre le problème. Devoir redémarrer signifie perdre des informations éventuellement précieuses. À tout le moins, je pouvais démarrer dans d'autres noyaux, ce qui signifiait que j'avais quelque chose avec quoi travailler.
Dans le dernier noyau 1, j'ai d'abord essayé de suivre mes propres conseils d'il y a deux ans, mais la commande systemctl status boot-efi.mount n'a rien montré d'utile. Je suis toujours perplexe devant la fragilité, la complexité et le manque de convivialité du nouveau cadre de démarrage moderne. Le numéro précédent m'a incité à écrire mon article Progress through complexity, et ses conclusions sont toujours valables, des années plus tard.
L'obstacle le plus simple est la disponibilité des informations sous /var/log. Au bon vieux temps de l'initialisation, vous y trouviez généralement les éléments suivants :syslog/messages, boot, old boot et kernel logs. Il s'agissait de fichiers texte que vous pouviez facilement et instantanément inspecter avec cat, less, peu importe.
Dans Fedora, vous obtenez certains - mais pas tous ces fichiers. Par exemple, boot.log est là, mais alors :
sudo less boot.log
"boot.log" peut être un fichier binaire. Vous le voyez quand même ?
Curieusement, c'est un fichier texte (avec quelques caractères bizarres), et vous pouvez réellement l'afficher avec cat. Mais ce fichier n'a fourni aucune information utile qui m'aiderait à identifier le problème.
J'ai ensuite passé un peu plus de temps à lire différentes options pour journalctl, et cela vous donne la possibilité de voir les journaux de démarrage précédents. Vous pouvez le faire en fournissant une valeur entière négative pour voir les anciens journaux. Ce n'est pas très intuitif, mais au moins cela m'a donné ce dont j'avais besoin, bien que je déteste en principe l'idée du format de journal binaire. Vous l'avez vu récemment lorsque j'ai débogué le problème de l'ordinateur portable en panne. Thème similaire.
journalctl --boot=-1
Ici, j'ai parcouru les lignes, à la recherche d'erreurs. Bien que le truc systemctl n'ait pas aidé plus tôt, avec cette commande, j'ai finalement rencontré le problème de démarrage critique :
11 juillet 13:55:07 testeur systemd[1] :Montage de /boot/efi...
11 juillet 13:55:07 testeur mount[899] :montage :/boot/efi :type de système de fichiers inconnu 'vfat '.
11 juillet 13:55:07 testeur systemd[1] :boot-efi.mount :processus de montage terminé, code=exited, status=32/n/a
11 juillet 13:55:07 testeur systemd[1] :boot-efi.mount :Échec avec le résultat "code de sortie".
11 juillet 13:55:07 testeur systemd[1] :Échec du montage de /boot/efi.
11 juillet 13:55:07 testeur systemd[1] :échec de la dépendance pour les systèmes de fichiers locaux.
11 juillet 13:55:07 testeur systemd[1] :local-fs.target :la tâche local-fs.target/start a échoué avec le résultat "dépendance".
11 juillet 13:55:07 testeur systemd[1] :local-fs.target :déclenchement des dépendances OnFailure=.
Très similaire à ce qui s'est passé il y a trois ans. Encore une fois, nous semblons avoir un initramfs mal assemblé, ce qui semble se produire beaucoup trop souvent à mon goût. De plus, il est corrélé à la mise à niveau de la version. Je me demande ce qui peut être si délicat avec le module FAT32, mais c'est une question pour quelqu'un d'autre. En ce qui concerne les fichiers initramfs, j'avais ce qui suit sous /boot :
ls -ltr initramfs*
-rw-------. 1 racine racine 73443963 19 mai 2018 initramfs-0-rescue-efe3eec4bb6646fe864735812f4d094b.img
-rw-------. 1 racine racine 22953495 2 avril 15:54 initramfs-5.0.4-200.fc29.x86_64.img
-rw-------. 1 racine racine 22961687 20 mai 13:11 initramfs-5.0.16-200.fc29.x86_64.img
-rw-------. 1 racine racine 23015208 20 mai 21:17 initramfs-5.0.16-300.fc30.x86_64.img
Le dernier était le coupable, tandis que celui d'avant (ci-dessus) fonctionnait bien. Quoi qu'il se soit passé pendant la mise à jour, le deuxième initramfs a été corrompu, sans le module vfat pour permettre le montage correct du système de fichiers. Par curiosité, j'ai décidé d'extraire les images pour voir les différences - ce qui a confirmé mes soupçons. Encore une fois, ce n'était pas l'exercice le plus trivial, car vous ne pouvez pas utiliser zcat et cpio pour extraire les fichiers initarmfs comme par le passé, vous avez besoin d'un combo plus complexe :
/usr/lib/dracut/skipcpio initramfs-"version".img | zcat | cpio -id
Solution
Eh bien, vous avez plusieurs options ici. Premièrement, si vous avez une deuxième copie de Fedora sur la même boîte et qu'elle fonctionne, vous pouvez copier son fichier initramfs et l'utiliser, comme je l'ai fait dans Ubuntu à l'époque. Ce n'est pas une option anodine, mais si vous l'avez, vous avez de la chance !
Si vous ne le faites pas, les anciens noyaux devraient vous aider - comme ils l'ont fait dans mon scénario. Ensuite, vous pouvez exécuter une mise à jour du système ou recréer manuellement les fichiers initramfs. Vous pouvez lire mon article sur le démarrage lent d'Ubuntu pour plus de détails sur la façon de procéder. Si vous ne pouvez pas démarrer dans un autre noyau et que vous n'avez pas d'autres instances Linux sur l'hôte, votre dernière option est d'utiliser la session en direct, puis d'y effectuer la récupération - ou de réinstaller.
Conclusion
Je suis surpris et quelque peu consterné par cette situation - tout cela. L'erreur elle-même, l'impossibilité de déboguer en direct, le fait que cela m'est arrivé après une mise à jour de Fedora (encore une fois), le fait que je me suis retrouvé avec une distribution non démarrable après des activités système ordinaires, la complexité globale de systemd. Tout cela me laisse un sentiment de malaise.
En 2020, le monde de la technologie n'est pas plus abstrait, robuste ou résilient qu'il ne l'était il y a dix ans. Au contraire, les erreurs continuent de se produire, et lorsqu'elles se produisent, l'écosystème environnant est beaucoup plus difficile à utiliser et à travailler que par le passé. Cela rend le dépannage et la résolution de problèmes plus frustrants. Alors oui, je l'ai corrigé, et c'est peut-être ce qui compte, mais non, ce n'est pas ce qui compte. Une expérience utilisateur transparente est l'objectif final. Hélas, jour après jour, le bureau Linux s'éloigne lentement de cette noble mission, devenant de plus en plus hors de propos dans l'ordre des choses. Quoi qu'il en soit, sur le plan technique, j'espère que cet article vous a été utile. Prenez soin de vous.