nvm
nvm copied to clipboard
nvm-sh
"No such file or directory" when there is indeed such a file "node"
Operating system and version:
Debian Linux 10.8
nvm debug output:
nvm --version: v0.37.2
$SHELL: /bin/bash
$SHLVL: 1
whoami: 'pi'
${HOME}: /home/pi
${NVM_DIR}: '${HOME}/.config/nvm'
${PATH}: ${NVM_DIR}/versions/node/v12.21.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
$PREFIX: ''
${NPM_CONFIG_PREFIX}: ''
$NVM_NODEJS_ORG_MIRROR: ''
$NVM_IOJS_ORG_MIRROR: ''
shell version: 'GNU bash, version 5.0.3(1)-release (i686-pc-linux-gnu)'
uname -a: 'Linux 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux'
checksum binary: 'sha256sum'
OS version: Debian GNU/Linux 10
curl: /usr/bin/curl, curl 7.64.0 (i686-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
wget: /usr/bin/wget, GNU Wget 1.20.1 built on linux-gnu.
git: /usr/bin/git, git version 2.20.1
grep: /bin/grep (grep --color=auto), grep (GNU grep) 3.3
awk: /usr/bin/awk, awk: not an option: --version
sed: /bin/sed, sed (GNU sed) 4.7
cut: /usr/bin/cut, cut (GNU coreutils) 8.30
basename: /usr/bin/basename, basename (GNU coreutils) 8.30
rm: /bin/rm, rm (GNU coreutils) 8.30
mkdir: /bin/mkdir, mkdir (GNU coreutils) 8.30
xargs: /usr/bin/xargs, xargs (GNU findutils) 4.6.0.225-235f
nvm current:
which node: ${NVM_DIR}/versions/node/v12.21.0/bin/node
which iojs:
which npm: ${NVM_DIR}/versions/node/v12.21.0/bin/npm
npm config get prefix: /usr
npm root -g: /usr/lib/node_modules
nvm ls output:
v12.21.0
system
default -> 12 (-> v12.21.0)
iojs -> N/A (default)
unstable -> N/A (default)
node -> stable (-> v12.21.0) (default)
stable -> 12.21 (-> v12.21.0) (default)
lts/* -> lts/fermium (-> N/A)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.0 (-> N/A)
lts/erbium -> v12.21.0
lts/fermium -> v14.16.0 (-> N/A)
How did you install nvm?
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.37.2/install.sh | bash
What steps did you perform?
Checking node --version
What happened?
Got:
bash: /home/pi/.config/nvm/versions/node/v12.21.0/bin/node: No such file or directory
What did you expect to happen?
A node version number, not an error.
Is there anything in any of your profile files that modifies the PATH?
Other than nvm itself, no. My $PATH is: /home/pi/.config/nvm/versions/node/v12.21.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
The "file not found" doesn't seem to be about the copy of node itself... it's definitely there. I can see the node file in the directory at /home/pi/.config/nvm/versions/node/v12.21.0/bin/.
which node also returns /home/pi/.config/nvm/versions/node/v12.21.0/bin/node.
It seems the node is actually running at the command line, but that node itself is producing the "No such file or directory" error for some reason, and what file it isn't finding, I have no idea.
env node --version works, but it finds the default v10.24.0 version of node.
Since which node works, i would expect node to work as well. If you just run node by itself, do you get the repl?
What does type node print out?
type node gives me node is hashed (/usr/bin/node).
I agree that if which node works, node should work too. That's why this is maddeningly confusing.
That's weird. One terminal window gave me the above response for type node. A different window gave me node is hashed (/home/pi/.config/nvm/versions/node/v12.21.0/bin/node). That's where node fails. Node works in the other terminal, but it's version 10, not 12.
In the other terminal, it’s using your system node, so that seems fine.
The only thing i can think of is to nvm uninstall v12.21.0 and then nvm install v12.21.0, just to rule out a corrupted node install or something.
Hmm. Did you have to do anything special to install node 10 on the system? Sometimes Pis and similar low-level devices need extra things to be installed for programs to work (manjaro/busybox in particular).
it also seems weird in your OP - which node returns nvm’s node, but npm root -g returns your system node’s location. Do you have any env vars with “prefix” in their names? `npm config get prefix should not be pointing to /usr. Also check ~/.npmrc
I have this Debian installation on a VM. I just reverted to a clean, post-Debian-installation snapshot, with nothing done beyond making sure the OS was fully updated.
I took these steps:
- Checked node version -- no node installed.
- Installed node 10 via
sudo apt-get install -y nodejs - Checked node version -- v10.24.0
- Installed nvm via
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.37.2/install.sh | bash - Close terminal window and opened a new terminal window.
- Checked nvm version -- 0.37.2
- Installed node 12 via
nvm install v12 - Checked node version --
bash: /home/pi/.config/nvm/versions/node/v12.21.0/bin/node: No such file or directory
I don't see any "prefix" environment variables either.
so to confirm again: if you run nvm use 12, and which node and which npm both report paths inside $NVM_DIR, node -v continues to error, and node fails to open the repl (in which process.version reports the expected version)?
Yes, that's the situation. node by itself also fails with no such file, instead of opening the repl.
That really does sound like an issue with node itself, then. It's likely that your system node, installed via apt, isn't installing real node but instead is installing a modified version. If we knew what those modifications are (presumably, compiler options) you could nvm install -s v12 --extra --options, but atm I'm pretty stuck.
In case anyone is interested in exploring this issue, a VM built using 2021-01-11-raspios-buster-i386.iso obtained from here, under the category "Raspberry Pi Desktop": https://www.raspberrypi.org/software/operating-systems/
...will do it.
Here's someone at StackOverflow having the same issue: https://stackoverflow.com/q/67222751/436641
Interesting commonality would seem to be the Raspberry Pi.
I just had a very similar issue on Alpine and I'm wondering if the problem is that nvm has installed an incompatible binary. I'm not sure which Pi devices/ARM chips are supported by downloadable Node.js binaries and which need to be compiled locally, but that would seem to be something to look into.
The checks nvm uses are mainly nvm_get_arch and nvm_get_os.
https://github.com/nvm-sh/nvm/blob/fc87226b2314f93ea8c38b62b0d2ef26c3055fd7/nvm.sh#L1816 may be relevant, as may be https://github.com/nvm-sh/nvm/blob/fc87226b2314f93ea8c38b62b0d2ef26c3055fd7/nvm.sh#L2054.
The checks
nvmuses are mainlynvm_get_archandnvm_get_os.https://github.com/nvm-sh/nvm/blob/fc87226b2314f93ea8c38b62b0d2ef26c3055fd7/nvm.sh#L1816
may be relevant, as may be https://github.com/nvm-sh/nvm/blob/fc87226b2314f93ea8c38b62b0d2ef26c3055fd7/nvm.sh#L2054
.
According to @richardlau in https://github.com/nodejs/node/discussions/38496, arm6l has been unsupported since Node.js 12. Maybe that's relevant?
that's arm6l, the line of code is armv6l - i'm not familiar with the difference tho.
that's
arm6l, the line of code isarmv6l- i'm not familiar with the difference tho.
I could be wrong, but I doubt they are different. ARM is the architecture. 6 is the version of the architecture. l is for little-endian. The inclusion or omission of the v for version before the version number is a matter of style, I think. I don't think Richard was specifying a string value, just saying the arm6l chips are not supported anymore.
Over in the StackOVerflow issue mentioned above, the person having this problem says they are using Pi 4. That would be an armv8 device. As far as I know, the Node.js binaries are built and tested on armv7 (Pi 2 and Pi 3). I wonder if the folks having a problem here are also using Pi 4, and I don't know if the binaries Node.js creates would be expected to work with Pi 4 devices or not. Maybe @rvagg knows.
"Raspberry Pi Desktop" 2021-01-11-raspios-buster-i386.iso
i386, and the Raspberry Pi OS site says this is for "PC or Mac", so this is a 32-bit x86 build of Raspberry Pi OS and unrelated to ARM.
What does uname -a tell you in this machine/VM/whatever it is?
@kshetline @OCDpunk can you run
uname -aand share the output?
@ljharb @rvagg Here's the result of uname -a from the StackOverflow question that seems similar or identical to this issue:
Linux raspberrypi 5.10.17-v8+ #1403 SMP PREEMPT Mon Feb 22 11:37:54 GMT 2021 aarch64 GNU/Linux
:shrug: https://github.com/nvm-sh/nvm/blob/ad24e96fda498887d6393a61cf8828ae13e0beb0/nvm.sh#L1809-L1825
Raspberry Pi OS native 64-bit I think might still be in "beta" as they don't list it through any of their download options. You can get it if you go hunting @ https://downloads.raspberrypi.org/ and it seems to be updated. The incantation to figure out the arch of the init system in the above link is a bit too obscure for me but I'm guessing that it's downloading the arm64 bundle.
Maybe someone using a native arm64 Raspberry Pi OS could manually download, unpack and try to run node from the arm64 tarball @ https://nodejs.org/download/release/latest-fermium/ and report back whether that works or not. Perhaps we have an interesting binary incompatibility for arm64.
The alternative may be nvm is not properly detecting the arm64 userland and downloading the armv7l tarball and that's not running properly. Running od -An -t x1 -j 4 -N 1 /lib/systemd/systemd would tell us that, it's giving me 01 on a native armv7l Raspberry Pi OS but apparently will be different for an arm64 userland—if I run it on a server-grade arm64 machine I get 02 so presumably that's what it needs to be to satisfy the conditions to download and use the arm64 binary.
I'm having the same problem - the only thing I've done recently was update the raspberry pi using
sudo apt-get update && sudo apt-get upgrade -y
I don't have a real solution - but I think I found the cause. Run the following command on your raspberry pi 4:
uname -m
If this shows aarch64 or similar, then nvm also thinks that the raspberry pi is 64 bit, and tries to download the 64 bit version of node. Node's 32-bit build still works just fine, but for some reason the 64 bit build is failing in this very unusual way.
My only real answer is to download "Linux Binary - ARMv7" from here:
https://nodejs.org/en/download/current/
and place it in the system path. It's inelegant, but it should work, in thoery.
Seeing this on an aarch64 Alpine running in a Podman image; ldd <path/to/>node has this to say[^1]:
$ ldd $HOME/.nvm/versions/node/v16.14.2/bin/node
/lib/ld-linux-aarch64.so.1 (0xffffa0d29000)
libdl.so.2 => /lib/ld-linux-aarch64.so.1 (0xffffa0d29000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xffffa0b39000)
libm.so.6 => /lib/ld-linux-aarch64.so.1 (0xffffa0d29000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xffffa0b14000)
libpthread.so.0 => /lib/ld-linux-aarch64.so.1 (0xffffa0d29000)
libc.so.6 => /lib/ld-linux-aarch64.so.1 (0xffffa0d29000)
Error loading shared library ld-linux-aarch64.so.1: No such file or directory (needed by $HOME/.nvm/versions/node/v16.14.2/bin/node)
Error relocating $HOME/.nvm/versions/node/v16.14.2/bin/node: __register_atfork: symbol not found
Error relocating $HOME/.nvm/versions/node/v16.14.2/bin/node: makecontext: symbol not found
Error relocating $HOME/.nvm/versions/node/v16.14.2/bin/node: backtrace: symbol not found
Error relocating $HOME/.nvm/versions/node/v16.14.2/bin/node: setcontext: symbol not found
Error relocating $HOME/.nvm/versions/node/v16.14.2/bin/node: getcontext: symbol not found
Error relocating $HOME/.nvm/versions/node/v16.14.2/bin/node: backtrace_symbols: symbol not found
Error relocating $HOME/.nvm/versions/node/v16.14.2/bin/node: gnu_get_libc_version: symbol not found
Error relocating $HOME/.nvm/versions/node/v16.14.2/bin/node: __strdup: symbol not found
Error relocating $HOME/.nvm/versions/node/v16.14.2/bin/node: __libc_stack_end: symbol not found
Looks to me like you are pulling down a binary linked against glibc, so it's no surprise that running it on Alpine (which uses musl libc, rather than GNU libc) isn't working. :-(
[^1]: I am back-substituting </path/to/my/home/dir> -> $HOME in output of ldd for conciseness.
Hmm... It looks like this is already documented in your README.
@Trott please see above, since you explicitly say you are on Alpine. Sounds to me like OP was on Debian, now that I look at the thread in more detail. Apologies for creating further confusion apropos "what platform is this on."
The issue happens with an alpine image. I did away with Alpine and fixed the issue.
