Serveur ne démarre pas sur le noyau 3.16.0-6-amd64 après migration vers debian8

Support Debian
#1

Bonjour à tous et très bonne année 2019,

J’ai un serveur qui tournait sous debian7 et je l’ai migré en debian8.

La migration est passée sans problème mais lors de redémarrage , serveur n’arrive pas à booter sur le nouveau noyau (3.16.0-6-amd64).

J’étais obligé de le démarrer sur l’ancien noyau, celui de debian7 (3.2.0-5-amd64), car avec ce dernier le serveur démarre sans problème.

j’ai cherché mais je n’ai pas trouvé de réponses. y’a t-il un qui a rencontré ce problème ? quelqu’un a une réponse ?

Je vous remercie vraiment par avance.

Bonne journée.

#2

Tu n’aurais pas, par hasard, un message d’erreur qui puisse nous mettre sur la voie ?

#3

Lors de la migration pas eu d’erreur et j’ai suivi la même procédure que j’ai utilisé pour un autre serveur et sur ce dernier il n’y a pas eu de soucis.

Par contre après le démarrage sur l’ancien noyau, dans les logs je voix les erreurs suivantes:

# grep fsck /var/log/syslog
kernel: [   13.753428] EXT3-fs (md1): warning: mounting fs with errors, running e2fsck is recommended
kernel: [   14.463613] EXT2-fs (md0): warning: mounting unchecked fs, running e2fsck is recommended

Je pense j’ai la réponse, d’après “https://www.debian.org/releases/jessie/armhf/release-notes/ch-information.fr.html#systemd-auto-mounts-incompat”, il semble que le problème vient bien de là. le noyau debian8 est strict et refuse de monter le système de fichier en erreur.
quelqu’un peut me confirmer ça ? si Oui, pouvez vous m’aider à corriger ça ? Merci bcp !

#4

Tu peux exécuter e2fsck, comme recommandé…

#5

pour exécuter e2fsck les partitions doivent être démontées et malheureusement je ne peux interrompre le service (c’est un serveur de production).

#6

Hein ? Tu as fait un upgrade de version majeure de Debian sur un serveur en production ? Il ne faut jamais faire ça !
Si tu peux à un moment, je te conseille d’envisager la réinstallation de la machine.

#7

Hein ? Tu as fait un upgrade de version majeure de Debian sur un serveur en production ? Il ne faut jamais faire ça !

Pourquoi pas ? j’en ai déjà fait sur deux serveurs et pas eu de problèmes (bien évidement j’ai pris en compte les changements qui ont lieu sur debian8, ex sur apache, ssh, …)
et j’ai déjà fait l’upgrad de debian6 vers debian7 il y a deux ans sur tous les serveurs et j’ai l’impression que passer de debian7 vers debian8 est plus critiques que celle de debian7 vers debian8.

Dans l’absolu, quant c’est possible, effectivement je préfère partir sur un nouveau système debian8 que de migrer debian7 vers debian8, mais la réinstallation/mise en production me prendra plus du temps.

#8

Quelqu’un peut me confirmer si le problème vient des erreurs du système de fichier? Merci

#9

Décris plutôt ce qui se passe quand le serveur démarre avec le noyau 3.16.

#10

Le screenshot qu’on m’a qu’on m’a founi
image

#11

Ah, oui, ça me rappelle quelque chose. Une différence est que le noyau 3.2 utilise des pilotes distincts pour les systèmes de fichiers ext2, ext3 et ext4 alors que le noyau 3.16 utilise le même pilote ext4 pour tous les systèmes de fichiers ext*, ce qui permet de bénéficier de certaines de ses fonctionnalités même en ext2 et ext3. Or le pilote ext4 est plus strict sur la cohérence entre la taille déclarée par le système de fichiers (visible avec tune2fs -l /dev/md1) et la taille du volume qui le contient (visible dans /proc/partitions ou /proc/mdstat). Evidemment, la taille déclarée ne doit pas être plus grande que celle du contenant.

Ici c’est le programme de vérification/réparation fsck.ext3 (e2fsck) exécuté par l’initramfs du noyau 3.16 qui détecte l’incohérence, avant le montage de la racine par le noyau. Au passage, il ne permet pas de corriger ce type de problème. Je soupçonne que le problème ne se produit pas avec le noyau 3.2 parce que son initramfs généré avec les outils de Wheezy ne lance pas fsck.

Les fois où j’ai vu ce problème avec du RAID, il était causé par une mauvaise mise en place du RAID sur une partition initialement formatée sans RAID, la taille qui manque correspondant à l’espace occupé par les méta-données du RAID.

#12

Non. Non seulement tu as compris ce paragraphe de travers, mais il n’a strictement aucun rapport avec ton erreur.
Le paragraphe dit que systemd (et non le noyau) interrompt le démarrage en cas d’échec d’un montage auto.
Dans ton erreur, c’est l’initramfs (et non systemd ni le noyau) qui interrompt le démarrage à cause de l’échec de la vérification (et non du montage) du système de fichiers racine.

#13

désolé je n’avais pas le temps de répondre plus tôt.
Merci bcp @PascalHambourg, pour vos réponses.
je complète par ce screenshot
image

Et d’après ce que je trouve sur des forums (ex: https://unix.stackexchange.com/questions/205116/wheezy-to-jessie-update-broke-root-software-raid-can-it-be-fixed ), il semble que le problème vient du raid1 soft, pouvez vous me le confirmer ?
Si oui, la correction me semble dangereuse sur un serveur de prod, que pensez vous ?

#14

Cet écran, qui est affiché avant le précédent, ne contient aucune erreur. Par contre il s’agit de l’ancien GRUB legacy (GRUB 1, paquet grub-legacy). La version de GRUB installée par défaut lors d’une nouvelle installation depuis Debian 7 au moins est GRUB 2 (paquet grub-pc).

L’écran nous apprend qu’il y a un système de fichiers /boot séparé, mais on ne peut pas savoir s’il est dans une partition simple ou un ensemble RAID 1 car la gestion du RAID 1 par GRUB legacy relève de la bidouille crade (en gros il le traite comme des partitions simples). De toute façon c’est sans incidence sur le montage de la racine qui intervient bien plus tard.

Je déconseille d’exécuter la commande update-initramfs -a -u qui va reconstruire les initrd de tous les noyaux et risque de provoquer le problème avec le noyau 3.2. L’autre n’apportera rien.

Peux-tu fournir la sortie des commandes suivantes en texte et pas en image ?

fdisk -l
cat /etc/fstab
mdadm --detail /dev/md1
tune2fs -l /dev/md1
#15

Effectivement :

  • il y a bien GRUB legacy car le serveur de base était sur debian6 est migré vers debian7.
  • la partition boot est à part et elle est en raid1 (md0)
#16

Il est possible d’ajouter l’option fastboot ou fsck.mode=skip à la ligne de commande du noyau passée par GRUB pour éviter la vérification du système de fichiers racine. Néanmoins je crains qu’à son tour le noyau refuse de monter le système de fichiers racine à cause de l’incohérence des tailles.