[kernel panic] Not syncing. No init found (résolu)

[Nicop]

Bonjour,

Depuis la dernière mise à jour, j'ai l'erreur suivante juste après la sélection d'archlinux dans grub.

Code : Tout sélectionner

Kernel panic - not syncing. No init found. Try passing init = option to kernel. See Linux Documentation /init.txt for guidance. 

Pid : 1, comm : swapper/0 not tainted 3.7.4-1-ARCH #1

C'est une version 64 bits de archlinux. Ce kernel panic est arrivé juste après avoir mis à jour filesystem. La mise à jour ne se faisant pas malgré les indications des news archlinux, et j'avais ce message :

Code : Tout sélectionner

filesystem: /lib exists in filesystem
filesystem: /lib64 exists in filesystem

J'ai donc supprimé /lib (le raccourci), ce qui a fait planter l'ordinateur. J'ai ensuite lancé un disque archlinux (la dernière netinst) pour remettre le raccourci, mais depuis j'ai un kernel panic, même pour le fallback.

J'ai donc chrooté depuis cet netinst une seconde fois pour terminer la mise à jour, avec un --force pour que la mise à jour se fasse, car les fichiers /lib et /lib64 n'étaient associés à aucun programme. J'ai ensuite exécuté mkinitcpio -p linux (ce qui avait réparé un précédant kernel panic) qui s'est exécuté correctement et grub-mkconfig, qui n'a signalé presque aucune erreur, à part le message suivant (/dev/sda4 est ma partition logique sur laquelle il y a mon home, mon root et mon swap archlinux) :

Code : Tout sélectionner

SQUASHFS error: can't find a SQUASHFS superblock on sda4
EXT4-fs (sda4): unable to read superblock

J'ai également vérifié les fichiers /boot/grub/grub.cfg et /etc/fstab pour savoir si les partitions étaient corrects et c'est le cas (j'utilise les UUID directement).

Quelqu'un a une idée sur l'origine du kernel panic ? Je peux vous envoyer le contenu de certains fichiers si vous voulez (grub.cfg, fstab, etc...)

Merci d'avance,

Nicolas

[FoolEcho]

Salut,

J'ai donc supprimé /lib (le raccourci), ce qui a fait planter l'ordinateur.

J'ai donc chrooté depuis cet netinst une seconde fois pour terminer la mise à jour, avec un --force pour que la mise à jour se fasse

Et ce, en dépit de la lecture de l'annonce...

Juste pour le cas où (pour toi c'est trop tard, mais pour d'autres lecteurs, sait-on jamais):
-a priori la mise à jour est transparente pour du i686
-côté x86_64, si /usr/lib64 est en conflit, il faut commencer par mettre à jour les paquets qui auraient éventuellement pu installer quelque chose ici (pour le savoir, pacman -Qo) ;
-et bien sûr... pas de --force/-f !

Quelqu'un a une idée sur l'origine du kernel panic ? Je peux vous envoyer le contenu de certains fichiers si vous voulez (grub.cfg, fstab, etc...)

À tout hasard, on peut voir tes mises à jour d'avant le démarrage du kernel panic (y compris ce qui a suivi dans le chroot) ?
Pour l'erreur du SQUASHFS, je ne sais pas... J'imagine que ce n'est pas étranger au fait d'avoir fait sauter /lib à chaud... Au redémarrage "normal", il n'y a pas eu de vérification du disque (fsck), je serai d'avis d'en faire un... ?

[Ypnose]

Incroyable cette manie du --force alors c'est à proscrire à tout prix (sauf quand les devs le disent).
Sinon FoolEcho, tu as raison. De mon côté (en 64 bits), j'ai fait:

Code : Tout sélectionner

pacman -Syu --ignore glibc,filesystem
pacman -Su

et tout roule

[Nicop]

Merci pour cette réponse rapide.

Effectivement, la mise à jour fonctionne très bien sur du 32bits (mon autre ordinateur est sous Arch et pas de problème à ce niveau-là). Cependant, avant de faire ça, j'ai quand même vérifié qu'aucun programme n'avait de fichier dans /lib et /lib64 avec un pacman -Ql | grep ' /lib' (je ne connaissais pas pacman -Qo). Mais comme je l'ai dit, après avoir supprimé le /lib, et mis à jour glibc de la version 2.17-1 -> 2.

Sinon pour les mises à jour il y avait (je ne mets que les paquets qui ont pu faire un kernel panic, c'est à dire pas les paquets graphiques) :
xf86-video-intel
xorg-server-common
xorg-server
xorg-xsetroot
nvidia-bumblebee
lib32-nvidia-utils-bumblebee
(les deux derniers sont pour les cartes nvidia récentes avec la technologie optimus)

Pour la sda4 elle a l'air vide. Je pense que ce n'est pas grave (je verrai ça avec gparted parce que cfdisk ne la voit pas et fsck me dit qu'elle est vide).

Merci d'avance

[tuxce]

Une question : pourquoi tu relances grub-mkconfig ? Une mise à jour ne modifie rien en relation avec grub.cfg !
Pour ce qui concerne l'erreur, /dev/sda4 ne serait pas ta partition étendue ?

Une piste : tu n'as pas installé systemd-sysvcompat, avant tu avais le init=***systemd et suite au grub-mkconfig, tu l'a plus ...

[Nicop]

J'ai contrôlé le grub.cfg et il semble être identique à celui de mon arch 32bits. Mais le kernel panic date d'avant le forçage de la mise à jour et et grub-mkconfig (il est apparu après que j'ai effacé /lib).

J'ai réinstallé systemd-sysvcompat mais toujours rien.

[tuxce]

Si pacman se lance et qu'il installe, je vois pas bien pourquoi init ne se lancerait pas.
En supposant qu'il devrait se lancer, il ne reste donc que l'erreur de partition. Il faudrait que tu ne montes que la partition signalée par l'argument root= et que tu vérifies :
- si c'est bien la racine
- si elle contient <point de montage>/sbin/init
- si ce dernier se lance

[Nicop]

J'ai résolu le problème.

Je pense que ça venait du fichier fstab. En effet, la partition root se trouvait après le swap et tmpfs. J'avais changé l'ordre, mais je n'avais pas refais de mkinicpio. Ce n'est évidemment qu'une hypothèse, mais c'est celle qui me parait la plus logique dans la mesure où en mettant l'option debug j'avais le message "Failed to execute /init".

Merci pour votre aide.

Nicolas

[benjarobin]

Non le fstab n'a aucune incidence sur le /init qui est sur la partition root et celle-ci est déjà monté en lecture seule par le noyau