Bug#1015174: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0

[Raphael Hertzog]

Control: tags -1 + patch
Control: user de...@kali.org
Control: usertags -1 + kali-patch

On Sun, 17 Jul 2022 05:50:20 +0200 Cyril Brulebois  wrote:
> I suppose the journal bits could be patched out for the udeb build (right
> now, configure ends up defining SYSTEMD_JOURNAL_SUPPORT to 1 there), but
> I'm not sure what consequences disabling APP_MACHINEID_SUPPORT in the udeb
> could have for arrays built at installation time (the function call itself
> is already guarded within an #ifdef/#endif block, so it seems somewhat
> optional already).

I confirm that a build with this patch gets rid of the libsystemd0
dependency in the udeb:

diff --git a/debian/rules b/debian/rules
index f1a9df9bd..bef9b2df3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -71,6 +71,8 @@ define CONFARGS.udeb
--with-pool=none
--disable-readline
--disable-selinux
+   --disable-app-machineid
+   --disable-systemd-journal
 endef
 
 BUILDS :=

I looked up the impact of --disable-app-machineid and I concluded that it
should be safe to use it even if the non-udeb build has it enabled.

The option only adds a supplementary source (named "appmachineid") for lvm
to get a "system_id". The DEFAULT_SYSTEM_ID_SOURCE is "none" and it's not
overriden by what we ship as Debian configuration files. Given that it was
non-existent up-to-now, we can be pretty sure that d-i is not overriding
the lvm configuration to set global/system_id_source to "appmachineid".

man lvmsystemid has some explanation about the feature related to
"systemid" and from a quick check on my system, it looks like that
VG created by d-i do not set any system id.

Bastian, do you agree with the above assessment? If yes, can you upload
a fixed package please?

Cheers,
-- 
Raphaël Hertzog

Bug#1015174: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0

[Philip Hands]

I presume this is also the cause of this failure when installing Debian-EDU:

   https://openqa.debian.net/tests/64605#step/grub/3

If one looks at the associated syslog, here:

   https://openqa.debian.net/tests/64605#step/grub/31

one can see various symptoms of libsystemd0's absence:

...
Jul 16 14:43:44 anna[2159]: DEBUG: resolver (libsystemd0): package doesn't 
exist (ignored)
...
Jul 16 14:43:58 main-menu[423]: (process:4065): pvs: error while loading shared 
libraries: libsystemd.so.0: cannot open shared object file: No such file or 
directory
...

resulting in the failure to create the volume group, seen in the initial
screenshot above.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#1015174: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0

[Cyril Brulebois]

Package: lvm2-udeb
Version: 2.03.15-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debian-b...@lists.debian.org

[ Please keep debian-boot@ cc'd. ]

Hi,

lvm2-udeb is no longer installable, which causes some d-i images to fail
to build:

The following packages have unmet dependencies:
 lvm2-udeb : Depends: libsystemd0 (>= 251.2) but it is not installable

This also causes some issues at runtime (even though it seems a little
strange to get that far, despite the dependency issue):
  https://lists.debian.org/debian-boot/2022/07/msg00015.html

A naive check (grepping in debian/*-udeb after an lvm2 build in unstable)
suggests that only /sbin/lvm in lvm2-udeb pulls such a NEEDED dependency
on libsystemd.so.0, for those symbols:

U sd_id128_get_machine_app_specific@LIBSYSTEMD_233
U sd_journal_printv_with_location@LIBSYSTEMD_209
U sd_journal_send_with_location@LIBSYSTEMD_209

I suppose the journal bits could be patched out for the udeb build (right
now, configure ends up defining SYSTEMD_JOURNAL_SUPPORT to 1 there), but
I'm not sure what consequences disabling APP_MACHINEID_SUPPORT in the udeb
could have for arrays built at installation time (the function call itself
is already guarded within an #ifdef/#endif block, so it seems somewhat
optional already).

Feel free to let us know, and whether you'd like us to try and come up
with a tentative patch.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant