Demi Marie Obenour writes: > On 11/8/25 17:52, Alyssa Ross wrote: >> Demi Marie Obenour writes: >> >>> On 11/8/25 17:37, Alyssa Ross wrote: >>>> Demi Marie Obenour writes: >>>> >>>>> On 11/8/25 17:14, Alyssa Ross wrote: >>>>>> Alyssa Ross writes: >>>>>> >>>>>>> Demi Marie Obenour writes: >>>>>>> >>>>>>>> On 11/8/25 14:49, Alyssa Ross wrote: >>>>>>>>> Demi Marie Obenour writes: >>>>>>>>> >>>>>>>>>> @@ -113,14 +76,15 @@ let >>>>>>>>>> >>>>>>>>>> kernel = linux_latest; >>>>>>>>>> >>>>>>>>>> - appvm = callSpectrumPackage ../../img/app { inherit (foot) terminfo; }; >>>>>>>>>> - netvm = callSpectrumPackage ../../vm/sys/net { inherit (foot) terminfo; }; >>>>>>>>>> + appvm = callSpectrumPackage ../../img/app { inherit (no_pgo_foot) terminfo; }; >>>>>>>>>> + netvm = callSpectrumPackage ../../vm/sys/net { inherit (no_pgo_foot) terminfo; }; >>>>>>>>>> >>>>>>>>>> # Packages that should be fully linked into /usr, >>>>>>>>>> # (not just their bin/* files). >>>>>>>>>> usrPackages = [ >>>>>>>>>> - appvm kernel.modules firmware netvm >>>>>>>>>> - ] ++ (with pkgsGui; [ mesa dejavu_fonts westonLite ]); >>>>>>>>>> + appvm kernel.modules firmware kmod kmod.lib >>>>>>>>>> + netvm mesa dejavu_fonts westonLite >>>>>>>>>> + ]; >>>>>>>>>> >>>>>>>>>> appvms = { >>>>>>>>>> appvm-firefox = callSpectrumPackage ../../vm/app/firefox.nix {}; >>>>>>>>> >>>>>>>>> So based on what we'd discussed previously, I was ready to just apply >>>>>>>>> this and pare down the Nix changes myself since I don't have to worry >>>>>>>>> about rebuilds, etc., but in doing so I came across this. Do you know >>>>>>>>> why kmod.lib is required? Is something impurely dlopening it? Seems >>>>>>>>> very strange, but I did verify that it's required for Weston to start. >>>>>>>> >>>>>>>> systemd uses dlopen heavily. This allows dependencies to be optional >>>>>>>> at runtime. I remember strace showing that systemd-udevd dlopen's >>>>>>>> kmod.lib. In short, your diagnosis is correct. >>>>>>> >>>>>>> Okay, that's a packaging bug in Nixpkgs then. (See e.g. [1].) I'll see >>>>>>> what can be done. >>>>>>> >>>>>>> [1]: https://github.com/NixOS/nixpkgs/commit/2328731ad041735a2260698574ce6599591f33ad >>>>>> >>>>>> I have looked into it a bit and am now even more confused. From what I >>>>>> can see, loading libkmod should be done by libsystemd-shared.so, which >>>>>> has kmod.lib in its RUNPATH. >>>>> >>>>> According to https://wiki.debian.org/RpathIssue, only the RUNPATH of >>>>> the executable is honored. The RUNPATH of libraries is not honored. >>>>> For this to work, libsystemd-shared.so needs to have kmod.lib in its >>>>> RPATH, and udevadm *may* need to not have a RUNPATH. >>>> >>>> Right, so we might need to add --force-rpath to the patchelf invocation. >>>> >>>> I wonder why this doesn't affect every NixOS system, though. They >>>> certainly don't have /usr/lib/libkmod.so.2. >>> >>> Difference between musl and glibc is the first thing that comes to mind. >> >> Was my first thought too, but people (including Yureka, who can maybe >> confirm) have run musl NixOS systems, and I've never heard of this >> problem with them. > > I did the following tests: > > 1. Move kmod and kmod.libs from usrPackages to packages. Module > loading breaks. > > 2. Switch from pkgsGui.systemd (musl) to pkgs.systemd (glibc). > Module loading works again. > > My conclusion is that this problem is specific to musl. > > Would it be okay to merge this with the workaround, and revert it > later when it is no longer needed? You're correct. I asked in #exotic:nixos.org if anybody has encountered anything like this, and I was linked to a musl patch for this very issue[1]. So given there's already been an upstream fixed proposed, I'm fine with adding it to the upstream bug tracking board and doing the workaround for now. [1]: https://inbox.vuxu.org/musl/20251017-dlopen-use-rpath-of-caller-dso-v1-1-46c69eda1473@iscas.ac.cn/