Kernel panic – not syncing: No init found.

J’indiquais dans un article précédent (à la fin de « Construire son système personnel pour Pandaboard – 1« )  que ce message était pour moi une excellente nouvelle, car il indiquait que le noyau avait correctement démarré, identifié les périphériques et trouvé son système de fichiers initial. Une excellente nouvelle lorsqu’on construit un système embarqué. Pas lorsque le message se présente sur mon poste de travail principal ! Voici donc une mésaventure qui m’est arrivé cette semaine.

Circonstances

Après une longue journée de développement logiciel, de rédaction d’un chapitre de mon prochain livre, et de configuration d’un système live Gnu/Linux dont je vous reparlerai prochainement, j’allais lancer la sauvegarde quotidienne de mon répertoire personnel sur le serveur lorsqu’un popup attire mon regard, indiquant que des mises à jour étaient disponibles pour quelques dizaines de packages de la Fedora 15 que j’utilise. Je valide alors naturellement le téléchargement et la mise à jour de ces packages, tout en fermant mes dernières applications. Le système de mise à jour m’a demandé la confirmation pour l’installation d’une nouvelle version du kernel Linux, ce que j’ai accepté.

Puis, j’ai quitté l’écran des yeux pendant quelques instants, pour préparer la synchronisation de mon répertoire personnel sur un ordinateur portable. J’ignore quelle était exactement la tâche de mise à jour en cours lorsque j’ai aperçu l’écran de mon poste de travail s’éteindre. Ce dernier allait apparemment redémarrer tout seul, ce qui m’a légèrement surpris, mais la mise à jour du noyau nécessite évidemment un reboot du système.

 Sauf que ce reboot s’est mal terminé ! Le message classique du « kernel panic » indiquant qu’il ne pouvait charger le programme init est apparu. J’ai donc essayé successivement un reboot à froid – ordinateur totalement éteint puis rallumé – puis un redémarrage sur les versions précédentes du noyau (dans le menu de choix de Grub), rien n’y fit le système restait incapable de trouver son programme init. J’ai tenté de redémarrer en mode mono-utilisateur en ajoutant (avec le menu Grub) sur la ligne de commande du kernel l’option « single« .

Le fichier /sbin/init (qui correspond sur les Fedora 15 à un lien symbolique vers /bin/systemd) aurait pu être endommagé, aussi ai-je tenté sans grande conviction d’ajouter l’option init=/bin/sh sur la ligne de démarrage du kernel. En vain.

Diagnostic

Arrivé à ce point, une touche d’angoisse commençait à poindre. Ce poste de travail ne comporte que deux partitions : la première contient le système Linux Fedora proprement dit et la seconde mon répertoire de travail personnel. Je ne pouvais m’empêcher d’imaginer la sauvegarde pénible du contenu de cette partition à l’aide d’un outil de récupération plus ou moins convivial, suivi d’une réinstallation du système.

En analysant la situation, on peut quand même déduire quelques éléments :

• Le bootloader fonctionne correctement et charge le noyau, ce n’est donc pas un problème de disque ou de partition.
• Le noyau démarre a priori normalement et ne panique qu’au moment de lancer le processus init. Le comportement est le même pour les deux versions précécentes du kernel, ce n’est donc pas lié au noyau Linux lui-même.
• Le processus /sbin/init ne démarre pas, non plus que /bin/sh. Il y a très peu de chances que ces deux exécutables aient été endommagés simultanément. Dans le doute je pourrais toujours essayer ultérieurement avec d’autres commandes comme /bin/ls, etc.

Mes soupçons se portèrent alors sur les bibliothèques. Il suffit que la bibliothèque C par exemple soit endommagée pour qu’aucun exécutable ne fonctionnent hormis ceux dont l’édition des liens a été réalisée de manière statique, mais il n’y en a pratiquement plus dans les distributions classiques actuelles. Pour vérifier cela, il faut déjà accéder à la partition système incriminée.

J’ai démarré sur un CD-Rom Fedora 15 live que j’avais gravé il y a quelques temps pour mettre mon système à jour. Je conseille vivement de toujours disposer d’un CD live relativement récent pour ce genre de situation où la tension nerveuse aidant on n’a aucune envie de devoir télécharger et graver une nouvelle image dans l’urgence.

Une fois le système live en fonctionnement, j’ai monté manuellement les deux partitions de mon disque dur sur deux répertoires temporaires. J’ai examiné rapidement le contenu des répertoires /bin,  /sbin, /etc, et /lib avec la commande « ls -lrt » qui présente le contenu des répertoires classé par ordre chronologique. Les derniers fichiers listés sont les plus récemment modifiés. L’erreur est apparue rapidement :

# cd /mnt/sda1/lib
# ls -lrt
[...]
-rwxr-xr-x.  1 root root     0  3  juin 16:52 libgcc_s-4.6.0-20110603.so.1
lrwxrwxrwx.  1 root root    28  4  août 05:25 libgcc_s.so.1 -> libgcc_s-4.6.0-20110603.so.1
#  ls -l libgcc*
-rwxr-xr-x.  1 root root 115328 30 mai  20:48 libgcc_s-4.6.0-20110530.so.1
-rwxr-xr-x.  1 root root      0  3 juin 16:52 libgcc_s-4.6.0-20110603.so.1
lrwxrwxrwx.  1 root root     28  4 août 05:25 libgcc_s.so.1 -> libgcc_s-4.6.0-20110603.so.1
#

Visiblement la mise à jour de la bibiothèque libgcc ayant échoué, le fichier visé par le lien symbolique est vide.  Ceci explique que le démarrage des exécutables soit impossible.

Récupération

On peut déjà corriger partiellement le problème en redirigeant le lien symbolique vers la version précédente.

# ln -sf libgcc_s-4.6.0-20110530.so.1 libgcc_s.so.1

Puis, pour vérifier le fonctionnement, je tentai un déplacement chroot vers ma partition système.

# chroot /mnt/sda1
#

Ceci fonctionna et les utilitaires classique (ls, df, rpm) marchèrent correctement.

Toutefois, le problème étant survenu lors d’une mise à jour du système, la base de données des packages devait probablement être en mauvais état. J’ai dû exécuter successivement (de mémoire, je n’ai pas pu faire de capture d’écran).

# yum check

qui m’indiqua qu’il restait une transaction de mise à jour non terminée. Je la complétai donc avec

# yum-complete-transaction

toutefois, des erreurs persistaient et je dus effectuer les opérations suivantes (chacune m’indiquant la suivante à lancer)

# package-cleanup --problems
# package-cleanup --dupes
# rpm -Va --nofiles --nodigest

Enfin, certains conflits persistant entre packages de même nom et de numéros de version différents, je dus terminer le nettoyage avec une série de :

# yum erase nom-du-package

Après retrait du CD live et redémarrage, tout fonctionna à nouveau comme avant. Ouf !

Conclusion

Cette petite mésaventure, heureusement sans conséquences autres qu’un peu de temps perdu, m’a permis de tirer quelques remarques que je présenterai sous forme de conseils :

• Ne jamais paniquer, ne jamais se précipiter et surtout ne jamais tenter de réinstaller quoique ce soit avant d’avoir tout essayé. Il est extrèmement rare qu’un incident logiciel (je ne parle pas de la mort physique d’un disque) bloque irrémédiablement un système Linux. Tant qu’il n’y a pas de fumée ou d’odeur bizarre, il y a un bon espoir de pouvoir remettre tout le système en marche comme précédemment.
• Disposer d’un CD-Rom bootable live de préférence de la même distribution (même version majeure) que votre poste de travail. Il n’est pas très agréable de devoir courir après un CD vierge et un poste libre pour télécharger et graver la version de sauvetage alors que votre poste de travail est apparemment moribond.
• Éviter les mises à jour du système en étant connecté en mode graphique avec plusieurs applications en cours d’utilisation. Et éviter avant-tout de faire une mise à jour du système si les données utilisateur qu’il contient n’ont pas été entièrement sauvegardées. C’est une règle simple, mais rarement respectée d’autant que bon nombre d’environnements de travail nous présentent une fenêtre « 50 mises à jour disponibles » alors que nous venons de commencer notre travail depuis quelques dizaines de minutes…

En respectant ces conseils, et avec un peu de patience et de réflexion, on doit pouvoir redémarrer un système Linux quelque soit le plantage survenu.

1 commentaire »