[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

One minor nit for this draft: the ruling should not exclude the
possibility of enhancing LVM in the future to handle dynamically added
devices *without* using systemd-udev-settle.service.  (That may occur by
using lvmetad in cases where it works, for instance.)

Suggested change, if a TC member agrees: leave all the existing content,
but add an additional paragraph right before the "Therefore" saying:
"Nothing in this ruling should be taken to block future changes to LVM
to support dynamic discovery of devices without the need for udevadm
--settle or systemd-udev-settle.service; in the event such changes fully
obsolete the patch in question, the patch may be dropped."

Does that sound reasonable?

- Josh Triplett


Reply to: