Bug#728486: Draft of Resolution for 728486 (lvm/systemd compatibility)
Don Armstrong wrote:
> Below is the current draft of a resolution to resolve 728486. I have
> one current comment in the draft which I would like clarified. [CTTE
> members: please comment/suggest change.] I also expect to change the
> reference to the patch to a newly updated patch with the changes
> suggested in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486#183.
>
> ==BEGIN DRAFT==
>
> When systemd is in operation in conjunction with lvm and lvmetad is
> not in use, lvchange -aay must be called after udevadm --settle which
> is provided by systemd-udev-settle.service, and before (and after)
> encrypted devices are configured (cryptsetup.target).
>
> ==COMMENT==
> Is there any case where udevadm --settle would be required after the
> encrypted devices are configured? Does cryptsetup.target ensure that
> udev has triggered the appropriate rules for the newly configured
> encrypted devices?
> ==END COMMENT==
>
> The patch prepared by Michael Stapelberg <stapelberg@debian.org> in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486#163 installs
> the two systemd unit files necessary to properly configure lvm devices
> when systemd is running, and additionally configures
> systemd-tmpfiles.d to create the lockfile directories required by
> systemd.
>
> Therefore, the CTTE:
>
> A. Overides the objection of the maintainer of lvm (Bastian Blank
> <waldi@debian.org>) to this patch, and directs the maintainer to
> accept this patch or alternatively, authorizes an NMU to implement
> this patch.
>
> B. Further discussion
>
> ==END DRAFT==
>
> This draft is 728486_systemd_and_lvm_incompatibility/draft-dla in git.
Would it also be possible to add a 3rd option to the ballot to overrule
and to use the generator as proposed initially by the systemd
maintainers (and upstream)?
Using the generator would automatically prevents an unneeded (and
expensive) synchronization point (the call to udevadm trigger) during
the boot if lvmetad daemon is actually used on the machine.
Using Condition in the .service file to test if the lvmetad executable
is present on the disk is probably not correct as it can be disabled by
the "use_lvmetad" option in lvm.conf configuration file. The only
purpose of the generator, parse this file and react accordingly to the
use_lvmetad option.
The rational of the generator is explained in the initial commit
message at:
http://www.redhat.com/archives/lvm-devel/2012-July/msg00072.html
Cheers,
Laurent Bigonville
Reply to: