Défaillance de démarrage avec root sur MD (RAID1) + LVM: timing de l'événement udev

Une nouvelle installation de Ubuntu Server 13.10 (x64) a des problèmes de démarrage à partir de son volume racine situé dans md + lvm. J'ai maintenant répondu à une solution, mais j'aimerais mieux comprendre ce qui se passe et quelles solutions il pourrait y avoir.

Étant donné que l'objectif de cette machine est d'expérimenter avec Xen (pour une meilleure compréhension de l'hébergement VM commercial), la machine est assemblée à partir de pièces que j'ai à la main, en particulier: un disque SATA Q6600 + Asus P5QL Pro, 1 To et 500 Go (Bien que le disque de 500 Go soit encore utilisé ailleurs, il sera ajouté plus tard).

Le disque 1TB comporte trois partitions: sda1 a une taille égale à sdb1 sur le disque de 500 Go, sda2 est échangé et la balance dans sda3. Md0 est un volume RAID1 [1] composé de sda1 + sdb1, et le PV disponible pour LVM.

Ubuntu est installé dans deux VL (dom0_root et dom0_homes) dans cette VG (vg_mir) et / boot vit dans dom0_root.

Le problème spécifique se manifeste avec les messages suivants, immédiatement après l'initialisation des disques:

kernel: [ 3.003506] md: bind<sda1> kernel: [ 3.007705] md/raid1:md0: active with 1 out of 1 mirrors kernel: [ 3.007768] md0: detected capacity change from 0 to 499972440064 kernel: [ 3.047284] md0: unknown partition table kernel: [ 3.124709] device-mapper: table: 252:0: linear: dm-linear: Device lookup failed kernel: [ 3.124759] device-mapper: ioctl: error adding target to table kernel: [ 3.125156] device-mapper: table: 252:1: linear: dm-linear: Device lookup failed kernel: [ 3.125196] device-mapper: ioctl: error adding target to table 

Après une pause, il abandonne et tombe dans un shell initramfs. En lançant la commande lvm vgchange -ay initialise avec succès LVM, / dev / mapper est rempli comme prévu, et le système démarre normalement après un ^ D.

En faisant une copie de /lib/udev/rules.d/85-lvm2.rules dans / etc et en insérant un sleep 1 comme indiqué ici:

 SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", \ RUN+="watershed sh -c 'sleep 1; /sbin/lvm vgscan; /sbin/lvm vgchange -a y'" 

(Et reconstruire les initramfs), le système démarre maintenant sans aide, mais c'est une solution plutôt horrible. J'ai essayé de rootwait= avec rootwait= , lvmwait= et scsi_mod.scan=sync les paramètres du noyau comme discuté dans les différents trackers de bug et les publications du blog, mais aucun de ce que j'ai essayé n'a fonctionné. Quelques pages suggèrent que evms est un problème, mais cela ne semble pas être installé. D'autres suggèrent des délais d'attente sur des périphériques de blocage non pertinents, et j'ai même désactivé le lecteur de DVD.

Il semble qu'il existe une sorte de condition de course entre md et lvm, et lvm est invoqué par udev avant que md0 ne soit prêt. Ces arguments du noyau semblent insérer un délai après que lvm a été exécuté, donc aucune quantité d'attente ne les aide parce que les LV ne seront jamais prêts car vgchange a déjà été exécuté (et échoué).

C'est à ce moment-là que j'ai compris le problème. Quelqu'un peut-il proposer une meilleure solution, ou suggérer comment explorer pour trouver plus de problème?

[1] car sdb1 est, en ce moment, manquant, ce volume de raid configuré manuellement pour être RAID1 avec 1 périphérique car Ubuntu n'aime pas le démarrage sur un volume dégradé.

Je viens d'avoir le même problème, avec apparemment le même type de matériel et une nouvelle installation 13.10 x64. Étant moins expérimenté, j'ai passé quelques jours à chercher des modules de kernel manquants, etc., mais après avoir lu votre rapport, je trouve que vgchange -ay à l'invite initramfs busybox rend le système amorçable. Je n'ai pas encore essayé la solution de contournement de retard de 1 sec que vous avez posté (je le ferai), mais je note également le rapport de bogue Debian suivant qui peut être lié:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633024

J'ai eu le même problème et après la recherche, j'ai découvert que cette solution fonctionnait pour moi. J'ai juste dû renommer tous les appareils /dev/md/* /dev/md* dans /etc/mdadm/mdadm.conf et exécuter update-initramfs -u pour mettre à jour les initramfs.