Am 03.05.2014 14:17, schrieb Todd Goodman: > * 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/
Thanks for the link .... I will keep it in mind ... for now I try to stay as close to the stuff in portage as possible (and it worked until yesterday ;-) ). S
