Summary: | >=sys-fs/lvm2-2.02.98: add systemd support | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Enrico Tagliavini <enrico.tagliavini> |
Component: | [OLD] Core system | Assignee: | Robin Johnson <robbat2> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, ao, base-system, cardoe, dennis, dushistov, erkiferenc, jens, kripton, leho, lists, nikoli, pacho, poncho, pums974, robbat2, systemd |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 448882, 465244, 424637, 468898, 479464 | ||
Attachments: |
add systemd support
add systemd support add systemd support add systemd support add systemd support v2 |
Description
Enrico Tagliavini
2013-01-22 21:59:02 UTC
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 |