New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to install Nix package manage #743

Closed
cloudhan opened this Issue Aug 3, 2016 · 18 comments

Comments

Projects
None yet
@cloudhan

cloudhan commented Aug 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mohammadprabowo

mohammadprabowo Aug 19, 2016

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

mohammadprabowo commented Aug 19, 2016

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

@jamesgecko

This comment has been minimized.

Show comment
Hide comment
@jamesgecko

jamesgecko Oct 4, 2016

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

jamesgecko commented Oct 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@benhillis

benhillis Oct 10, 2016

Member

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.

Member

benhillis commented Oct 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@wizardist

wizardist Oct 11, 2016

@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.

wizardist commented Oct 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@benhillis

benhillis Oct 11, 2016

Member

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

Member

benhillis commented Oct 11, 2016

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

@stehufntdev

This comment has been minimized.

Show comment
Hide comment
@stehufntdev

stehufntdev Nov 2, 2016

Collaborator

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.

Collaborator

stehufntdev commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sjackman

sjackman Nov 28, 2016

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)

sjackman commented Nov 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@brianjking

brianjking Nov 29, 2016

Following... Thanks!

brianjking commented Nov 29, 2016

Following... Thanks!

@stehufntdev

This comment has been minimized.

Show comment
Hide comment
@stehufntdev

stehufntdev Nov 30, 2016

Collaborator

@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.

Collaborator

stehufntdev commented Nov 30, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@sjackman

sjackman Nov 30, 2016

#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

sjackman commented Nov 30, 2016

#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

This comment has been minimized.

Show comment
Hide comment
@stehufntdev

stehufntdev Nov 30, 2016

Collaborator

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?

Collaborator

stehufntdev commented Nov 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sjackman

sjackman Nov 30, 2016

You can use either brew test -v hello or

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

sjackman commented Nov 30, 2016

You can use either brew test -v hello or

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

This comment has been minimized.

Show comment
Hide comment
@stehufntdev

stehufntdev Nov 30, 2016

Collaborator

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.

Collaborator

stehufntdev commented Nov 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bobvanderlinden

bobvanderlinden Dec 6, 2016

For reference: Issue for PR_SET_PDEATHSIG

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

bobvanderlinden commented Dec 6, 2016

For reference: Issue for PR_SET_PDEATHSIG

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

@domenkozar

This comment has been minimized.

Show comment
Hide comment
@domenkozar

domenkozar Jan 15, 2017

@stehufntdev can you do

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

and it works?

domenkozar commented Jan 15, 2017

@stehufntdev can you do

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

and it works?

@stehufntdev

This comment has been minimized.

Show comment
Hide comment
@stehufntdev

stehufntdev Jan 17, 2017

Collaborator

@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.

Collaborator

stehufntdev commented Jan 17, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@puffnfresh

puffnfresh Jan 19, 2017

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! 🎆

puffnfresh commented Jan 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@stehufntdev

stehufntdev Jan 19, 2017

Collaborator

Great, thanks for confirming!

Collaborator

stehufntdev commented Jan 19, 2017

Great, thanks for confirming!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment