Debian server ne trouve pas un RAID 1 au premier démarrage

Support Debian
#1

Bonjour, ceci est mon premier post sur ce forum donc si ce n’est pas un endroit approprié pour un problème avec GRUB ou initramfs j’en suis désolé mais je commence à manquer d’options.

Pour un TFE, j’ai besoin d’un serveur principale et j’ai choisi d’utiliser debian qui fonctionne très bien pour l’ensemble du projet cependant le serveur est doté d’un RAID 1 software sur lequel il doit boot et j’ai un problème que je n’arrive pas à m’expliquer:

  • Si le serveur était hors tension, je le met sous tension et démarre: le boot essaye pendant un bon moment de trouver le RAID 1 mais n’y arrive pas et drop dans la console BusyBox

  • Si le serveur était déjà sous tension et a déjà été allumé, le démarrage se passe à merveille…

Je n’arrive pas à comprendre l’origine du problème, qu’il soit software ou hardware… Le RAID a été configuré en suivant ce tutorial: https://wiki.debian.org/DebianInstaller/SoftwareRaidRoot

J’ai trouvé quelques posts avec excatement ce problème dont celui-ci: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616689

Mais les solutions sur cette page ne fonctionne pas pour moi:
J’ai essayé “rootdelay=60”, “lvmwait=/dev/mapper/vg1-foobar_root” et “scsi_mod.scan=sync” mais sans succès (en appliquant update-grub bien sûr)…

Pour Debian en soi je pense m’en sortir mais GRUB et initramfs j’ai plutôt vachement peur de faire une bêtise et devoir recommencer du début (j’ai des backups de certaines configurations mais beaucoup de trucs avec KVM serait à refaire je crois)

Et pour couronner ce problème, la carte mère est vraiment insupportable, c’est une Gigabyte MW21 SE0… C’est le pire BIOS que j’ai jamais vu, elle n’a aucun support et je commence à vraiment redouter que ça vienne d’elle ou d’un paramètre mais impossible d’avoir de la vrai doc dessus. J’ai des doutes à son sujet car une fois le boot a pu fonctionner après mise sous tension car je suis resté genre 20min à parcourir le BIOS…

Le serveur fonctionnant, c’est pas vraiment un problème majeur mais lorsque sera venu le temps de la défense du projet, ça le ferait pas de devoir démarrer deux fois la machine :confused:

#2

On peut avoir des précisions sur la structure des disques (par exemple avec lsblk) et l’état de volumes dans le shell de l’initramfs (par exemple avecblkid, cat /proc/mdstat, pvs, vgs, lvs, attention au clavier QWERTY par défaut si on n’a pas modifié /etc/initramfs-toos/initramfs.conf) ?

#3

Oui bien sûr, merci pour ces commandes qui permettent déjà d’avoir de meilleurs renseignement sur la situation :wink:

Pour le moment j’ai beaucoup d’éléments en transfert sur le réseau géré par le serveur donc je ne peux pas reproduire le problème tout de suite mais voilà déjà les résultats lorsque le serveur tourne sans soucis, au cas où il y aurait déjà quelque chose qui puisse paraitre bizarre:

root@HEH-SC-Server:/home/sangoku# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
└─sda1 8:1 0 931.5G 0 part
└─md0 9:0 0 931.4G 0 raid1
├─vg1-foobar_root 253:0 0 901.6G 0 lvm /
└─vg1-swap 253:1 0 29.8G 0 lvm [SWAP]
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part
└─md0 9:0 0 931.4G 0 raid1
├─vg1-foobar_root 253:0 0 901.6G 0 lvm /
└─vg1-swap 253:1 0 29.8G 0 lvm [SWAP]
sr0 11:0 1 1024M 0 rom

root@HEH-SC-Server:/home/sangoku# blkid
/dev/sda1: UUID=“8a5c2ef5-19aa-70f5-39ea-d50db96b3eec” UUID_SUB=“9050e707-80cc-292c-ca48-d2c94cf8f041” LABEL=“HEH-SC-Server:0” TYPE=“linux_raid_member” PARTUUID=“463c8e28-01”
/dev/sdb1: UUID=“8a5c2ef5-19aa-70f5-39ea-d50db96b3eec” UUID_SUB=“655638b7-71d0-273c-6b5c-8b7a1cf1a854” LABEL=“HEH-SC-Server:0” TYPE=“linux_raid_member” PARTUUID=“477ec4b9-01”
/dev/md0: UUID=“3Y3NXq-4t7O-OEDq-yErB-Cnwe-mVY3-zr7Pgr” TYPE=“LVM2_member”
/dev/mapper/vg1-foobar_root: LABEL=“ROOT” UUID=“3d9b6b34-4542-41fe-bb6e-7fb2123dd243” TYPE=“ext4”
/dev/mapper/vg1-swap: UUID=“69d3d483-1563-43d5-b7e7-2ddea1132d13” TYPE=“swap”

root@HEH-SC-Server:/home/sangoku# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
976629760 blocks super 1.2 [2/2] [UU]
bitmap: 5/8 pages [20KB], 65536KB chunk
unused devices:

root@HEH-SC-Server:/home/sangoku# pvs
PV VG Fmt Attr PSize PFree
/dev/md0 vg1 lvm2 a-- 931.38g 0

root@HEH-SC-Server:/home/sangoku# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
foobar_root vg1 -wi-ao---- 901.58g
swap vg1 -wi-ao---- 29.80g

Je ne pourrais pas recréer le soucis avant au moins demain voir plus tard mais déjà merci pour ces pistes de comparaison :smiley:

#4

Finalement j’ai pu tester aujourd’hui et le résultat des commandes est plutôt déroutant :no_mouth:

blkid ne renvoit rien du tout;

cat /proc/mdstat:
Personalities:
unused devices:

pvs, vgs et lvs renvoient:
"/bin/sh: pvs: not found"
"/bin/sh: vgs: not found"
"/bin/sh: lvs: not found"

Par rapport au séquence de boot opérationnel, il ne me semble pas avoir vu sda et sdb dans la sortie… Comme si les disques n’était pas connecté mais la console face à moi ne peut venir que de là car il n’y a aucun autre périphérique de stockage dans le serveur :disappointed:

#5

Si blkid n’affiche rien dans l’initramfs, c’est qu’a priori le noyau ne détecte pas les disques, donc le problème se situe au plus bas niveau de la chaîne.
Vérifier l’absence de /dev/sd*, le contenu de /proc/partitions, les messages du noyau relatifs à “ata”, “sd”, “scsi”.

Mais comme tu le dis, les disques sont bien détectés par le BIOS ou firmware UEFI puisqu’il arrive à amorcer le chargeur d’amorçage qui arrive à charger le noyau et l’initramfs (en faisant appel aux fonctions d’accès disque du firmware, contrairement au noyau Linux pour la suite du démarrage).

Quel est le type de contrôleur disque listé par lspci -nn ?

Tu écris que le système ne démarre correctement que si la machine était déjà sous tension, mais alors comment arrives-tu à démarrer le système une première fois lorsque la machine était sous tension ?

Note : Si pvs, vgs et lvs ne fonctionnent pas directement dans l’initramfs, il faut les faire précéder de lvm et d’un espace.