{"id":1048,"date":"2011-08-05T11:00:21","date_gmt":"2011-08-05T10:00:21","guid":{"rendered":"http:\/\/www.blaess.fr\/christophe\/?p=1048"},"modified":"2017-06-05T03:19:12","modified_gmt":"2017-06-05T02:19:12","slug":"crash-systeme-et-recuperation","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2011\/08\/05\/crash-systeme-et-recuperation\/","title":{"rendered":"Crash syst\u00e8me et r\u00e9cup\u00e9ration"},"content":{"rendered":"

Kernel panic – not syncing: No init found<\/strong>.<\/em><\/p>\n

J’indiquais dans un article pr\u00e9c\u00e9dent (\u00e0 la fin de \u00ab\u00a0Construire son syst\u00e8me personnel pour Pandaboard – 1<\/a>\u00ab\u00a0)\u00a0 que ce message \u00e9tait pour moi une excellente nouvelle, car il indiquait que le noyau avait correctement d\u00e9marr\u00e9, identifi\u00e9 les p\u00e9riph\u00e9riques et trouv\u00e9 son syst\u00e8me de fichiers initial. Une excellente nouvelle lorsqu’on construit un syst\u00e8me embarqu\u00e9. Pas lorsque le message se pr\u00e9sente sur mon poste de travail principal<\/strong> ! Voici donc une m\u00e9saventure qui m’est arriv\u00e9 cette semaine.<\/p>\n

\n\n<\/p>\n

Circonstances<\/h1>\n

Apr\u00e8s une longue journ\u00e9e de d\u00e9veloppement logiciel, de r\u00e9daction d’un chapitre de mon prochain livre, et de configuration d’un syst\u00e8me live<\/em> Gnu\/Linux dont je vous reparlerai prochainement, j’allais lancer la sauvegarde quotidienne de mon r\u00e9pertoire personnel sur le serveur lorsqu’un popup<\/em> attire mon regard, indiquant que des mises \u00e0 jour \u00e9taient disponibles pour quelques dizaines de packages<\/em> de la Fedora 15 que j’utilise. Je valide alors naturellement le t\u00e9l\u00e9chargement et la mise \u00e0 jour de ces packages, tout en fermant mes derni\u00e8res applications. Le syst\u00e8me de mise \u00e0 jour m’a demand\u00e9 la confirmation pour l’installation d’une nouvelle version du kernel Linux, ce que j’ai accept\u00e9.<\/p>\n

Puis, j’ai quitt\u00e9 l’\u00e9cran des yeux pendant quelques instants, pour pr\u00e9parer la synchronisation de mon r\u00e9pertoire personnel sur un ordinateur portable. J’ignore quelle \u00e9tait exactement la t\u00e2che de mise \u00e0 jour en cours lorsque j’ai aper\u00e7u l’\u00e9cran de mon poste de travail s’\u00e9teindre. Ce dernier allait apparemment red\u00e9marrer tout seul, ce qui m’a l\u00e9g\u00e8rement surpris, mais la mise \u00e0 jour du noyau n\u00e9cessite \u00e9videmment un reboot<\/em> du syst\u00e8me.<\/p>\n

\u00a0Sauf que ce reboot<\/em> s’est mal termin\u00e9 ! Le message classique du \u00ab\u00a0kernel panic\u00a0\u00bb indiquant qu’il ne pouvait charger le programme init<\/em> est apparu. J’ai donc essay\u00e9 successivement un reboot<\/em> \u00e0 froid – ordinateur totalement \u00e9teint puis rallum\u00e9 – puis un red\u00e9marrage sur les versions pr\u00e9c\u00e9dentes du noyau (dans le menu de choix de Grub), rien n’y fit le syst\u00e8me restait incapable de trouver son programme init<\/em>. J’ai tent\u00e9 de red\u00e9marrer en mode mono-utilisateur en ajoutant (avec le menu Grub) sur la ligne de commande du kernel l’option \u00ab\u00a0single<\/code>\u00ab\u00a0.<\/p>\n

Le fichier \/sbin\/init<\/code> (qui correspond sur les Fedora 15 \u00e0 un lien symbolique vers \/bin\/systemd<\/code>) aurait pu \u00eatre endommag\u00e9, aussi ai-je tent\u00e9 sans grande conviction d’ajouter l’option init=\/bin\/sh<\/code> sur la ligne de d\u00e9marrage du kernel. En vain.<\/p>\n

Diagnostic<\/h1>\n

Arriv\u00e9 \u00e0 ce point, une touche d’angoisse commen\u00e7ait \u00e0 poindre. Ce poste de travail ne comporte que deux partitions : la premi\u00e8re contient le syst\u00e8me Linux Fedora proprement dit et la seconde mon r\u00e9pertoire de travail personnel. Je ne pouvais m’emp\u00eacher d’imaginer la sauvegarde p\u00e9nible du contenu de cette partition \u00e0 l’aide d’un outil de r\u00e9cup\u00e9ration plus ou moins convivial, suivi d’une r\u00e9installation du syst\u00e8me.<\/p>\n

En analysant la situation, on peut quand m\u00eame d\u00e9duire quelques \u00e9l\u00e9ments :<\/p>\n

    \n
  • Le bootloader fonctionne correctement et charge le noyau, ce n’est donc pas un probl\u00e8me de disque ou de partition.<\/li>\n
  • Le noyau d\u00e9marre a priori<\/em> normalement et ne panique qu’au moment de lancer le processus init<\/em>. Le comportement est le m\u00eame pour les deux versions pr\u00e9c\u00e9centes du kernel, ce n’est donc pas li\u00e9 au noyau Linux lui-m\u00eame.<\/li>\n
  • Le processus \/sbin\/init<\/code> ne d\u00e9marre pas, non plus que \/bin\/sh<\/code>. Il y a tr\u00e8s peu de chances que ces deux ex\u00e9cutables aient \u00e9t\u00e9 endommag\u00e9s simultan\u00e9ment. Dans le doute je pourrais toujours essayer ult\u00e9rieurement avec d’autres commandes comme \/bin\/ls<\/code>, etc.<\/li>\n<\/ul>\n

     <\/p>\n

    Mes soup\u00e7ons se port\u00e8rent alors sur les biblioth\u00e8ques. Il suffit que la biblioth\u00e8que C par exemple soit endommag\u00e9e pour qu’aucun ex\u00e9cutable ne fonctionnent hormis ceux dont l’\u00e9dition des liens a \u00e9t\u00e9 r\u00e9alis\u00e9e de mani\u00e8re statique, mais il n’y en a pratiquement plus dans les distributions classiques actuelles. Pour v\u00e9rifier cela, il faut d\u00e9j\u00e0 acc\u00e9der \u00e0 la partition syst\u00e8me incrimin\u00e9e.<\/p>\n

    J’ai d\u00e9marr\u00e9 sur un CD-Rom Fedora 15 live<\/em> que j’avais grav\u00e9 il y a quelques temps pour mettre mon syst\u00e8me \u00e0 jour. Je conseille vivement de toujours disposer d’un CD live<\/em> relativement r\u00e9cent pour ce genre de situation o\u00f9 la tension nerveuse aidant on n’a aucune envie de devoir t\u00e9l\u00e9charger et graver une nouvelle image dans l’urgence.<\/p>\n

    Une fois le syst\u00e8me live<\/em> en fonctionnement, j’ai mont\u00e9 manuellement les deux partitions de mon disque dur sur deux r\u00e9pertoires temporaires. J’ai examin\u00e9 rapidement le contenu des r\u00e9pertoires \/bin<\/code>,\u00a0 \/sbin<\/code>, \/etc<\/code>, et \/lib<\/code> avec la commande \u00ab\u00a0ls -lrt<\/code>\u00a0\u00bb qui pr\u00e9sente le contenu des r\u00e9pertoires class\u00e9 par ordre chronologique. Les derniers fichiers list\u00e9s sont les plus r\u00e9cemment modifi\u00e9s. L’erreur est apparue rapidement :<\/p>\n

     <\/p>\n

    # cd \/mnt\/sda1\/lib<\/strong>\n# ls -lrt<\/strong>\n[...]\n-rwxr-xr-x.  1 root root     0<\/strong>  3  juin 16:52 libgcc_s-4.6.0-20110603.so.1\nlrwxrwxrwx.  1 root root    28  4  ao\u00fbt 05:25 libgcc_s.so.1 -> libgcc_s-4.6.0-20110603.so.1\n#  ls -l libgcc*<\/strong>\n-rwxr-xr-x.  1 root root 115328 30 mai  20:48 libgcc_s-4.6.0-20110530.so.1\n-rwxr-xr-x.  1 root root      0  3 juin 16:52 libgcc_s-4.6.0-20110603.so.1\nlrwxrwxrwx.  1 root root     28  4 ao\u00fbt 05:25 libgcc_s.so.1 -> libgcc_s-4.6.0-20110603.so.1\n#<\/pre>\n
    Visiblement la mise \u00e0 jour de la bibioth\u00e8que libgcc<\/em> ayant \u00e9chou\u00e9, le fichier vis\u00e9 par le lien symbolique est vide.\u00a0 Ceci explique que le d\u00e9marrage des ex\u00e9cutables soit impossible.<\/p>\n
    R\u00e9cup\u00e9ration<\/h1>\n
    On peut d\u00e9j\u00e0 corriger partiellement le probl\u00e8me en redirigeant le lien symbolique vers la version pr\u00e9c\u00e9dente.<\/p>\n
    # ln -sf libgcc_s-4.6.0-20110530.so.1 libgcc_s.so.1<\/strong><\/pre>\n
    Puis, pour v\u00e9rifier le fonctionnement, je tentai un d\u00e9placement chroot<\/em> vers ma partition syst\u00e8me.<\/p>\n
    # chroot \/mnt\/sda1<\/strong>\n#<\/pre>\n
    Ceci fonctionna et les utilitaires classique (ls<\/code>, df<\/code>, rpm<\/code>) march\u00e8rent correctement.<\/p>\n
    Toutefois, le probl\u00e8me \u00e9tant survenu lors d’une mise \u00e0 jour du syst\u00e8me, la base de donn\u00e9es des packages devait probablement \u00eatre en mauvais \u00e9tat. J’ai d\u00fb ex\u00e9cuter successivement (de m\u00e9moire, je n’ai pas pu faire de capture d’\u00e9cran).<\/p>\n
    # yum check<\/strong><\/pre>\n
    qui m’indiqua qu’il restait une transaction de mise \u00e0 jour non termin\u00e9e. Je la compl\u00e9tai donc avec<\/p>\n
    # yum-complete-transaction<\/strong><\/pre>\n
    toutefois, des erreurs persistaient et je dus effectuer les op\u00e9rations suivantes (chacune m’indiquant la suivante \u00e0 lancer)<\/p>\n
    # package-cleanup --problems<\/strong>\n# package-cleanup --dupes<\/strong>\n# rpm -Va --nofiles --nodigest<\/strong><\/pre>\n
    Enfin, certains conflits persistant entre packages de m\u00eame nom et de num\u00e9ros de version diff\u00e9rents, je dus terminer le nettoyage avec une s\u00e9rie de :<\/p>\n
    # yum erase <\/strong>nom-du-package<\/em><\/pre>\n
    Apr\u00e8s retrait du CD live<\/em> et red\u00e9marrage, tout fonctionna \u00e0 nouveau comme avant. Ouf !<\/p>\n
    Conclusion<\/h1>\n
    Cette petite m\u00e9saventure, heureusement sans cons\u00e9quences autres qu’un peu de temps perdu, m’a permis de tirer quelques remarques que je pr\u00e9senterai sous forme de conseils :<\/p>\n
      \n
    • Ne jamais paniquer, ne jamais se pr\u00e9cipiter et surtout ne jamais tenter de r\u00e9installer quoique ce soit avant d’avoir tout essay\u00e9. Il est extr\u00e8mement rare qu’un incident logiciel (je ne parle pas de la mort physique d’un disque) bloque irr\u00e9m\u00e9diablement un syst\u00e8me Linux. Tant qu’il n’y a pas de fum\u00e9e ou d’odeur bizarre, il y a un bon espoir de pouvoir remettre tout le syst\u00e8me en marche comme pr\u00e9c\u00e9demment.<\/li>\n
    • Disposer d’un CD-Rom bootable live<\/em> de pr\u00e9f\u00e9rence de la m\u00eame distribution (m\u00eame version majeure) que votre poste de travail. Il n’est pas tr\u00e8s agr\u00e9able de devoir courir apr\u00e8s un CD vierge et un poste libre pour t\u00e9l\u00e9charger et graver la version de sauvetage alors que votre poste de travail est apparemment moribond.<\/li>\n
    • \u00c9viter les mises \u00e0 jour du syst\u00e8me en \u00e9tant connect\u00e9 en mode graphique avec plusieurs applications en cours d’utilisation. Et \u00e9viter avant-tout de faire une mise \u00e0 jour du syst\u00e8me si les donn\u00e9es utilisateur qu’il contient n’ont pas \u00e9t\u00e9 enti\u00e8rement sauvegard\u00e9es. C’est une r\u00e8gle simple, mais rarement respect\u00e9e d’autant que bon nombre d’environnements de travail nous pr\u00e9sentent une fen\u00eatre \u00ab\u00a050 mises \u00e0 jour disponibles\u00a0\u00bb alors que nous venons de commencer notre travail depuis quelques dizaines de minutes…<\/li>\n<\/ul>\n
      En respectant ces conseils, et avec un peu de patience et de r\u00e9flexion, on doit pouvoir red\u00e9marrer un syst\u00e8me Linux quelque soit le plantage survenu.<\/p>\n
      ","protected":false},"excerpt":{"rendered":"
      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 […]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-1048","post","type-post","status-publish","format-standard","hentry","category-linux-2"],"_links":{"self":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/1048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/comments?post=1048"}],"version-history":[{"count":1,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/1048\/revisions"}],"predecessor-version":[{"id":5054,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/1048\/revisions\/5054"}],"wp:attachment":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/media?parent=1048"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/categories?post=1048"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/tags?post=1048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}