* Stefan G. Weichinger <li...@xunil.at> [140503 08:09]: > Am 03.05.2014 13:39, schrieb Stefan G. Weichinger: > > > Booted with "rd.auto=1" and now I also get a funny start job > > running/waiting for /dev/sda1 (/ on the SSD). > > > > Oh my! :-) > > > > pasta now. > > So, back from speed-lunch now ;-) > > While cooking the pasta I got a bit further: > > Box boots now with kernel 3.14.1 and with commented LVs in fstab. > > When I login and check there are no mdadm-raids assembled. > > When I "mdadm -A --scan" they get correctly assembled: > > > # cat /proc/mdstat > Personalities : [raid1] > md4 : active raid1 sdb3[0] sdc6[2] > 52395904 blocks super 1.2 [2/2] [UU] > > md1 : active raid1 sdb6[0] sdc3[1] > 623963072 blocks [2/2] [UU] > > (Don't ask for the strange setup with sdb3/sdc6 and sdb6/sdc3, > historically grown somehow ...) > > "vgchange -ay" then gets me all my LVs. Great so far. > > So the question is, what part of the whole setup should now assemble the > arrays? > > I think, dracut, right? > > So I will now test booting with these funny "rd.auto" kernel line > parameters ... > > Has mdadm.service to be enabled as well? Or is that redundant in a way? > > Stefan
FWIW, I have a similar problem with mdadm and dracut and do something similarly to what's described in: http://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/ Todd
