regressions due to patchelf: 0.9 -> 0.10

[yorickvP]

Describe the bug

During stage1: Starting udev [ 0.589855] systemd-udevd[114]: Assertion 'resolve_name_timing >= 0 && resolve_name_timing < _RESOLVE_NAME_TIMING_MAX' failed at src/udev/udev-rules.c:1282, function udev_rules_new(). Aborting.

After this, the system is unable to mount any disks.

To Reproduce Steps to reproduce the behavior:

1. nixpkgs 41af38f
2. boot

Expected behavior A clear and concise description of what you expected to happen. System boots.

Additional context This is on a xen VM with the root pivoted. Config: https://gist.github.com/yorickvP/837cc52589b609803b0d28b3c3369e84

cc: @abbradar

[vcunat]

The problem is avoided now on master after f8a8fc6c7c, but we still need to fix it, so I'm leaving this open.

[vcunat]

I can confirm that the patchelf upgrade #58715 caused this and also some other issues: https://github.com/NixOS/nixpkgs/commit/41af38f3728bd64b80721c44ed1fb019978cbc1b#commitcomment-35178328 though I still fail to understand why/how.

[vcunat]

vscode: the wrapping is the same, but binary gets corrupted by patchelf: https://github.com/NixOS/patchelf/issues/170#issuecomment-533856950 I find it likely that both regressions (and probably more) were caused by these.

For now I downgraded the default patchelf in 4e5b46505, so that we can immediately start integrating the rest of staging-next (security fixes, in particular).

[booxter]

@vcunat thanks for handling the mess. What's the procedure to validate a bump for patchelf before merging it?

[vcunat]

I'm not aware of any such formalities. First we should verify at least some of those known regressions (say, test vscode). Then we might do a run in a separate Hydra jobset, but... I didn't discover this regression by looking at the staging-next jobset and it got to nixpkgs master.

[vvs-]

Just found this issue. I'm unable to install vscode and vscodium with virtual address space underrun! apparently because of patchelf. I'm on NixOS 19.03 i686, though.

[vcunat]

Hmm, I'm getting a different error

git checkout 3f92c2124a5 # current 19.03
env NIXPKGS_ALLOW_UNFREE=1 nix build -f . pkgsi686Linux.vscode
./result/bin/code
# /nix/store/gkbm49f5a096knqphy1iwim024hzvxrx-vscode-1.35.1/lib/vscode/code: error while loading shared libraries: libnode.so: cannot open shared object file: No such file or directory

19.03 always used patchelf 0.9 by default, so I can't see why it would be affected by the very same issue.

Note: on 19.09 and later i686 isn't supported anymore due to upstream: https://github.com/NixOS/nixpkgs/pull/64308#issuecomment-508574483 ... and 19.03 isn't really a supported nixpkgs branch anymore.

[flokli]

I'd really prefer if patchelf from nixpkgs could point to the the latest official release. If vscode and vscodium don't work with the latest patchelf, we could keep a patchelf_0_9 attribute until the bugs are fixed in patchelf.

Are we able to reproduce the udev error with a NixOS VM test, or is it a Xen-specific thing?

[flokli]

Urgh, turns out, patchelf is part of stdenv, so autoPatchelfHook (what's used to patchelf vscode and vscodium) will pick whatever is a default there :-/

[domenkozar]

@vcunat I've merged a bunch of patchelf patches including the possible fix, could you setup staging using patchelfUnstable from recent master?

[vcunat]

I had to hack around some issues in 15bfb6b69; we'll probably want a patchelf release/tarball before merging this to nixpkgs master. Jobset is running now: https://hydra.nixos.org/eval/1591215?compare=1591203

[flokli]

@vcunat nice, let's hope this works out!

IMHO, while we do that, we should also rename patchelf/unstable.nix to patchelf/default.nix and replace all usages of patchelfUnstable with patchelf - these were all hacks that wanted >= patchelf 0.10, features, and we can remove all this.

[vcunat]

Sure, I didn't want to hassle with such details at this moment.

[flokli]

sure :-)

[domenkozar]

@vcunat I've tried vscode but I get:

$ nix-build -A vscode
error: anonymous function at /home/ielectric/dev/nixpkgs/pkgs/build-support/fetchurl/boot.nix:5:1 called with unexpected argument 'recursiveHash', at /home/ielectric/dev/nixpkgs/pkgs/build-support/fetchzip/default.nix:17:2
(use '--show-trace' to show detailed location information)

[vcunat]

That's an error for almost anything in nixpkgs, and the commit mentioned above fixes it for me.

Still, I was unable to use vscode for testing this, because in the past only i686 version appeared to be broken and that platform isn't supported by current vscode. (With some more work, I can imagine applying the patchelf update to the old nixpkgs and trying that.)

EDIT: so I skipped that, thinking that we need to check whole nixpkgs anyway.

[domenkozar]

I can launch vscode-with-extensions with your additional commit without problems.

[domenkozar]

@vcunat It's looking pretty good (6k builds to go).

The only weird failure so far is:

/nix/store/psw68f7ngn728fng2xh9vzsdiri9a8r5-pytest-check-hook/nix-support/setup-hook: line 40:   113 Illegal instruction     /nix/store/2v0r743sczdnagsja18vq89hw4qdqm4d-python3-3.7.7/bin/python3.7 -m pytest -k "not test_load_cuda_params_to_cpu and not test_pickle_load"

[domenkozar]

Jobset has only 30 failing builds and they all don't seem related. Seems like we can release 0.11?

[domenkozar]

To me it looks like @edolstra can release patchelf 0.11, but I'd invite anyone to test extra things that were broken by 0.10

[domenkozar]

0.11 was released and a PR for staging is at https://github.com/NixOS/nixpkgs/pull/89927

[monoidal]

Since #89927 was merged, should this be closed?