Installation sur RAID + LVM

Support Debian
#1

Bonjour à tous,
J’ai fait une installation de Debian sur un RAID1 logiciel avec une couche LVM de la manière la plus simple possible : le RAID1 est composé des deux disques entiers, et LVM gère tout ensuite (3 lv : /boot, / et swap). J’ai tout fait avec l’installeur Debian, aucune manip à la main. Petit schema :

                         
          LVM            
    +-------------+      
    |             |      
    |  /boot ext2 |      
    |  /     ext4 |      
    |  swap  swap |      
    +-------------+      
                         
    +-------------+ md0  
                         
    |----|   |----|      
    +----+   +----+      
    sda1      sdb1

Au boot tout se passe bien, je lance ensuite ces deux commandes :

[code]# grub-install /dev/sda

grub-install /dev/sdb[/code]

Pour être sûr que le MBR est OK sur les deux disques.

Mais si je débranche un disque, n’importe lequel, mon système ne boote pas. En effet Grub apparaît et commence à démarrer mais il affiche rapidement ce message :

Begin: Running /scripts/local-block ... Volume group "vg0" not found Skipping volume groupe vg0 Unable to find LVM volume vg0/rootfs done.

Et ça boucle…
Si je remet le disque manquant et que je redémarre, ça fonctionne à nouveau.
Le disque importe peu, que ce soit l’un ou l’autre, Debian ne boote pas si les deux ne sont pas présents.

Est-ce qu’il manque quelque chose ?

Merci

#2

Je me réponds à moi-même, j’ai trouvé ces commandes pour démarrer quand le serveur est bloqué sur l’initramfs:

code

mdadm --stop /dev/md0

mdadm --assemble --scan

vgchange -ay

exit[/code]

Donc il semble que le problème soit bien du à mdadm qui ne monte pas son array si un disque est manquant… il y a un moyen de lui dire de le faire quand même ?

Parce que si un disque claque et que le serveur redémarre, il sera bloqué et dans l’urgence pas sûr qu’on retrouve les 4 commandes citées précédemment :confused:

#3

Pourquoi dois-tu arrêter /dev/md0 en premier ? Dans quel état est-il lorsque le shell de l’initramfs se lance ?

cat /proc/mdstat mdadm --detail /dev/md0

#4

[quote=“PascalHambourg”]Pourquoi dois-tu arrêter /dev/md0 en premier ? Dans quel état est-il lorsque le shell de l’initramfs se lance ?

cat /proc/mdstat mdadm --detail /dev/md0[/quote]
Il est en état “Inactive” :confused:

EDIT : Je peux aussi faire :

[code]# mdadm -R /dev/md0

vchange -ay

exit[/code]

Ainsi plus besoin de faire le stop.

#5

D’accord. Je viens de tester avec Jessie et je constate le même problème, alors que je ne l’avais jamais rencontré avec une version antérieure de Debian. Le bug #784070 a été ouvert pour un problème indentique. L’auteur du rapport a son RAID sur des disques partitionnés au format GPT et il se trouve que ceux sur lesquels j’ai testé aussi mais je ne vois pas en quoi c’est lié. Tes disques en RAID sont ils partitionnés au format GPT ou MBR/MSDOS ?

Le bug semble lié à l’assemblage incrémental des ensembles RAID par udev (voir dans [mono]/lib/udev/rules.d/md-raid[/mono]) qui est activé dans Jessie mais était désactivé auparavant. C’est lui qui crée les ensembles incomplets mais les met dans l’état inactif. Visiblement il attend que tous les membres définis comme actifs dans les superblocs soient présents pour activer l’ensemble. Ce que ne fait pas l’assemblage traditionnel ([mono]–assemble[/mono]). Ce qui est gênant, c’est que l’assemblage automatique traditionnel qui est quand même effectué par le script [mono]/scripts/local-top/mdadm[/mono] de l’initramfs ne démarre pas les ensembles existants qui sont dans l’état inactif malgré l’option [mono]–run[/mono].

Un facteur atténuant est que si les membres du disque manquant ont été marqués comme “faulty” avant le redémarrage, comme cela devrait se produire lors d’une vraie panne, alors le problème ne se produit pas car l’assemblage incrémental n’attend pas la présence des membres déclarés “faulty”.

#6

Merci pour ton implication.
Moi c’est en MBR (j’ai laissé l’installeur Debian tout faire, et je n’ai pas démarré en UEFI).

#7

J’ai envoyé un mail au bug Debian référencé ci-dessus pour confirmer le problème, tu peux en faire de même.