[oe] [meta-oe][PATCH 8/8] lvm2: Move libdevmapper to a separate package

[Patrick Ohly]

On Thu, 2017-03-16 at 16:42 +0100, Patrick Ohly wrote:
> On Sat, 2017-02-18 at 03:10 +0100, Peter Kjellerstedt wrote:
> > This allows, e.g., cryptsetup to use libdevmapper without having to
> > pull in all of lvm2.
> 
> I'm experiencing an issue where both kpartx and cryptsetup hang
> infinitely. For kpartx, I traced it down to the lack of dmsetup udev
> rules in the rootfs, the same problem as in
> https://github.com/docker/docker/issues/22025#issuecomment-243943728
> 
> Adding lvm2 to my image fixed it, but that defeats the purpose of this
> patch... ;-}
> 
> Peter, do you know which parts of lvm2 are needed for kpartx
> +libdevicemapper to work correctly? My initial attempt with moving just
> the udev rules to the libdevicemapper packages was either flawed or
> incomplete.

The rules call dmsetup. Moving that also to libdevicemapper works for
me, see below. Shall I submit that as patch?

diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc b/meta-oe/recipes-support/lvm2/lvm2.inc
index b25d775f1..4804b6fb3 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.inc
+++ b/meta-oe/recipes-support/lvm2/lvm2.inc
@@ -83,14 +83,17 @@ SYSTEMD_AUTO_ENABLE = "disable"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
-FILES_${PN} += "${libdir}/device-mapper/*.so ${nonarch_base_libdir}/udev"
+FILES_${PN} += "${libdir}/device-mapper/*.so"
 FILES_${PN}-scripts = " \
     ${sbindir}/blkdeactivate \
     ${sbindir}/fsadm \
     ${sbindir}/lvmconf \
     ${sbindir}/lvmdump \
 "
-FILES_libdevmapper = "${libdir}/libdevmapper.so.*"
+# Specified explicitly for the udev rules, just in case that it does not get picked
+# up automatically:
+RDEPENDS_${PN} += "libdevmapper"
+FILES_libdevmapper = "${sbindir}/dmsetup ${libdir}/libdevmapper.so.* ${nonarch_base_libdir}/udev/rules.d"
 FILES_libdevmapper-dev = " \
     ${libdir}/libdevmapper.so \
     ${libdir}/pkgconfig/devmapper.pc \


-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.