turn libkmod into a dlopen() dependency, too by poettering · Pull Request #31131 · systemd/systemd

poettering · 2024-01-30T13:59:55Z

No description provided.

poettering · 2024-01-30T17:02:10Z

@mrc0mmand any idea what i might be missing here? i updated test-functions with the libkmod dep, assuming that would make the testsuite work, but that wasn't enough?

mrc0mmand · 2024-01-30T17:21:48Z

@mrc0mmand any idea what i might be missing here? i updated test-functions with the libkmod dep, assuming that would make the testsuite work, but that wasn't enough?

The Testing Farm error is unrelated (that's some post mass rebuild issue). For the Arch Linux one I'll need to prepare a fix for the mkinitcpio hook, since it needs to explicitly pull the libkmod dep in (https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/main/initcpio-install-systemd?ref_type=heads#L127). I'll restart the job once that's done.

mrc0mmand · 2024-01-30T17:59:08Z

Monkey-patched and restarted, hopefully it'll be content this time. Ignore the Testing Farm job for now, I'll try to deal with it later today.

poettering · 2024-01-30T18:06:20Z

@mrc0mmand thank you so much!

mbiebl · 2024-01-30T18:07:48Z

Using dlopen for more "exotic" / less frequently used dependencies seems ok. It does come at a cost though. As you no longer get any automatic shlibs dependency tracking.

In case of libkmod I'm not actually sure if the dlopen approach is the desirable one.

poettering · 2024-01-30T18:11:27Z

Using dlopen for more "exotic" / less frequently used dependencies seems ok. It does come at a cost though. As you no longer get any automatic shlibs dependency tracking.

as mentioned elsewhere before: i am happy to extend ELF metadata declaring such weak deps if there's interest. As i understand people weren't intereste din that (did that change?), but it's the bed you made yourself then.

There's nothing stopping anyone to declare weak deps in ELF notes or so, except politics i guess..

In case of libkmod I'm not actually sure if the dlopen approach is the desirable one.

libkmod is of no use in a container, and it has a surprisingly large dep tree, see the lddtree output in the commit msg. It actually makes a difference...

mbiebl · 2024-01-30T18:16:18Z

none of the deps pulled in by libkmod (zstd,lzma) aren't already pulled in by journald.
If I'm missing something, which part of the "large dependency tree" exactly are you referring to?

mbiebl · 2024-01-30T18:16:58Z

$ ldd /usr/lib/x86_64-linux-gnu/libkmod.so.2
	linux-vdso.so.1 (0x00007ffd930c7000)
	libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fae6c59d000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fae6c56d000)
	libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fae6c000000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fae6be1e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fae6c699000)

mbiebl · 2024-01-30T18:20:11Z

Using dlopen for more "exotic" / less frequently used dependencies seems ok. It does come at a cost though. As you no longer get any automatic shlibs dependency tracking.

as mentioned elsewhere before: i am happy to extend ELF metadata declaring such weak deps if there's interest. As i understand people weren't intereste din that (did that change?), but it's the bed you made yourself then.

It seems you failed to convince maintainers of the relevant domains. This is not something I can comment on, as I was not involved.

daandemeyer · 2024-01-30T18:56:51Z

@poettering Obviously you have to do the dlopen() dance for compression deps as well to make this worth it (which would happen to also be very useful for mkosi-initrd ;) )

mbiebl · 2024-01-30T19:07:34Z

Fwiw, I'd be happy to see more elaborate support for weak ELF deps, as it could be really useful.
But it doesn't exist as of today.

mrc0mmand · 2024-01-30T19:47:08Z

I have a feeling that this breaks Ubuntu CI as well, in a similar fashion to the Arch Linux job:

3188s [    2.468538] Btrfs loaded, crc32c=crc32c-vpmsum, zoned=yes, fsverity=yes
3188s Scanning for Btrfs filesystems
3188s done.
3188s Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
3188s done.
3188s Gave up waiting for root file system device.  Common problems:
3188s  - Boot args (cat /proc/cmdline)
3188s    - Check rootdelay= (did the system wait long enough?)
3188s  - Missing modules (cat /proc/modules; ls /dev)
3188s ALERT!  UUID=0a02b638-bd49-4573-80f4-e676eaf07236 does not exist.  Dropping to a shell!

/cc @bluca

poettering · 2024-01-30T21:50:29Z

@poettering Obviously you have to do the dlopen() dance for compression deps as well to make this worth it (which would happen to also be very useful for mkosi-initrd ;) )

It's already on the TODO list. And yes, I want to in particular the more exotic ones to be dlopen() deps

…y included Some required libraries that used to be statically included are in the process to be opened via `dlopen()`. References: - systemd/systemd#31131 - systemd/systemd#31550 - systemd/systemd#32019 Closes dracutdevs#2642

…y included Some required libraries that used to be statically included are in the process to be opened via `dlopen()`. References: - systemd/systemd#31131 - systemd/systemd#31550 - systemd/systemd#32019

poettering · 2024-04-04T16:00:12Z

maybe adding likmod2 instead of kmod as rpm to opensuse helps? trying again

daandemeyer · 2024-04-04T16:14:58Z

@poettering Note that you can dnf install zypper and then do mkosi -d opensuse -f qemu to reproduce locally.

As it turns out libkmod has quite a bunch of deps, including various compressing libs and similar. By turning this into a dlopen() dependency, we can make our depchain during install time quite a bit smaller. In particular as inside of containers kmod doesn't help anyway as CAP_SYS_MODULE is not available anyway. While we are at it, also share the code that sets up logging/kmod context. After: $ lddtree ./build/systemd systemd => ./build/systemd (interpreter => /lib64/ld-linux-x86-64.so.2) libsystemd-core-255.so => ./build/src/core/libsystemd-core-255.so libaudit.so.1 => /lib64/libaudit.so.1 libcap-ng.so.0 => /lib64/libcap-ng.so.0 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 libm.so.6 => /lib64/libm.so.6 libmount.so.1 => /lib64/libmount.so.1 libblkid.so.1 => /lib64/libblkid.so.1 libseccomp.so.2 => /lib64/libseccomp.so.2 libselinux.so.1 => /lib64/libselinux.so.1 libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 libsystemd-shared-255.so => /home/lennart/projects/systemd/build/src/shared/libsystemd-shared-255.so libacl.so.1 => /lib64/libacl.so.1 libattr.so.1 => /lib64/libattr.so.1 libcap.so.2 => /lib64/libcap.so.2 libcrypt.so.2 => /lib64/libcrypt.so.2 libgcrypt.so.20 => /lib64/libgcrypt.so.20 libgpg-error.so.0 => /lib64/libgpg-error.so.0 liblz4.so.1 => /lib64/liblz4.so.1 libcrypto.so.3 => /lib64/libcrypto.so.3 libz.so.1 => /lib64/libz.so.1 libpam.so.0 => /lib64/libpam.so.0 libeconf.so.0 => /lib64/libeconf.so.0 liblzma.so.5 => /lib64/liblzma.so.5 libzstd.so.1 => /lib64/libzstd.so.1 libc.so.6 => /lib64/libc.so.6 Before: $ lddtree ./build/systemd systemd => ./build/systemd (interpreter => /lib64/ld-linux-x86-64.so.2) libsystemd-core-255.so => ./build/src/core/libsystemd-core-255.so libaudit.so.1 => /lib64/libaudit.so.1 libcap-ng.so.0 => /lib64/libcap-ng.so.0 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 libkmod.so.2 => /lib64/libkmod.so.2 libzstd.so.1 => /lib64/libzstd.so.1 liblzma.so.5 => /lib64/liblzma.so.5 libz.so.1 => /lib64/libz.so.1 libcrypto.so.3 => /lib64/libcrypto.so.3 libgcc_s.so.1 => /lib64/libgcc_s.so.1 libm.so.6 => /lib64/libm.so.6 libmount.so.1 => /lib64/libmount.so.1 libblkid.so.1 => /lib64/libblkid.so.1 libseccomp.so.2 => /lib64/libseccomp.so.2 libselinux.so.1 => /lib64/libselinux.so.1 libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 libsystemd-shared-255.so => /home/lennart/projects/systemd/build/src/shared/libsystemd-shared-255.so libacl.so.1 => /lib64/libacl.so.1 libattr.so.1 => /lib64/libattr.so.1 libcap.so.2 => /lib64/libcap.so.2 libcrypt.so.2 => /lib64/libcrypt.so.2 libgcrypt.so.20 => /lib64/libgcrypt.so.20 libgpg-error.so.0 => /lib64/libgpg-error.so.0 liblz4.so.1 => /lib64/liblz4.so.1 libpam.so.0 => /lib64/libpam.so.0 libeconf.so.0 => /lib64/libeconf.so.0 libc.so.6 => /lib64/libc.so.6

bluca · 2024-04-04T22:57:17Z

jammy-amd64 is back to working in other PRs, trying again here

poettering · 2024-04-05T07:38:16Z

So I take it ubuntu jammy is using their own initrd generator which does not run systemd, but does run systemd-udevd?

I guess it needs to be fixed to pull in libkmod then probably. How can we do this?

bluca · 2024-04-05T08:15:07Z

Ah of course it's initramfstools and it does ldd based resolution like dracut goddamnit

keszybz · 2024-04-05T11:08:01Z

Ah of course it's initramfstools and it does ldd based resolution like dracut goddamnit

So we're waiting for an update there I guess.

keszybz

LGTM, but we need to get the packaging in order.

keszybz · 2024-04-05T11:13:49Z

mkosi / ci (ubuntu, noble):

The following packages have unmet dependencies:
 libtss2-esys-3.0.2-0t64 : Breaks: libtss2-esys-3.0.2-0 (< 4.0.1-7.1ubuntu5)
 libtss2-mu-4.0.1-0t64 : Breaks: libtss2-mu-4.0.1-0 (< 4.0.1-7.1ubuntu5)
 libtss2-rc0t64 : Breaks: libtss2-rc0 (< 4.0.1-7.1ubuntu5)
 libtss2-tcti-device0t64 : Breaks: libtss2-tcti-device0 (< 4.0.1-7.1ubuntu5)
E: Unable to correct problems, you have held broken packages.

Hmmmmmmmmmmmm.

daandemeyer · 2024-04-05T11:14:18Z

mkosi / ci (ubuntu, noble):

The following packages have unmet dependencies:
 libtss2-esys-3.0.2-0t64 : Breaks: libtss2-esys-3.0.2-0 (< 4.0.1-7.1ubuntu5)
 libtss2-mu-4.0.1-0t64 : Breaks: libtss2-mu-4.0.1-0 (< 4.0.1-7.1ubuntu5)
 libtss2-rc0t64 : Breaks: libtss2-rc0 (< 4.0.1-7.1ubuntu5)
 libtss2-tcti-device0t64 : Breaks: libtss2-tcti-device0 (< 4.0.1-7.1ubuntu5)
E: Unable to correct problems, you have held broken packages.

Hmmmmmmmmmmmm.

Not our problem

keszybz · 2024-04-05T11:15:36Z

mkosi / ci (ubuntu, noble):

The following packages have unmet dependencies:
 libtss2-esys-3.0.2-0t64 : Breaks: libtss2-esys-3.0.2-0 (< 4.0.1-7.1ubuntu5)
 libtss2-mu-4.0.1-0t64 : Breaks: libtss2-mu-4.0.1-0 (< 4.0.1-7.1ubuntu5)
 libtss2-rc0t64 : Breaks: libtss2-rc0 (< 4.0.1-7.1ubuntu5)
 libtss2-tcti-device0t64 : Breaks: libtss2-tcti-device0 (< 4.0.1-7.1ubuntu5)
E: Unable to correct problems, you have held broken packages.

Hmmmmmmmmmmmm.

Not our problem

I know. I was just expressing my dismay that this thing is still a thing.

jammy-amd64:

17804s [    2.361886] Btrfs loaded, crc32c=crc32c-intel, zoned=yes, fsverity=yes
17804s Scanning for Btrfs filesystems
17804s done.
17804s Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
17804s done.
17804s Gave up waiting for root file system device.  Common problems:
17804s  - Boot args (cat /proc/cmdline)
17804s    - Check rootdelay= (did the system wait long enough?)
17804s  - Missing modules (cat /proc/modules; ls /dev)
17804s ALERT!  UUID=caa1508a-4bb6-4126-a072-7d5db157c351 does not exist.  Dropping to a shell!

bluca · 2024-04-05T11:20:11Z

Noble is still borked and is starting to stabilize. But yes it would be broken because of initramfstools, like jammy is showing. A temporary quick solution would be to link udev to libkmod, as you don't install udev in containers anyway normally

keszybz · 2024-04-05T12:14:37Z

Noble is still borked and is starting to stabilize. But yes it would be broken because of initramfstools, like jammy is showing. A temporary quick solution would be to link udev to libkmod, as you don't install udev in containers anyway normally

That's not so easy. We have --as-needed probably, which means that if we add the linkage without any use, it'd get dropped anyway.

poettering · 2024-04-05T14:17:36Z

I am kinda tempted to just merge the thing, and ignore the CI for a bit, until somebody fixes that initramfs builder?

bluca · 2024-04-05T14:19:20Z

Please, no, that will make it impossible to get the CI changes done for your other PR, among other things. I'll work out a solution tonight or tomorrow.

bluca · 2024-04-05T22:47:53Z

I have pushed a fix, let's see if it works

bluca · 2024-04-06T12:18:23Z

It works, fortunately the udev hook is in the systemd package repo, so the change is self-contained and doesn't have to come from the initramfs package itself. Jammy is now working, noble has unrelated issues that have nothing to do with this.

poettering added build-system modules-load labels Jan 30, 2024

github-actions Bot added udev util-lib tests meson please-review PR is ready for (re-)review by a maintainer labels Jan 30, 2024

poettering force-pushed the dlopen-kmod branch from 2f96e6d to 802942a Compare January 30, 2024 14:44

bluca added ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR and removed please-review PR is ready for (re-)review by a maintainer labels Jan 30, 2024

poettering force-pushed the dlopen-kmod branch from 802942a to 4e06aca Compare January 30, 2024 15:44

github-actions Bot added please-review PR is ready for (re-)review by a maintainer and removed ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR labels Jan 30, 2024

poettering force-pushed the dlopen-kmod branch from 4e06aca to ed81d34 Compare January 30, 2024 16:03

bluca added ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR and removed please-review PR is ready for (re-)review by a maintainer labels Jan 30, 2024

mrc0mmand removed the ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR label Jan 30, 2024

bluca added the ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR label Apr 4, 2024

poettering force-pushed the dlopen-kmod branch from 758651c to 876ec6e Compare April 4, 2024 15:59

github-actions Bot added please-review PR is ready for (re-)review by a maintainer and removed ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR labels Apr 4, 2024

poettering added 2 commits April 4, 2024 18:16

update TODO

a0ff536

poettering force-pushed the dlopen-kmod branch from 876ec6e to a0ff536 Compare April 4, 2024 16:17

keszybz approved these changes Apr 5, 2024

View reviewed changes

bluca approved these changes Apr 6, 2024

View reviewed changes

dracutng mentioned this pull request Apr 6, 2024

fix(systemd): explicitly install some libs that will not be statically included dracut-ng/dracut#118

Merged

mrc0mmand mentioned this pull request Apr 8, 2024

vagrant(rawhide): explicitly pull libkmod into the initrd systemd/systemd-centos-ci#723

Merged

samy-mahmoudi mentioned this pull request Jul 12, 2024

No keyboard input after building with dracut and systemd 256.1 or 256.2 (at least on Arch Linux) zbm-dev/zfsbootmenu#648

Closed

Conversation

poettering commented Jan 30, 2024

Uh oh!

poettering commented Jan 30, 2024

Uh oh!

mrc0mmand commented Jan 30, 2024

Uh oh!

mrc0mmand commented Jan 30, 2024

Uh oh!

poettering commented Jan 30, 2024

Uh oh!

mbiebl commented Jan 30, 2024

Uh oh!

poettering commented Jan 30, 2024

Uh oh!

mbiebl commented Jan 30, 2024

Uh oh!

mbiebl commented Jan 30, 2024

Uh oh!

mbiebl commented Jan 30, 2024

Uh oh!

daandemeyer commented Jan 30, 2024

Uh oh!

mbiebl commented Jan 30, 2024

Uh oh!

mrc0mmand commented Jan 30, 2024

Uh oh!

poettering commented Jan 30, 2024

Uh oh!

poettering commented Apr 4, 2024

Uh oh!

daandemeyer commented Apr 4, 2024

Uh oh!

bluca commented Apr 4, 2024

Uh oh!

poettering commented Apr 5, 2024

Uh oh!

bluca commented Apr 5, 2024

Uh oh!

keszybz commented Apr 5, 2024

Uh oh!

keszybz left a comment

Choose a reason for hiding this comment

Uh oh!

keszybz commented Apr 5, 2024

Uh oh!

daandemeyer commented Apr 5, 2024

Uh oh!

keszybz commented Apr 5, 2024

Uh oh!

bluca commented Apr 5, 2024

Uh oh!

keszybz commented Apr 5, 2024

Uh oh!

poettering commented Apr 5, 2024

Uh oh!

bluca commented Apr 5, 2024

Uh oh!

bluca commented Apr 5, 2024

Uh oh!

bluca commented Apr 6, 2024

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

9 participants