Am 15.05.2014 14:38, schrieb [email protected]: > Stefan G. Weichinger <[email protected]> wrote: > >> Am 15.05.2014 13:50, schrieb [email protected]: >>> Canek Peláez Valdés <[email protected]> wrote: >>> >>>> On Thu, May 15, 2014 at 1:18 AM, Canek Peláez Valdés <[email protected]> >>>> wrote: >>>>> On Wed, May 14, 2014 at 5:26 PM, <[email protected]> wrote: >>>>> [snip] >>>>>> >>>>>> Well, the workaround sort of worked -- it went through the initrd -- I >>>>>> had debug in the kernel command line, but it did not stop for nothing! >>>>>> When it went to the real root, however it did not activate any of the >>>>>> lvm volumes I had except for what I specified in the kernel command >>>>>> line, causing things not to work well. Also, I noticed that if insisted >>>>>> on using the predictable network names, even though I have >>>>>> /etc/udev/rules.d/70-persistent-net.rules and >>>>>> /etc/udev/rules.d/80-name-slot.rules which work fine in openrc to give >>>>>> me back my eth* names. So all in all, it was a mess and took me to an >>>>>> emergency shell and that was the end of that. I did eventually activate >>>>>> some volumes by lvchange -aay, but obviously that would not work well. >>>>> >>>>> OK, I was a little mystified about why dracut-036 worked on my system >>>>> and 037 didn't. Before I tried any workaround, I wanted to know what >>>>> changed from the previous version to the current one. >>>>> >>>>> So I generated an initramfs with dracut-036-r4 and another one with >>>>> dracut-037-r1, and I tried to see what changed from one to the other. >>>>> The answer is surprisingly easy: in /etc/cmdline.d/, the following >>>>> files where in the 036-r4 version, but not in the 037-r4: >>>>> >>>>> 90crypt.conf >>>>> 90lvm.conf >>>>> 90mdraid.conf >>>>> base.conf >>>>> >>>>> Te contents of those files are (90crypt.conf is empty): >>>>> >>>>> 90lvm.conf >>>>> rd.lvm.lv=vg/vol1 >>>>> rd.lvm.lv=vg/vol4 >>>>> rd.lvm.lv=vg/vol3 >>>>> >>>>> 90mdraid.conf >>>>> rd.md.uuid=f4a59e68:fbe4039f:a39fc86d:e9e91e12 >>>>> >>>>> base.conf >>>>> ro >>>>> >>>>> So I just changed my /etc/default/grub file: >>>>> >>>>> GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd quiet nosplash >>>>> rd.lvm.lv=vg/vol1 rd.lvm.lv=vg/vol4 rd.lvm.lv=vg/vol3 >>>>> rd.md.uuid=f4a59e68:fbe4039f:a39fc86d:e9e91e12" >>>>> >>>>> I regenerated my GRUB2 config, and now again my LVM test system works >>>>> perfectly with the latest dracut version. >>>> >>>> I'm an idiot; I didn't saw the documentation about hostonly_cmdline; >>>> BTW Jc, you used host_cmdline, I think the former is the correct one. >>>> >>>> So, to resume: there is no bug, is just that before hostonly_cmdline >>>> was yes by default, and now is no by default. This change was >>>> documented, but I failed to notice it (and I think the ebuild in >>>> Gentoo should print an einfo message). >>>> >>>> Anyway, I think that explains all my problems; John, I don't know if >>>> it will solve yours. Again: did you used "dracut --print-cmdline" to >>>> get the command line? Also, have you tried to use -H to generate your >>>> initramfs? And finally, have you tried with --hostonly-cmdline? >>> >>> OK, I was looking through the journal output and I think the key to the >>> lvm's not activating is the following: >>> 4 12:54:57 ccs systemd[1]: Got notification message for unit >>> systemd-journald.service >>> 4 12:54:57 ccs systemd[1]: systemd-journald.service: Got notification >>> message from PID 1750 (WATCHDOG=1...) >>> 4 12:54:57 ccs systemd[1]: systemd-journald.service: got WATCHDOG=1 >>> 4 12:54:57 ccs systemd[1]: Received SIGCHLD from PID 2603 (lvm). >>> 4 12:54:57 ccs systemd[1]: Child 2602 (lvm) died (code=exited, >>> status=5/NOTINSSTALLED) >>> 4 12:54:57 ccs systemd[1]: Child 2603 (lvm) died (code=exited, >>> status=5/NOTINSSTALLED) >>> 4 12:54:57 ccs systemd[1]: Child 2610 (lvm) died (code=exited, >>> status=5/NOTINSSTALLED) >>> 4 12:54:57 ccs systemd[1]: Job >>> dev-mapper-linux\x2d\x2dfiles\x2dportage.device/start timed out. >>> >>> So what is not installed? >> >> My search tells me that this might be a misinterpreted return code. >> I might repeat myself but the thread gets quite large now: >> >> Did you enable lvm2-lvmetad.service or socket (and set use_lvmetad=1 in >> lvm.conf)? > Yep, did not see that starting. > >> >> I think you don't have to, I just ask to check. >> >> What release of lvm2, btw? > 105-r2
Would you test downgrading to 2.02.104 for checking if that changes something? Or 2.02.106 ... I find various bugs on b.g.o. around lvm2 .... Stefan
