Unable to install Nix package manage

[cloudhan]

cloud@DESKTOP-DSHEB2Q:~$ curl https://nixos.org/nix/install | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2590  100  2590    0     0    362      0  0:00:07  0:00:07 --:--:--   559
downloading Nix binary tarball for x86_64-linux from 'https://nixos.org/releases/nix/nix-1.11.2/nix-1.11.2-x86_64-linux.tar.bz2' to '/tmp/nix-binary-tarball-unpack.GBp1CD11La'...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 67.1M  100 67.1M    0     0  65098      0  0:18:01  0:18:01 --:--:-- 77956
performing a single-user installation of Nix...
directory /nix does not exist; creating it by running ‘mkdir -m 0755 /nix && chown cloud /nix’ using sudo
[sudo] password for cloud:
copying Nix to /nix/store...........................
initialising Nix database...
/tmp/nix-binary-tarball-unpack.GBp1CD11La/unpack/nix-1.11.2-x86_64-linux/install: line 58: /nix/store/4z8srway6dl128dxzn5r0wwdvglz3m61-nix-1.11.2/bin/nix-store: cannot execute binary file: Exec format error
/tmp/nix-binary-tarball-unpack.GBp1CD11La/unpack/nix-1.11.2-x86_64-linux/install: failed to initialize the Nix database

I don't know what is running wrong, because is no useful information. WSL just complaint cannot execute binary file: Exec format error, using file command on this file I get

cloud@DESKTOP-DSHEB2Q:/nix/store/4z8srway6dl128dxzn5r0wwdvglz3m61-nix-1.11.2/bin$ file nix-store
nix-store: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped

To reproduce this error, simply run curl https://nixos.org/nix/install | sh or just follow the instruction on http://nixos.org/nix/. This will install a standalone package manager independent from the host. It heavily used link.

[mohammadprabowo]

I hope this will eventually resolved soon. Many packages in nix are more updated and close to upstream version....

[jamesgecko]

I've run into something very similar with the Linuxbrew package manager. Initial installation goes OK, but every ELF binary linked in ~/.linuxbrew/bin gives Exec format error. I'm using the fish shell here, but the same thing happens under bash.

james@JAMES-PC ~/.l/bin> pwd
/home/james/.linuxbrew/bin
james@JAMES-PC ~/.l/bin> ./makedepend
Failed to execute process './makedepend'. Reason:
exec: Exec format error
The file './makedepend' is marked as an executable but could not be run by the operating system.
james@JAMES-PC ~/.l/bin> file makedepend
makedepend: symbolic link to `../Cellar/makedepend/1.0.5/bin/makedepend'
james@JAMES-PC ~/.l/bin> file ../Cellar/makedepend/1.0.5/bin/makedepend
../Cellar/makedepend/1.0.5/bin/makedepend: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=a9632df29b7109cefa6d1bf5a44fb2293e639391, not stripped

[benhillis]

Sorry for the delay in looking at this thread, I dug into this a bit and it looks like our ELF parsing logic is assuming that interpreter paths must be less than 64 characters long, which is incorrect. When I bumped that number up to 128 the Nix binaries are running. I'm going to look through the ELF format documentation to determine what the correct max size is (maybe it's just PATH_MAX).

Unfortunately shortly after the Nix binaries use the PR_SET_PDEATHSIG option of the prctl system call for which I've filed a task to implement.

[wizardist]

@benhillis I think it indeed should be PATH_MAX. I can't recall any limitations in the ELF specification, only that interpreter path is referenced by specifying offset for path string and its integer length.

[benhillis]

@wizardist That seems to be the case. I have a fix in code review that will resolve this.

[stehufntdev]

The PR_SET_PDEATHSIG fix should be out to insider builds soon, and I confirmed curl https://nixos.org/nix/install | sh didn't report any errors.

[sjackman]

Any update on this issue? Does this mean that Linuxbrew executables modified by patchelf are also expected to work after this patch?
See the related issue #471 (comment)

[brianjking]

Following... Thanks!

[stehufntdev]

@sjackman thanks for the follow-up. I read through the information in this post and #471, but I'm not seeing how they are related. Can you please clarify?

For this post, the two issues where with 1.) elf parsing logic for interpreter path length was wrong and 2.) PR_SET_PDEATHSIG support. For #471, it looks like the issue there was the "cannot enable executable stack" failure which has a workaround.

[sjackman]

#471 (comment)

I stumbled into the same issue. In general, binaries aren't executed that are patched with patchelf, and all the bottles (precompiled binaries from brew) are this way. So to use linuxbrew, you currently should set it to always compile from source.

The precompiled executables are patched with patchelf to set the path to the dynamic linker to /home/linuxbrew/.linuxbrew/lib/ld.so and RPATH to /home/linuxbrew/.linuxbrew/lib (by default). After being modified by patchelf these executables are no longer loadable by the Windows kernel.

To reproduce the issue, install Linuxbrew (instructions at http://linuxbrew.sh) and run

brew install hello
hello

[stehufntdev]

Thanks for providing the additional details. I went through all of the steps, but the last one (hello) gives me an error:

:~$ hello
The program 'hello' can be found in the following packages:

• hello
• hello-traditional
  Try: sudo apt install

Is there a different command I need to run? Sorry I'm not familiar with brew, but maybe brew run hello?

[sjackman]

You can use either brew test -v hello or

PATH="$HOME/.linuxbrew/bin:$PATH"
hello

[stehufntdev]

Thanks for the detailed steps. I just tried locally, and it is failing in execv for /home/.linuxbrew/Cellar/hello/2.10/bin/hello. Since this failure isn't related to this post, let's continue the discussion over in #471.

[bobvanderlinden]

For reference: Issue for PR_SET_PDEATHSIG

In which version of Windows should the path parsing problem be fixed?

[domenkozar]

@stehufntdev can you do

https://nixos.org/nix/install | sh
nix-env -i python
python

and it works?

[stehufntdev]

@domenkozar, I went through those steps and was able to launch python and didn't see any obvious failures in the install spew. Please let us know if you hit any issues on the most recent insider build.

[puffnfresh]

I think this can be closed. I've installed Nix, did a normal build of GNU Hello and executed it. I then did a cross-compile from WSL to an .exe file:

(import <nixpkgs> {
  crossSystem = {
    config = "x86_64-w64-mingw32";
    libc = "msvcrt";
  };
}).hello.crossDrv

And the brilliant thing is that an .exe will work within WSL so it's possible to execute Windows binaries within Nix builds! 🎆

[stehufntdev]

Great, thanks for confirming!