ChanServ changed the topic of #nixos-systemd to: NixOS <3 systemd | https://jitsi.nixcon.net/systemd | Next meeting 08.12.2020 14:00 UTC (every two weeks)
<arianvp>
lukegb: hm
<lukegb>
Heh, I should go and make a minimal testcase
<lukegb>
I worked around it and promptly forgot
<arianvp>
classic =)
<lukegb>
LoadCredential seems relatively new so I'm not surprised it has weird interactions
<arianvp>
I just noticed NixOS doesn't ship `modprobe@.service`; which systemd uses to load modules on demand in quite a few places
<arianvp>
e.g. if you have a RootImage= directive; the unit gets an implicit depenency on modprobe@dm_mod.service
<arianvp>
should we add it?
<arianvp>
andi-: question about linking and C
<arianvp>
So how is the build system smart enough to not link against say libpcre2 anymore in the presence of dlopen ?
<arianvp>
why did it end up as a dependency before; but now not anymore?
<arianvp>
like.... how does stdenv/meson/whatever is deciding this know the difference?
<andi->
arianvp: just entering the shower. Look at the libfido2 shared lib commit.
<arianvp>
ah I see. thanks
<andi->
arianvp: the short answer is to just not link against it and just dlopen it during runtime. IIRC there is also some linker foo where you can tell the dynamic linker to try to look it up during runtime but where it isn't mandatory.. linker black magic.
<andi->
the latter mode I haven't actually used myself but only seen somewhere years ago. It would be much more favorable for our cause as it would require less custom code but not sure how well supported that really is.
<andi->
might have been a custom init section in that project.
<arianvp>
yeh it's a bit baffling to me that you need to write so much manual code for dlopen to work
<arianvp>
with dlsym etc
<andi->
there isn't much manual code..
<andi->
it is mostly the symbols
<andi->
You must declare them some how
<andi->
I am sure you could generate them during build time but then you'd depend on the library again... And that seems to be something they try to avoid.
<andi->
In a while we will see two types of crashes a) dynamic symbol was still NULL because some code path wasn't checked b) symbol versioning mismatch and thus passing the wrong arguments
<andi->
but it really isn't something new. dlopen(3) has been used since forever to allow pluggable features (ffmpeg, libva, opengl, …)
<lukegb>
LibGL :p
<arianvp>
It all is a bit messy to me. Wish nix had better support for t
<arianvp>
for it*
<andi->
arianvp: for what exactly?
<andi->
Have you looked at distri and how they approach these kinds of issue (diregarding that they symlink to /lib …)
<andi->
Another option, this dlopen stuff enables, is us providing things only during runtime. That being good or bad depends on us. We could perfectly well remove all the runtime stuff from the minimal build closure and add it to the minimal system closure instead..
<andi->
If they migrate their cryptsetup dependency onto dlopen we might be able to get rid of the systemdMinimal hack
<andi->
obviously all those supposedly existing nixpkgs on non-nixos users (according to eelco) would then have a systemd that doesn't support pcre2 grep, fido, … but I really only care about NixOS users here (for now).
<lukegb>
Why do we have a systemdMinimal
<ajs124>
lukegb: AFAIK because we would enventually like to have systemd in our initrd and we don't want the full thing, with all its dependencies, there.
<lukegb>
Aaaaah, yes, that makes sense
<andi->
no
<andi->
it is more because we can't build systemd without systemd
<andi->
it is for bootstrapping systemd's dependencies
<andi->
a bunch of stuff out there requires udev and those are require to build systemd but systemd is udev..
<andi->
so we build a very stripped down version of systemd to just have udev + a few other things and then rebuild systemd (and it's dependencies) with the proper packages again..
elvishjerricco has quit [Ping timeout: 260 seconds]
elvishjerricco has joined #nixos-systemd
<lukegb>
andi-: wat
<andi->
lukegb: software, it is hard.
<kloenk>
Anyone did something on systemd in initrd recently?