En analysant le paquet dmraid je trouve:
Le bloc de règle udev dans /lib/udev/rules.d/97-dmraid.rules contenant notamment
(...)
RUN+="/sbin/dmraid-activate %k"
(...)
RUN+="/sbin/kpartx -a /dev/$kernel"
On y voit la commande d'activation "dmraid-activate" (qui apparaissait comme ayant échouée dans le log du service udev) :
mars 20 19:24:02 julien-GA-880GA-UD3H dmraid-activate[796]: ERROR: Cannot retrieve RAID set information for pdc_bffbjachi
Suivie de la commande kpartx (équivalent de partprobe que je t'ai fait lancer, et qui va chercher s'il y a une table de partition sur un volume) qui n'est donc pas exécutée, en raison de l'échec de l'activation.
Du coup le device raid ne devrait même pas être actif dans /dev/mapper.
Cependant on trouve l'explication probable de l'activation du volume raid, en dépit de l'échec de son activation par udev, dans un script du initramfs: "/usr/share/initramfs-tools/scripts/local-top/dmraid" du paquet. Qui semble être là pour palier à un éventuel échec (plus ou moins prévue donc) de l'activation à ce moment.
(...)
wait_for_udev 30
# Activate any dmraid arrays that were not identified by udev and vol_id.
if devices=$(dmraid -r -c); then
for dev in $devices; do
dmraid-activate $dev
done
fi
Ce script attend max 30 secondes que udev n'ai plus d'évènement à traiter puis explore les dmraid existant et les active, mais
sans faire de sondage de table de partition (pas de commande kpartx).
Conclusion, il semble bien qu'en l'état actuel de linux, le démarrage de ton faike raid soit intrinsèquement aléatoire.
Du coup une solution plus pérenne serait probablement de commencer par aller ajouter dans ce script la commande kpartx (si tant est que l'on puisse savoir quels paramètres lui passer) et refaire les initramfs. Et si ça fonctionne aller déclarer un bug sur lauchpad pour que le paquet soit corrigé. (Autrement à la prochaine mise à jour ça va revenir comme avant)
j'aimerais bien voir ce que retourne la commande
sudo dmraid -r -c
