Hi Bastian, Am 16.01.2014 17:38, schrieb Bastian Blank: > systemd ships it's own cryptdisks-early.service and cryptdisks.service. > They do nothing and always succeed. This breaks lvm2, as it expects > this services to do something useful.
.. > This services does not fit in the cryptsetup.target definition, so they > can't be successful. Please make stuff you can't support properly fail. > > There are two possible solutions: > - Make cryptdisks-early.service and cryptdisks.service both fail. > - Make cryptdisks-early.service fail and cryptdisks.service an alias to > cryptsetup.target. This way some dependencies may survive. I've taken a look at all existing init scripts. Only lvm2 references cryptdisks-early. $ grep -E "(Should|Required)-Start.*cryptdisks.*" */*/* cryptsetup/init.d/cryptdisks:# Required-Start: checkroot cryptdisks-early lvm2/init.d/lvm2:# Should-Start: udev mdadm-raid cryptdisks-early multipath-tools-boot As you probably noticed, systemd ships a generator for cryptdisks which dynamically creates units and hooks them up in cryptsetup.target. I still hope we can convince you to ship a systemd service file for lvm2. Not using the static generator and shipping them as static service files would be perfectly fine, fwiw. That service file should then just declare an After=cryptsetup.target. The .service files generated by scripts/lvm2_activation_generator_systemd_red_hat.c already do add such a dependency. Since this only affects lvm2, this looks like the cleanest solution overall. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
