With systemd/udev 197 lvm /dev symlinks nodes are no more created automatically for me. I asked in #systemd IRC channel and also looked at how fedora 17 and fedora 18 are working. It turns out a systemd generator or a service unit is needed. Reproducible: Always Steps to Reproduce: 1. setup a gentoo box with systemd as init system 2. have an LVM volume marked to automount in fstab like /dev/mapper/vg_schroedingers-lv_home /home ext4 defaults 0 1 3. boot and systemd will fail waiting for the named device 4. drop to a shell and ll /dev/mapper and /dev/VGNAME. the first is empty, the latter doesn't exist I searched for a solution looking at how fedora handles the problem. Fedora 17 uses a systemd generator, included in the upstream lvm2 package. Fedora 18 uses lvmetad to autodiscover, and the systemd unit files are included by default in the upstream lvm2 package. In my opinion the lvmetad solution is likely the better one, in the long term. The systemd generator might be discontinued since fedora/redhat will use lvmetad from now on. But for a short term solution the generator is probably a better idea. I will upload a patch for the last ebuild to add this support.
Created attachment 336524 [details, diff] add systemd support A little disclaimer: this solution is not meant to be final. It is at most a request for comment level, and it is almost not tested given my limited time. It might even boot my system hopefully. This patch add systemd support for the last ~amd64 lvm2 ebuild, version 2.02.98 at the time of writing. It add 2 USE flags: systemd and lvmetad, with the latter masked by default for now. lvmetad USE should be set when the user want to use lvmetad by default with LVM. Setting systemd only will install the generator, setting also lvmetad will install lvmetad systemd unit files. You might ask why this is needed: while it should be technically possible to have both the generator and the lvmetad unit files at the same time, thus having the lvm scan 2 times at boot, this doesn't look good to me. You should have one or the other. Also for testing pourpose it is better to not have the generator, and see the fail if lvmetad doesn't work. But as you can read in the patch, having lvmetad running is not enough. It must be enabled in the lvm.conf file too. Otherwise the boot will probably fail but keep in mind the boot should fail at mounting non root partitions, so you are able to drop to a shell, with your / already mounted in rw and fix this problem very easly (systemd automatically drop to a shell in this case). [The initrd mount / if it is on LVM, not systemd, so the / mount should not fail even if the config is wrong. This needs testing, since e.g. dracut can optionally include lvm.conf in the initramfs. Also genkernel must be checked]. The reason why I say to mask lvmetad for now is the openrc init script is missing, so there is no feature parity with the main gentoo init system, and it is still disabled by default unless enabled in the config file. Worth a bit of testing anyway. This is also the reason why I included the work for lvmetad in this bug instead of filling another one. Note my work for lvmetad is only for systemd support, not for openrc. I think this is the best long term solution, so it is not a separate issue.
tested on ~amd64 box. Fixes booting on machine with /var and /home inside of encrypted lvm. Root partition is on separate device which is not part of that lvm setup. Before using this modification, systemd would time out waiting for lvm volumes to appear. Upon entering the recovery shell, the device nodes would already be available. mount -a allowed to resume boot process, restarting mount services would stall and return to recovery shell. Reinstalling lvm2 with aforementioned lvmetad use flag, enabling lvmetad as a systemd service and in lvm.conf fixes the boot process.
Created attachment 337336 [details, diff] add systemd support This corrects the generator. By default it calls the lvm executable from /usr/sbin but in gentoo it is in /sbin.
Well I think it is time to ask the opinion of the gentoo LVM2 package maintainers, if not even the inclusion in the main portage tree (probably with lvmetad USE masked). I don't see any major problem with this solution right now, but if you see them, please share :)
To be honest, I'd make all the systemd stuff unconditional. AFAICS it's nothing really big, and it doesn't have external deps. Installing the generator or the unit files does not hurt non-systemd systems, and people who really dislike them have INSTALL_MASK for the paths already.
Created attachment 344098 [details, diff] add systemd support Good point, simpler, less problems. This version does that. When USE lvmetad is not set systemd generator is installed in any case. Unit files are for lvmetad only. I'm still not really sure if the generator can be installed even if you use lvmetad. In theory it is not a problem, but just to be sure I'm not enabling it for now.
Hrm, here's my take on this, which I'd try to solve between tonight and tomorrow and then commit: Introducing the lvmetad USE flag without an OpenRC script is a bad idea; I guess I'll need to set up a VM with LVM2 and test it myself (this cannot work with LXC, unfortunately). The "use foo || use bar &&" form is tricky and I honestly don't like it — I'll change it to "{ use foo || use bar; } &&"
(In reply to comment #7) > Introducing the lvmetad USE flag without an OpenRC script is a bad idea; I > guess I'll need to set up a VM with LVM2 and test it myself (this cannot > work with LXC, unfortunately). > > The "use foo || use bar &&" form is tricky and I honestly don't like it — > I'll change it to "{ use foo || use bar; } &&" Yeah as I said lvmetad should be there just to start experiment with that, it might even be masked for now. But I think is worth to start introducing this stuff. About the || && you are right. Better to be strict. Thank you also for the lvmetad openrc init script
(In reply to comment #6) > I'm still not really sure if the generator can be installed even if you use > lvmetad. In theory it is not a problem, but just to be sure I'm not enabling > it for now. http://www.redhat.com/archives/lvm-devel/2012-July/msg00072.html "The lvm2 activation generator generates systemd units conditionally based on the global/use_lvmetad lvm.conf setting. If use_lvmetad=0, the lvm2-activation-early.service and lvm2-activation.service units will be generated. These units are responsible for direct volume activation by calling "vgchange -aay --sysinit" (this is actually the original on-boot activation as it was used before). If use_lvmetad=1, no units will be generated as we're relying on autoactivation."
Created attachment 345712 [details, diff] add systemd support Thank you very much Alexander. I was searching for that, since I was suspecting it. I never had the time to look into it since I was busy with other stuff. This simplify everything: install systemd stuff in any case, the einfo message might be worded better, and the lvmetad init script for openrc is still missing.
Just FYI, I committed a patched ebuild to the systemd-love overlay. Thanks for that!
(In reply to comment #11) > Just FYI, I committed a patched ebuild to the systemd-love overlay. Thanks > for that! Thank you Fabio
The only problem I have with this ebuild (well, the in-tree ebuild doesn't even work...) is that swap on LVM systemd unit activation times out. apr 25 13:40:54 linux systemd[1]: Job dev-disk-by\x2duuid-eb64434e\x2d8bd8\x2d41ae\x2da235\x2d52a6fd91b909.device/start timed out. apr 25 13:40:54 linux systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-eb64434e\x2d8bd8\x2d41ae\x2da235\x2d52a6fd91b909.device. apr 25 13:40:54 linux systemd[1]: Dependency failed for /dev/disk/by-uuid/eb64434e-8bd8-41ae-a235-52a6fd91b909. apr 25 13:40:54 linux systemd[1]: Starting Swap. apr 25 13:40:54 linux systemd[1]: Reached target Swap. This is my fstab entry: UUID=eb64434e-8bd8-41ae-a235-52a6fd91b909 swap swap defaults 0 0 I don't know (yet) if this is related to this bug or not though.
Weird, for me it works. I use an encrypted swap, no idea if this makes any difference /dev/mapper/luks-swap none swap sw 0 0 So I don't use UUIDs here since I use them in crypttab. Also for the rest of fstab I use labels and not UUID. Can you check if the problem happens only with UUIDs?
I tried UUIDs because this didn't work: # /dev/mapper/vg_linux-lv_swap swap swap defaults 0 0 I've seen that the /dev/disk/by-uuid/ (and by-id) symlinks are not generated by udev. I am using a genkernel initramfs, I wonder if it's mdev messing up or we should move some files over to the final root...
On my system /dev/disk/by-* symlinks (by-uuid, by-label, by-id) are not populated for lvm swap partitions.
Output of blkid -p -o udev /dev/mapper/vg_linux-lv_swap: ID_FS_LABEL=swappo ID_FS_LABEL_ENC=swappo ID_FS_UUID=eb64434e-8bd8-41ae-a235-52a6fd91b909 ID_FS_UUID_ENC=eb64434e-8bd8-41ae-a235-52a6fd91b909 ID_FS_VERSION=2 ID_FS_TYPE=swap ID_FS_USAGE=other Output of udevadm info -q all /dev/mapper/vg_linux-lv_swap: P: /devices/virtual/block/dm-1 N: dm-1 E: DEVNAME=/dev/dm-1 E: DEVPATH=/devices/virtual/block/dm-1 E: DEVTYPE=disk E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1 E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 E: MAJOR=251 E: MINOR=1 E: SUBSYSTEM=block E: SYSTEMD_READY=0 E: TAGS=:systemd: E: UDISKS_PRESENTATION_NOPOLICY=1 E: USEC_INITIALIZED=26344 Please note the "SYSTEMD_READY=0" environment variable, which is actually related to the effect I am seeing.
(In reply to comment #16) > On my system /dev/disk/by-* symlinks (by-uuid, by-label, by-id) are not > populated for lvm swap partitions. On my system they are. I just remembered I have another swap partition. The one for my ubuntu system. The symlink is created: schroedingherscat ~ # blkid | grep ubuntuswap /dev/mapper/vg_schroedingers-lv_ubuntuswap: LABEL="ubuntuswap" UUID="cf5b8855-cfa0-4561-96cd-8fa4c72440d0" TYPE="swap" schroedingherscat ~ # ll /dev/disk/by-uuid/cf5b8855-cfa0-4561-96cd-8fa4c72440d0 lrwxrwxrwx 1 root root 10 Apr 25 10:15 /dev/disk/by-uuid/cf5b8855-cfa0-4561-96cd-8fa4c72440d0 -> ../../dm-4 Note: I use dracut as initramfs generator. I point this out since you mentioned genkernel, but I have no idea if this can make a difference or not since I don't know genkernel
So it looks like that mdev is not setting up the environment* for udev/systemd (*udev hwdb)... :S Also see: http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg06402.html
To fix my issue I'd need to replace mdev with udev in the initramfs. :/
Why you are not using dracut?
I confirm that migrating the initramfs to udev (from mdev) and moving /run/udev over to the final root fixes the issue. I will post some patches tomorrow, but they'll be quite invasive.
I committed a working ebuild in the systemd-love overlay [1]. They are less painful that what I thought. I have been able to make possible to embed udev through --udev and eventually removed more cruft from the initramfs generation code: - lvm is now copied from the system (including libs, using copy_binaries()), this because lvm must be compiled with udev support and its udev rules must be placed into the initramfs as well) - dmraid needs lvm, so the above applies to it as well. The only thing I am not happy about is that the initramfs generation code has udev rules.d paths hardcoded, and I wonder if it's possible to query the package manager from there. [1] https://github.com/Sabayon/systemd-love/tree/master/sys-kernel/genkernel
(In reply to comment #20) > To fix my issue I'd need to replace mdev with udev in the initramfs. :/ Bug 330651 ?
(In reply to comment #24) > (In reply to comment #20) > > To fix my issue I'd need to replace mdev with udev in the initramfs. :/ > > Bug 330651 ? Ah.. Sorry, ignore my comment. :)
Created attachment 350132 [details, diff] add systemd support v2 Changes: - install tmpfiles.d config - add check for CONFIG_UEVENT_HELPER_PATH kernel config option (bug 451452) - remove most unconditional configure options from $myconf variable and append them to econf command - add configure option "--with-default-dm-run-dir=/run" - replace "--with-systemdsystemunitdir=$(systemd_get_unitdir)" with "$(systemd_with_unitdir)" - cleanup old patches -- + # when using systemd with lvmetad disabled + # a generator is needed for systemd to create /dev nodes + # note: this should be already build, but I am not sure + # if this is always, or just sometimes, better to force + emake -C scripts lvm2_activation_generator_systemd_red_hat It looks like it always built if sources configured with --enable-applib. But I didn't test this and leave comment and emake as is.
marked my attachment as obsolete since Alexander's version is an improvement :). Thank you for that
Any problem with committing changes from systemd-love overlay in a week?
As the changes are not trivial, I would like to see feedback from maintainer :/
*** Bug 451452 has been marked as a duplicate of this bug. ***
2.02.99 has upstream systemd files now, it's in portage
file new bugs if futher patches are required for the ebuild, thanks
I've just updated lvm2-2.02.99.ebuild again, so wait at least hour before it hits mirrors. Once you see the latest version of it, modify it and create unified diff and file a new bug if futher changes are required. Thank you.
bug 451452 is not a dublicate and it is not fixed yet
