Change:
crypt = let version = prev.crypt.version; in prev.crypt.override { <del> buildInputs = [ libxcrypt ]; </del> <ins> buildInputs = [ libxcrypt-legacy ]; </ins> postInstall = "mv $out/lib/erlang/lib/crypt-${version}/priv/{hex-source-crypt-${version},crypt}.so"; }; });

Discussion:
I upgraded Pleroma to 2.5.1, but it stopped working after the update. It crashes at startup with this . This might have to to do with the fact that I'm installing pleroma from unstable, from NixOS 22.11. Steps to reproduce the behavior: is my pleroma config: pleroma <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I'm a bit confused by that one, there's likely a weird interaction happening between libxcrypt and your host system, but I can't pinpoint it.

The error message seems to point to something related with the 1.0.0 -1.0.1 bump in Libxcrypt seem to ship a different crypt ABI on NixOS-21.11 and NixOS-unstable: 1.1.0 for 11.11, 2.0.0 for unstable: ~/code- (master) » ll $(nix-build -A libxcrypt)/lib ninjatrappeur these 4 paths will be fetched (6.74 MiB download, 30.97 MiB unpacked): /nix/store/0bxlqaklbcjy1cn5xw03jd5kxn39jn0l-libxcrypt-4.4.33 /nix/store/8xk4yl1r3n6kbyn05qhan7nbag7npymx-glibc-2.35-224 /nix/store/cnjwrrhnqn114jf5x0dwhx3jiaw6600d-libunistring-1.1 /nix/store/dh0jscni558i609q1s299qlrdbdj9jxa-libidn2-2.3.2 copying path '/nix/store/cnjwrrhnqn114jf5x0dwhx3jiaw6600d-libunistring-1.1' from ''... copying path '/nix/store/dh0jscni558i609q1s299qlrdbdj9jxa-libidn2-2.3.2' from ''... copying path '/nix/store/8xk4yl1r3n6kbyn05qhan7nbag7npymx-glibc-2.35-224' from ''... copying path '/nix/store/0bxlqaklbcjy1cn5xw03jd5kxn39jn0l-libxcrypt-4.4.33' from ''... total 124 -r-xr-xr-x 1 root root 963 1 janv. 1970 lrwxrwxrwx 1 root root 17 1 janv. 1970 - lrwxrwxrwx 1 root root 17 1 janv. 1970 - -r-xr-xr-x 1 root root 1 janv.

1970 dr-xr-xr-x 2 root root 4096 1 janv. 1970 pkgconfig
~/code- (master) » git checkout nixos-21.11 130 ↵ ninjatrappeur Mise à jour des fichiers: 100% (/), fait. Basculement sur la branche 'nixos-21.11' Votre branche est à jour avec 'origin/nixos-21.11'.
~/code- (nixos-21.11*) » ll $(nix-build -A libxcrypt)/lib ninjatrappeur total 220 -r-xr-xr-x 1 root root 963 1 janv. 1970 lrwxrwxrwx 1 root root 17 1 janv. 1970 - lrwxrwxrwx 1 root root 17 1 janv. 1970 - -r-xr-xr-x 1 root root 1 janv. 1970 lrwxrwxrwx 1 root root 11 1 janv. 1970 - lrwxrwxrwx 1 root root 13 1 janv. 1970 - lrwxrwxrwx 1 root root 11 1 janv. 1970 - dr-xr-xr-x 2 root root 4096 1 janv. 1970 pkgconfig My assumption here would be that libcrypto is somehow "leaking" somewhere through the NixOS closure and is in conflicts with the pleroma-provided one. I'm not 100% sure about that. I'm gonna try to find somebody more knowledgeable around this libcrypto area to help.
Mic92's suggestion: could you set to figure out which libcrypt is loaded? EG:
This is the part about libcrypt:
It seems like the right libcrypt gets loaded (the one coming from unstable). I'm not sure what's happening here, I'm really not a Elixir/Erlang expert, sorry. I guess your best bet might be looking at the Elixir/OTP docs and see if there's a way to make this DSO loader more chatty. Maybe strac-ing the process might show what the OTP is exactly trying to do before crashing.

Since my server runs with , I tried with nix-shell on my desktop and I can reproduce the issue here too. I attach the result of . I can't see anything wrong... thank you anyway.
Note that this isn't really a supported config. Using packages from unstable in an otherwise stable system can work but sometimes you run into errors like this. Unless you can reproduce this issue within a single channel, this isn't really something we can act on. Best ask about this sort of thing in Discourse or Matrix.
the OTP spins up several processes at startup, that's probably why we don't see any libcrypt-related reads. Can you add the (follow-forks) flag to your strace call to attach strace to the child processes and see if we get further informations?
I'd like to at least understand the issue here before closing it as wontfix.
I can reproduce this on a single channel. I am on unstable (), and my Pleroma fails with the same error. Here are my Pleroma logs: I have not run strace, as I'm not quite as advanced, and I don't know how to debug erlang. If it would be helpful, I can try to get specific debugging information when I have free time.
Hmm, that's concerning. I'm running my personal instance on unstable without any issues and can't reproduce that in the unstable VM test :thinking:. Upstream recently removed the crypt dependency altogether , so this issue will likely disappear for the next release. Looking at the upstream bug tracker, it seems like we're hitting I poked upstream there: Depending on their feedback, we'll either temporarily patch pleroma or use the next minor release. Edit: AH! I actually can reproduce on nixos-unstable, the pleroma test is failing. It runs successfully on . I'm going to git bisect from there, I'll post an update when I'll be done with the bisect.
Mystery solved :tada: is the culprit. It's been merged part of the run. Pleroma is definitely broken on unstable. I was lagging 3 days behind and failed to detect that.

The NixOS VM test broke though, yet another instance where it'd have been nice to have a notification from hydra :/ We're lucky upstream decided to drop cyrpt at the same time, the two issues were unrelated in the end. Let's wait for upstream response and act accordingly. FYI, we might have some other subtle breakages resulting from . In the meantime, you can pin your unstable channel to to get a functional 2.5.1 Pleroma.
thanks for your continued bug hunting. I confirm that pinning to that commit gave me back a working Pleroma 2.5.1. Thanks again.
: I pushed a temporary fix on master. You can track when it'll reach the nixos-unstable channel there: