Description of problem: This is a spin-off from #1026860. Quoting comment #9 there: The udev rule file /usr/lib/udev/rules.d/69-dm-lvm-metad.rules contains the following rule: ENV{SYSTEMD_WANTS}="lvm2-pvscan@$major:$minor.service" The rule may or may not be applied depending on conditions tested earlier in the rule file. The udev rule file is present also in the initramfs. The template unit file /usr/lib/systemd/system/lvm2-pvscan@.service is, however, not included in the initramfs. This leads to the following error message during boot: Dec 05 16:22:25 vm1 systemd[1]: Failed to load configuration for lvm2-pvscan@252:2.service: No such file or directory Dec 05 16:22:25 vm1 systemd[1]: Trying to enqueue job lvm2-pvscan@252:2.service/start/replace Dec 05 16:22:25 vm1 systemd[1]: Failed to add job lvm2-pvscan@252:2.service/start: Invalid argument, ignoring. Dec 05 16:22:25 vm1 systemd[1]: dev-block-252:2.device changed dead -> plugged Dec 05 16:22:25 vm1 systemd[1]: sys-devices-pci0000:00-0000:00:06.0-virtio2-block-vda-vda2.device changed dead -> plugged Dec 05 16:22:25 vm1 systemd[1]: Trying to enqueue job lvm2-pvscan@252:2.service/start/fail Version-Release number of selected component (if applicable): systemd-208-9.fc20.x86_64 dracut-034-19.git20131021.fc20.x86_64 lvm2-2.02.103-3.fc20.x86_64 How reproducible: 100% Steps to Reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1026860#c30 I'm assigning this to lvm2, but maybe dracut should be smarter? Maybe the error should just be silenced by including the unit file and adding a ConditionFileIsExecutable=/usr/sbin/pvscan ?
This is already upstream: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=297b8edc050715d563d54cfa34e42bf5909b9a7b Just needs to be packaged. Moving to dracut.
(In reply to Peter Rajnoha from comment #1) > http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/ > ?id=297b8edc050715d563d54cfa34e42bf5909b9a7b What about a different solution: leave the udev rule as-is, and modify the lvm2-pvscan.service to include ConditionFileIsExecutable=/usr/sbin/pvscan, and include the lvm2-pvscan.service file in the initramfs? This will all be much clearer for the *user*, because it'll be logged why the unit is not executed. It just seems more robust to me than sed-ding udev rules.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #2) > (In reply to Peter Rajnoha from comment #1) > > http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/ > > ?id=297b8edc050715d563d54cfa34e42bf5909b9a7b > What about a different solution: leave the udev rule as-is, and modify the > lvm2-pvscan.service to include ConditionFileIsExecutable=/usr/sbin/pvscan, The pvscan is normally available in initramfs as dracut can still do whatever it needs to do with LVM there manually - primarily to activate the volume with the root FS on it. Thing is that we don't install/run lvmetad daemon in initramfs. However, we still need those udev rules (but without the part I seded for dracut) to set certain variables in udev db for proper processing after pivot to root FS (the udev db is moved over from initramfs to root fs). We could probably add lvmetad in initramfs and rely on autoactivation there too, but I don't like that idea - imagine there's some update needed for lvmetad - you'd need to regenerate initramfs as well. And it's quite useless to use lvmetad in initramfs anyway if the only thing is to activate the LV with root FS. So everything can be done later with lvmetad when the root fs itself is mounted. I'd agree with adding the lvm2-pvscan@.service in initramfs if there was anything else than lvm binary path to check that we're in initramfs. Maybe there is something that dracut provides? Some file it writes and it's only specific to dracut environment that is not visible in normal system after pivot to root fs? Dunno... Anyway, even if we did that - would systemd run the service next time then when root fs is running? I mean during "udevadm trigger" that is done at boot to revalidate all devices. Because normally SYSTEMD_WANTS is not applied 2nd or more times, it's only the first time when it's hit in udev rules: === initramfs === - a device which is a PV appears - 69-dm-lvm-metad.rules are evaluated - SYSTEMD_WANTS+="lvm2-pvscan@$major:$minor.service" is assigned - but the service is not run because the condition is not met (the check "we're not in initramfs") === system itself with root fs mounted === - udevadm trigger is run to revalidate any existing devices created before (the systemd-udev-trigger.service), which means that SYSTEMD_WANTS is set again - ???? how would systemd now behave ??? Would it run the lvm2-pvscan service now? Or is this already covered with your latest patch? Since this did not work before - SYSTEMD_WANTS was only validated once. But this may have been changed... I haven't checked yet.
(In reply to Peter Rajnoha from comment #3) > Thing is that we don't install/run lvmetad daemon in initramfs. (the autoactivation and lvm2-pvscan@.service works only if lvmetad is available, otherwise the pvscan --cache -aay is a NOP. Yeah, maybe we should add Requires: lvm2-lvmetad.socket in the lvm2-pvscan@.service, not just the After: lvm2-lvmetad.socket!)
OK, so my idea will not work. > (In reply to Peter Rajnoha from comment #3) > > Thing is that we don't install/run lvmetad daemon in initramfs. > > (the autoactivation and lvm2-pvscan@.service works only if lvmetad is > available, otherwise the pvscan --cache -aay is a NOP. Yeah, maybe we should > add Requires: lvm2-lvmetad.socket in the lvm2-pvscan@.service, not just the > After: lvm2-lvmetad.socket!) This should work. But Requires would pull in the socket... Requisite=lvm2-lvmetad.socket might better.
dracut-034-64.git20131205.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/FEDORA-2013-22831/dracut-034-64.git20131205.fc20
dracut-034-64.git20131205.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.