[résolu] Kernel panic sur un serveur distant

Support Debian
#1

Bonjour,

Mon serveur web sur un VPS ne veut plus démarrer en mode normal. Le support de l’hébergeur m’a fait rebooté en mode “rescue” et il m’a envoyé ce message d’erreur: imgur.com/n78iffd

En gros “Kernel panic - not syncing unable to mount root fs on unknown-block(0,0)”

Je suis connecté au serveur en mode “rescue” et je ne sais pas du tout quoi faire pour réparer!

Je suis développeur web, pas admin. J’ai pris un VPS pour éviter d’avoir à gérer les problèmes matériels comme sur un dédié, mais là il parait que ce n’est pas le cas.
Je n’ai touché à rien, fait aucune mise à jour. Que faire? :confused:

#2

Mon syslog se termine par cette ligne, pas d’erreur avant:

Feb 24 11:01:41 vps-3210 kernel: [1872947.394380] freshclam[23018]: segfault at 7fb56fdd3296 ip 00007fbd74844589 sp 00007fffb5b23cc8 error 4 in libclamav.so.6.1.23[7fbd74703000+934000]

fsck répond clean sans trop de détail.

#3

Mauvais sujet : le kernel panic n’est que la conséquence de ce qui précède. La ligne importante, c’est “initramfs unpacking failed: no cpio magic”.

L’initramfs (autrefois initrd), c’est un fichier compressé contenant une archive au format cpio (un format d’archive moins connu que tar) de l’arborescence de la racine initiale dont le rôle est de réaliser toutes les opérations nécessaires au montage de la racine finale. Apparemment, ce fichier semble corrompu.

Depuis le système de secours, tu peux chrooter sur la racine de ton système, monter les systèmes de fichiers séparés comme /boot et /usr le cas échéant, et de là vérifier le contenu de l’initramfs avec

(remplacer par la version du noyau installé)
S’il s’avère que ce fichier est corrompu, tu peux le regénérer avec

Un segfault est généralement causé soit par un bug du programme, soit par une corruption de la mémoire ou du disque.
Pour forcer [mono]fsck[/mono] à vérifier un système de fichier démonté proprement il faut utiliser l’option [mono]-f[/mono].

#4

Merci, mais qui a parlé de initramfs? Je ne sais pas ce que c’est!

Entre temps, le support m’a filé un coup de main en examinant mon système. C’est mon fstab qui couillait et empêchait le démarrage, causant cette erreur “Kernel panic”.
Il l’a arrangé et redémarré le serveur en netboot. Il m’a dit de “réparer grub” sinon le problème reviendrait…

Je ne comprends pas comment en modifiant une ligne du fstab j’ai pu causer tout ce bordel, mais bon… Il m’a donné des indications:

#5

Les instructions de ton support reviennent plus ou moins à reconstruire ton initrd, la méthode est juste plus longue que celle proposée par PascalHambourg.
Au passage je soupçonne même qu’elle ne soit pas réalisable, je ne crois pas qu’APT te permette de désinstaller la version du noyau en cours d’utilisation.

#6

Oooh, OK, merci.
Je ne l’ai pas copié, mais le support m’avais écrit “j’ai effectué cette opération hier matin pour un de nos clients infogéré”, donc ça doit fonctionner, mais je vais essayer plutôt la méthode de Pascal alors.

Mais il faut me détailler SVP!
«chrooter sur la racine de ton système, monter les systèmes de fichiers séparés comme /boot et /usr le cas échéant,»

J’ai 3 partitions: système, swap et /home, je ne monte que la 1ère?

[code]mount /dev/sda1 /mnt

Et ceci trouvé sur http://doc.ubuntu-fr.org/chroot, utile?
mount --bind /dev /mnt/dev
mount -t proc /proc /mnt/proc
mount --bind /run /mnt/run

chroot /mnt
lsinitramfs /boot/initrd.img-
[/code]

Version du noyau, c’est avec uname -r?
Dois-je aussi tester les disques avec fsck? Mais comment tout ceci s’est abimé?

#7

C’est la première ligne de ta copie d’écran qui parle d’initramfs, juste avant le kernel panic.
J’en ai donné une description sommaire, mais si tu veux en savoir plus tu peux lire les articles sur Wikipédia et sur le wiki Debian (wiki.debian.org).

Bon, je ne vois pas bien le rapport avec le fstab, qui n’est lu qu’une fois que la racine finale est montée (donc bien après que l’initramfs a été chargé et exécuté avec succès).

Concernant la réparation de GRUB, tu peux vérifier le contenu de /boot/grub/grub.cfg.
D’après ta capture d’écran GRUB démarre bien, je ne vois pas l’intérêt de le réinstaller. Idem pour le noyau puisqu’il se charge bien (sinon il n’y aurait pas de kernel panic). On peut imaginer un corruption très subtile du noyau qui provoquerait le bug qui déclenche l’initramfs, mais cela me semble hautement improbable.

Pour moi, la première étape avant d’aller plus loin est de vérifier la validité de l’initramfs avec lsinitramfs. Pour le chroot, les commandes trouvées sur ubuntu-fr sont bien.

Non, cela affichera la version du noyau actif, celui du système de secours et non celui de ton système. Regarde plutôt les fichiers vmlinuz-* et initrd.img-* présents dans /boot.

#8

Oui, je n’avais pas vu au début!

Pour le fstab, je pense que le support m’a dit ça pour rejeter la faute sur moi.

Je peux afficher /boot/grub/grub.cfg mais je ne sais évidemment pas quoi vérifier dedans!

Pour utiliser lsinitramfs, je ne suis pas obligé de rebooter sur le système de secours, si? Là j’ai essayé tel quel (démarrage netboot avec un noyau distant fait par le support).
OK pour la version du noyau, ça se fait même avec l’autocomplétion en fait :slightly_smiling: mais je ne suis pas avancé:

root@vps-3210:~# lsinitramfs /boot/initrd.img-3.2.0-4-amd64 /boot/initrd.img-3.2.0-4-amd64

Je tente quand même update-initramfs -u -k ? Ou dois-je vraiment redémarrer en mode secours puis chroot?

Grand merci pour votre aide en tout cas!

#9

[quote=“MaDJiK”]OK pour la version du noyau, ça se fait même avec l’autocomplétion en fait :slight_smile: mais je ne suis pas avancé:

root@vps-3210:~# lsinitramfs /boot/initrd.img-3.2.0-4-amd64 /boot/initrd.img-3.2.0-4-amd64[/quote]
S’il s’agit du retour complet de la commande, ton initrd est effectivement corrompu.
La même commande chez moi me liste quelque chose comme 200~300 fichiers.

#10

Si lsinitramfs n’affiche rien d’autre que le nom du fichier, ce n’est pas un initramfs valide. Tu peux donc essayer de le regénérer. S’il n’y a qu’un noyau installé, tu peux simplement exécuter [mono]update-initramfs -u[/mono], sans spécifier la version avec -k. Relance lsinitramfs sur le fichier ensuite pour vérifier le résultat.

#11

OK.
J’ai tenté update, toujours démarré sur le netboot:

root@vps-3210:~# update-initramfs -u -k 3.2.0-4-amd64 update-initramfs: /boot/initrd.img-3.2.0-4-amd64 has been altered. update-initramfs: Cannot update. Override with -t option.

J’override? ou c’est justement parce que je ne suis pas sur le système de secours? :confused:

#12

Oui, override. Oui bien tu le renommes et tu en recrées un nouveau avec [mono]-c -k [/mono] (create) au lieu de -u (update).

#13

S’il est foutu autant l’écraser. :stuck_out_tongue:
Alors j’ai eu 2 avertissements:

root@vps-3210:~# update-initramfs -u -t -k 3.2.0-4-amd64 update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 W: mdadm: /etc/mdadm/mdadm.conf defines no arrays. W: mdadm: no arrays defined in configuration file.

par contre lsinitramfs me donne maintenant plein de fichiers, donc ça a du fonctionner quand même…

[code]/boot/initrd.img-3.2.0-4-amd64
.
init
conf
conf/arch.conf
conf/conf.d
conf/initramfs.conf
conf/mdadm
etc
etc/ld.so.conf.d
etc/ld.so.conf.d/libc.conf
etc/ld.so.conf.d/x86_64-linux-gnu.conf
etc/ld.so.cache
etc/modprobe.d
etc/modprobe.d/fbdev-blacklist.conf
etc/ld.so.conf
etc/mdadm
etc/mdadm/mdadm.conf
etc/udev
etc/udev/udev.conf
run

…

scripts/init-top/all_generic_ide
scripts/local-top
scripts/local-top/ORDER
scripts/local-top/mdadm
[/code]

#14

L’avertissement signale juste qu’il n’y a aucun ensemble RAID logiciel défini alors que mdadm est installé, ce qui est anodin si tu n’utilises pas de RAID logiciel. En effet si la racine ou le swap servant à l’hibernation sont contenus dans des volumes RAID, l’initramfs doit les identifier pour les assembler.

#15

En effet, non pas de RAID.
Merci. Je tente un redémarrage ou y a-t-il autre chose que je peux tester avant?

#16

Je ne vois rien d’autre à faire que redémarrer.

#17

(J’attends demain par contre. J’ai changé les DNS vers mon serveur de secours, mais il y a encore du trafic sur celui-ci et puisqu’il marche, je vais attendre. Désolé pour le suspense! :mrgreen: Je vous tiendrai au courant bien sûr!)

#18

Ça marche! Gros merci à vous deux, PascalHambourg et vv222. :023

#19

Donc la recommandation du support de l’hébergeur de réinstaller grub et le noyau était de l’artillerie lourde par rapport au problème.

#20

En effet. Cela dit, je suis très content de ce petit hébergeur. Il est quand même allé voir sur le serveur. Chez les gros concurrents on m’aurait juste envoyé vers le service d’infogérance payant.