Package: lvm2
Version: 2.02.176-4.1
Severity: normal
Dear Maintainer,
We just noted on a fresh Ubuntu 18.04 installation after it failed to
mount the /usr partition on boot, that its /sbin/lvm tool depends on
libraries in /usr/lib. I assumed at first that this bug was local to
Ubuntu, but for the sake of it I installed lvm2 on my Debian desktop
machine (which doesn't use LVM volumes itself) just to investigate
things further.
I was surprised to see that this was the case here also:
$ ldd /sbin/lvm
linux-vdso.so.1 (0x00007ffd681ed000)
libdevmapper-event.so.1.02.1 =>
/lib/x86_64-linux-gnu/libdevmapper-event.so.1.02.1 (0x00007f6367766000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0
(0x00007f63676da000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f63676ba000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f63676b5000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f6367663000)
libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
(0x00007f63673f8000)
libreadline.so.5 => /lib/x86_64-linux-gnu/libreadline.so.5
(0x00007f63671b4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6366ff7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f6366fd6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6366fcc000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f6366da6000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f6366b89000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20
(0x00007f6366a69000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6368039000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f6366a60000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
(0x00007f6366838000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f63666a4000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f6366676000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
(0x00007f6366652000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f63665de000)
The liblz4.so.1 library, coming from liblz4-1, causes an /sbin ->
/usr/lib dependency which is bad because it means the LVM binaries are
unable to be used before /usr is mounted.
I briefly looked in the FHS to see if this was stated there, but
couldn't find it. Anyway, it seems reasonable that /bin and /sbin depend
on libraries below /lib *only*, so that /usr can be kept on a separate
volume.
(I wonder, but haven't confirmed this, if the root cause on the
above-mentioned Ubuntu 18.04 machine not finding its /usr filesystem by
UUID is this bug. If it _is_, then I think the severity should be bumped
since it essentially makes it impossible to put your /usr partition on
an LVM volume in Debian and Ubuntu, which is rather bad. I find this
unlikely though, since it's reasonable someone else would have spotted
this by now.)
For the record, I briefly looked at the 2.02.133-1ubuntu10 package
provided by Ubuntu 16.04, and it _does not_ have the lz4 dependency, so
maybe this is a bug that has crept into Debian and Ubuntu during the
recent years? If so, it would explain to a certain degree why it hasn't
been reported yet.
$ ldd /sbin/lvm
linux-vdso.so.1 => (0x00007ffd1aff9000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fbc22e05000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbc22676000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007fbc22435000)
libdevmapper-event.so.1.02.1 =>
/lib/x86_64-linux-gnu/libdevmapper-event.so.1.02.1 (0x00007fbc2222e000)
libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
(0x00007fbc21fd5000)
libreadline.so.5 => /lib/x86_64-linux-gnu/libreadline.so.5
(0x00007fbc21d97000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbc219cd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fbc217c5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fbc215a8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbc22c0c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fbc213a3000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
(0x00007fbc21181000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbc20e78000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fbc20c4f000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fbc209df000
Best regards,
Per
-- System Information:
Debian Release: buster/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lvm2 depends on:
ii dmeventd 2:1.02.145-4.1
ii dmsetup 2:1.02.145-4.1
ii libblkid1 2.32.1-0.2
ii libc6 2.27-8
ii libdevmapper-event1.02.1 2:1.02.145-4.1
ii libdevmapper1.02.1 2:1.02.145-4.1
ii liblvm2app2.2 2.02.176-4.1
ii libreadline5 5.2+dfsg-3+b2
ii libsystemd0 239-11
ii libudev1 239-11
ii lsb-base 9.20170808
Versions of packages lvm2 recommends:
ii thin-provisioning-tools 0.7.4-2
lvm2 suggests no packages.
-- no debconf information
