web-dev-qa-db-fra.com

débogage `Panique du noyau - pas de synchronisation: Tentative de tuer init!`

Après avoir accepté une mise à jour du noyau, mon système a cessé de fonctionner. Les commandes sur le terminal (telles que ls, cd, etc.) ne fonctionnaient pas et renvoyaient un message d'erreur command not found, tout en essayant d'utiliser l'interface graphique pour toute action.

J'ai éteint l'ordinateur de force et, après le redémarrage, j'ai eu une erreur de panique dans le noyau:

[timestamp]Kernel panic - not syncing: Attempted to kill init! exitcode=0x0001000
[timestamp]CPU: 0 PID: 1 Comm: run-init Not tainted 3.19.0-25-generic #26~14.04.1-Ubuntu
[timestamp]Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B150M Pro4S, BIOS P1.10 07/16/2015
[timestamp] ffff88084cd60380 ffff880851727e68 ffffffff817aed00 0000000000002478
[timestamp] ffffffff81a901a8 ffff880851727ee8 ffffffff817a8bc8 ffff880851728000
[timestamp] ffffffff00000010 ffff880851727ef8 ffff880851727e98 ffffffff81c5ee20
[timestamp] Call Trace:
[timestamp]  [<ffffffff817aed00>] dump_stack+0x45/0x57
[timestamp]  [<ffffffff817a8bc8>] panic+0xc1/0x1f5
[timestamp]  [<ffffffff81077ae1>] do_exit+0xa11/0xb00
[timestamp]  [<ffffffff81077c17>] SyS_exit+0x17/0x20
[timestamp]  [<ffffffff817b668d>] system_call_fastpath+0x16/0x1b
[timestamp] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range:0xffffffff80000000-0xffffffffbfffffff)
[timestamp] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0001000

Je n'ai pas paniqué (j'espère que vous aimez le jeu de mots) et j'ai cherché des solutions possibles en ligne, parmi lesquelles j'ai trouvé:


Le problème avec cette approche est que le nouveau noyau semble avoir gâché l’ancien, et si et quand j’utilise le menu GRUB pour sélectionner une version précédente (en mode normal et en mode de récupération), le nouveau Le noyau donne exactement la même erreur.


Mon erreur est similaire, car la commande run-init ne fonctionne pas, mais pas parce qu'un fichier est manquant. Comme dans le cas de l'OP, mon disque fonctionne bien et si j'accède au périphérique à partir d'un LiveOS, je peux trouver tous les répertoires et fichiers binaires.


Les liens font référence à différents systèmes. J'ai donc adapté la solution comme suit, une fois que j'ai démarré la ligne de commande GRUB:

grub> set root=(hd0,1) selinux=0 enforcing=0
grub> linux /boot/vmlinuz-3.19.0-25-generic root=/dev/sda1
grub> initrd /boot/initrd.img-3.13.0-29-generic
grub> boot

Pas vraiment suggérer une solution, mais en soulignant plusieurs diagnostics possibles dont aucun ne semble correspondre à mon problème.


Sorte de non liée à la panique du noyau, mais explique comment démarrer en mode mono-utilisateur à partir du menu GRUB. Cela empêche le lancement de X Server et, espérons-le, me permettrait d'exécuter le noyau.


À ce stade, j'ai trouvé de nombreux diagnostics, essayé de nombreuses solutions et rien ne fonctionnait.

Ce que je (pense que je comprends):

  • Le noyau (nouveau et ancien, en mode de récupération ou non) rencontre un problème pour exécuter la commande run-init.
  • Cela n'a rien à voir avec mon ordinateur, car l'ordinateur fonctionne correctement avec un LiveOS et je peux utiliser une carte graphique, accéder à mon disque, utiliser le clavier et la souris.
  • Cette erreur en est au tout début du démarrage, car essayer de démarrer en mode mono-utilisateur ne fonctionne pas et empêcher le chargement de X server n'a aucun effet.

Ce que j'aimerais comprendre, par ordre d'importance:

  • Est-il possible qu'une nouvelle installation de noyau écrase/écrase l'ancien noyau?
  • Est-ce que quelqu'un est au courant de quelque chose qui me manque/d'autres solutions?
  • Ai-je commis une erreur en appliquant les solutions ci-dessus?
  • Y a-t-il quelque chose que je n'ai pas essayé qui vous vienne à l'esprit?
  • Puis-je installer un nouveau noyau sans tout formater à partir de la console GRUB?
  • Est-il temps de réinstaller le système d'exploitation? (Si vous ne pouvez pas répondre aux questions ci-dessus, je connais déjà la réponse à celle-ci ...)

Lectures supplémentaires

7
Matteo

avoir le même problème avec Trusty (14.04) en essayant de résoudre une unité problème en utilisant un solution trouvé dans une des documentation du bogue.

Ça me rend triste de voir toutes ces recherches aller au "gaspillage" sans même une tentative de réponse. Il doit sûrement y avoir un moyen de résoudre ce problème sans nouvelle installation.


Je ne suis pas encore arrivé à une solution, mais laissez-moi partager ce que peut être l'entrée dans une solution (en partie grâce à ce fil):

  1. Créez un lecteur USB amorçable avec la distribution Ubuntu de votre préférence

  2. Sélectionnez l'option Try Ubuntu

  3. Assurez-vous que votre système de fichiers est utilisable avec e2fsck /dev/your-partition

    • vous pouvez obtenir les informations correctes en exécutant blikd ou fdisk -l
  4. Montez votre partition avec Sudo mount /dev/your-partition /mnt

  5. Accédez à l'environnement de votre racine avec chroot /mnt

  6. Vous devriez maintenant avoir un accès complet à votre système de fichiers.
    C’est à vous d’essayer de corriger ou de récupérer vos données via un lecteur USB ou à l’aide de rsync

J'étais coincé en essayant de reconstruire init via Sudo apt-get install init

il a retourné unable to locate package init et comme pour Sudo apt-get update il a retourné quelque chose comme

Existe-t-il un paquet d'init par défaut pour Ubuntu 14.04?

En essayant de télécharger manuellement, j'ai trouvé une immense liste de paquets d'initialisation ici .

Le seul "init" package que j'ai trouvé est apparemment pour xenial. Puis-je utiliser ce paquet pour installer dans trusty ?


J'essaie toujours de comprendre comment faire en sorte que cela fonctionne. Quelques heures supplémentaires jusqu'à ce que j'avoue ma défaite et commence à sauvegarder mes données sensibles avant de le réinstaller à partir de zéro.

3
Lucas Czepaniki