On Saturday, May 03, 2014 02:08:26 PM Stefan G. Weichinger wrote: > 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 ...)
Seen stranger, it works. What do the logs show when enabling them? Any "odd" messages? > "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? Yes, something there. > So I will now test booting with these funny "rd.auto" kernel line > parameters ... With genkernel, I have a lvm and mdadm boot parameter. With dracut, that might also be necessary. I would prefer the initramfs to do it automagically without extra parameters. > Has mdadm.service to be enabled as well? Or is that redundant in a way? That's systemd-specific. Don't know. If dracut sorts that, mdadm.service might be too much. But, as those are not boot-critical, they might wait for the real system to be running. In that case, you do need mdadm.service as well. -- Joost
