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:
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.
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é?
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.
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 
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!
[quote=“MaDJiK”]OK pour la version du noyau, ça se fait même avec l’autocomplétion en fait 
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.
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.
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? 
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).
S’il est foutu autant l’écraser. 
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]
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.
En effet, non pas de RAID.
Merci. Je tente un redémarrage ou y a-t-il autre chose que je peux tester avant?
Je ne vois rien d’autre à faire que redémarrer.
(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! 
Je vous tiendrai au courant bien sûr!)
Ça marche! Gros merci à vous deux, PascalHambourg et vv222. 
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.
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.
Quand un presta fonctionne bien tu peux le dénoncer ça donnera peut être des idées à d’autre 
C’est Firstheberg.
Commercial ou technique, le support est vraiment bien. Avec le succès, ils sont moins arrangeants qu’au début, mais ça reste beaucoup plus souple que les grosses usines comme OVH où on ne sort jamais des limites du contrat.
si c’est résolu, merci d’utiliser la coche verte