Could not download node #1523
Comments
|
I'm having a similar error, happening intermittently in my CI/CD pipelines since a few days: Another one failed with Node 16. |
|
I think you can try to solve this problem by setting up the mirror source of nodejs through hook, |
|
same here |
|
I think it would be nice if Volta itself could ship with some pre-defined mirrors for redundancy. |
|
Hi all, thanks for the report. I've occasionally seen the same in CI over the past few months. Unfortunately, this stuff is all outside our ability to do anything about: we just ask the hosts for the downloads, and if they have a network issue… they have a network issue. 🤷🏻♂️ Shipping with built-in/pre-configured mirrors is an interesting idea, but definitely out of scope for us at present, and as you all may have inferred from the delay in our responding, we're all very much buried with other things right now! That said, if someone wants to spearhead writing an RFC with design for how that would work (vs. for users to define mirrors to fall back to in scenarios like this using the existing hooks design), we'd welcome it at least as a good point for discussion. |
I can download the zip file from the URL just fine, in the browser, |
|
Since this really became a pain point in my CI/CD pipelines, I wanted to share my temporary solution to it:
retry --tries 3 --sleep 15s -- volta install node@18The good thing is that, even if this issue gets fixed anywhere, retry will not cause any harm since it exits as soon as it passes. Also, I figured I could use the same tool for many other scenarios in my containers (and it's just so small), that I'd rather keep it there. |
|
I'm connecting over a VPN. That doesn't seem to matter for the browser, I can download Node just fine. But for Volta I had to disable VPN. |
volta --verbose install node
[verbose] No custom hooks found
[verbose] Found valid cache of Node version index
[verbose] Found newest LTS node version (18.17.1) from https://nodejs.org/dist/index.json
[verbose] Acquiring lock on Volta directory: ~/.volta/volta.lock
[verbose] Downloading node@18.17.1 from https://nodejs.org/dist/v18.17.1/node-v18.17.1-darwin-x64.tar.gz
[verbose] Unpacking node into '~/.volta/tmp/.tmpu1NqMB'
[verbose] Unlocking Volta Directory
#### without proxy
error: Could not unpack Node v18.17.1
Please ensure the correct version is specified.
[verbose] Error cause: failed to unpack `~/.volta/tmp/.tmpu1NqMB/node-v18.17.1-darwin-x64/bin/node`
Error cause: failed to unpack `~/.volta/tmp/.tmpu1NqMB/node-v18.17.1-darwin-x64/bin/node`
Error cause: failed to unpack `node-v18.17.1-darwin-x64/bin/node` into `~/.volta/tmp/.tmpu1NqMB/node-v18.17.1-darwin-x64/bin/node`
Error cause: Resource temporarily unavailable (os error 35)
Error details written to ~/.volta/log/volta-error-2023-09-18_16_11_34.765.log
#### with https_proxy
error: Could not unpack Node v18.17.1
Please ensure the correct version is specified.
[verbose] Error cause: failed to unpack `~/.volta/tmp/.tmpu3ZeJG/node-v18.17.1-darwin-x64/include/node/openssl/archs/darwin-i386-cc/asm/include/openssl/asn1.h`
Error cause: failed to unpack `~/.volta/tmp/.tmpu3ZeJG/node-v18.17.1-darwin-x64/include/node/openssl/archs/darwin-i386-cc/asm/include/openssl/asn1.h`
Error cause: failed to unpack `node-v18.17.1-darwin-x64/include/node/openssl/archs/darwin-i386-cc/asm/include/openssl/asn1.h` into `~/.volta/tmp/.tmpu3ZeJG/node-v18.17.1-darwin-x64/include/node/openssl/archs/darwin-i386-cc/asm/include/openssl/asn1.h`
Error cause: Resource temporarily unavailable (os error 35)
Error details written to ~/.volta/log/volta-error-2023-09-18_16_43_24.165.log |
|
Reading through this and related issues (e.g. #1546) the repeated comments about this showing up most commonly on CI and VPNs, combined with the detailed error reporting here are pretty suggestive that this may be related to a rate-limiting behavior on the host servers. Anyone using any of the hosted runners for GH Actions, for example, will be asking from the same address; and anyone pulling from inside a VPN likewise. (And direct access to the tarball, esp. in a browser, does not always run over the same VPN paths that access via Sorry this has been a hassle! It's frustrating to us, too. 😞 |
|
This error is very frequent https://github.com/gkd-kit/subscription/actions/runs/6274100781/job/17038860167 https://github.com/gkd-kit/subscription/actions/runs/6262568177/job/17005034345 https://github.com/gkd-kit/subscription/actions/runs/6262539779/job/17004936137 https://github.com/gkd-kit/subscription/actions/runs/6262522729/job/17004877700 https://github.com/gkd-kit/subscription/actions/runs/6262485089/job/17004746507 https://github.com/gkd-kit/subscription/actions/runs/6249994343/job/17002563652 Here's my solution, - uses: actions/setup-node@v3
with:
node-version: 20Now I only use volta on my personal computer |
|
How odd: And yes, this runs within my internal company's network, which is probably under a single external IP and multiple people could be running it at the same time. |
|
I run into the same problem. Also, it does not matter is VPN on or off. |
|
At work, we run into this issue continuously. We have Dockerfiles which use Volta within the build steps, like this: Frequently, our CICD (in both github actions and AWS codebuild) get these two errors:
It seems intermittent over time, if it's happening, all builds fail. I'm not sure the difference between the two errors, my assumption is "could not unpack" happens after a download has started and the network caused a partial download; whereas the "could not download" happens if the initial request to download fails right away. Either way, my first thought was to cache the download in the container ahead of time and keep it in ECR; but now I'm leaning towards just removing Volta from the Dockerfile altogether and going back to using like Open to ideas here. |
|
For the record, I'm running into the same issue at work, multiple different projects that use volta are suffering from intermittent failures in CI/CD |
|
Could volta provide a way for the user to override the repository where nodejs is fetched from, so that we could point it to something like an internal artifactory instance where we're caching the binary ourselves? |
|
@vanstinator isn't this what #1523 (comment) is for? |
Yes 🤦🏻 😅 Thank you! |
|
I used this for the ~/.volta/hooks.json and it seems to work too: |
This partially fixed my issue. Windows, no vpn, completely unable to download node with volta. It hung for a few minutes with no output before finally returning an error that says it could not download node, not really anything helpful in the log. With this it at least started fetching node, then failed out with addendum: |
So ... basically it seems that it is still flaky and the hooks / pointing to a specific mirror does not change anything? |
|
At the moment the Nodejs servers seem to have issues again (and all week apparently). Volta queries them for downloads, but also to determine the latest versions. This hooks.json seems to not do anything with the "latest" param, which can make them still stall there I'm guessing. I still find it weird that I can open my browser to nodejs.org and go to the download section and have very fast downloads, but volta's install (or fetch) command stalls and does nothing, or is very slow, and aborts halfway through, etc... Volta uses the .tar.gz files while the download site lists the .tar.xz files, that might be a thing. But again: If volta has issues with nodejs-server issues, why is my browser working fine on that same site. Is it their load-balancing / redirecting to a mirror that makes it work 'by luck' ? Because I can now try a 'volta fetch node@20' and it does nothing, ctrl+c, arrow up, retry, and nothing" and I have been doing that for the last 15 minutes. status.nodejs.org says everything is fine. |
|
Last week I convinced a co worker to try out Volta, she had to disconnect from the VPN for it to work, too much of an inconvenience for her to continue using it. Just now my GHA failed due to Volta not being able to download Node, while the Node servers are fine, like others above. My GHA with Volta worked dozens of times before, and after waiting 3-5 minutes and re-running the failed CI, it worked again. Error from the failed attempt: I'm really hoping these problems can be resolved soon, especially automatically. If Volta could fall back to a randomly selected mirror from a list automatically, then users won't even know they hit a rate-limit and Volta would continue trying mirrors until it finds one that works, so it just takes a little longer to get the download started, but other than that works normally. Obviously would need to double-check a hash before accepting the file from the mirror, but other than that this could all be done behind the scenes. |
|
Instead of installing volta in every action as a step, I now do it in a
prepared docker image. So volta is pre installed in our images used for
actions/pipelines.
And the config is changed to use the npm mirrors as much as possible. Since
then , no more issues as far as I know.
In a bigger version of our pipeline docker images I even run a 'volta fetch
***@***.***' and then the same for 16, 18 and 20. Those docker images are
rebuilt every week on a schedule.
So as long as the devs that use them have the projects pinned to the latest
version of a certain node major, the docker image had them available
already and often works without having an internet connection at all .
It was our fallback plan because hlthe interaction between volta and the
node servers was preventing devs from releasing, apparently
…On Wed, Jan 24, 2024, 15:26 The Jared Wilcurt ***@***.***> wrote:
Last week I convinced a co worker to try out Volta, she had to disconnect
from the VPN for it to work, too much of an inconvenience for her to
continue using it.
Just now my GHA failed due to Volta not being able to download Node, while
the Node servers are fine, like others above.
Volta error: Could not unpack Node v21.1.0
Please ensure the correct version is specified.
Volta error: Error cause: failed to unpack `/opt/hostedtoolcache/volta/1.1.1/x64/tmp/.tmpxEuBAO/node-v21.1.0-linux-x64/bin/node`
Error cause: failed to unpack `/opt/hostedtoolcache/volta/1.1.1/x64/tmp/.tmpxEuBAO/node-v21.1.0-linux-x64/bin/node`
Error cause: failed to unpack `node-v21.1.0-linux-x64/bin/node` into `/opt/hostedtoolcache/volta/1.1.1/x64/tmp/.tmpxEuBAO/node-v21.1.0-linux-x64/bin/node`
Error cause: Resource temporarily unavailable (os error 11)
Error: Process completed with exit code 126.
Really hoping these problems can be resolved soon, especially
automatically. If Volta could fall back to a randomly selected mirror from
a list automatically, then users won't even know they hit a rate-limit and
Volta would continue trying mirrors until it finds one that works, so it
just takes a little longer to get the download started, but other than that
works normally. Obviously would need to double-check a hash before
accepting the file from the mirror, but other than that this could all be
done behind the scenes.
—
Reply to this email directly, view it on GitHub
<#1523 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALMD2DUHT5D6E3CX3FIKKRDYQEKXZAVCNFSM6AAAAAAZVJOMKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBYGIZTMMRVHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
On Sun, 3 Mar 2024 at 09:40, codercoin ***@***.***> wrote:
same problem.😕
We've used docker images in pipelines now for more than a few months, which
have Volta included from the start.
So the 'volta installer' is run during creation of the docker image, and
then the environment variables are set in the image so that it's ready to
use when a container is started.
In the home folder of the container, we create a file `~/.volta/hooks.json`
with the following contents:
```json
{
"node": {
"index": {
"prefix": "https://npmmirror.com/mirrors/node/"
},
"distro": {
"template": "
https://npmmirror.com/mirrors/node/v{{version}}/{{filename}}"
}
},
"npm": {
"index": {
"prefix": "https://registry.npmmirror.com/"
},
"distro": {
"template": "https://registry.npmmirror.com/npm/-/{{filename}}"
}
},
"pnpm": {
"index": {
"prefix": "https://registry.npmmirror.com/"
},
"distro": {
"template": "https://registry.npmmirror.com/pnpm/-/{{filename}}"
}
}
}
```
This tells Volta to use the npmmirror for downloading node / npm. Although
the response time seems a bit slower (latency), download speeds are fast
and we had no problems since then.
NodeJS is working on a new site, though.
|
|
"volta" "install" "node" Could not download Node version registry Please verify your internet connection. Error cause: Io Error: invalid peer certificate contents: invalid peer certificate: UnknownIssuer Oi oi oi.. it attempts to wownload from https and it is not able to do it? |
Thank you!!! This method works for me! |
This configuration is also available {
"node": {
"index": {
"template": "https://mirrors.cloud.tencent.com/nodejs-release/index.json"
},
"distro": {
"template": "https://mirrors.cloud.tencent.com/nodejs-release/v{{version}}/node-v{{version}}-{{os}}-x64.zip"
}
}
} |
When using the commands volta install node@版本号 and volta pia node@版本号 to download Node.js, you encountered the following error message, but network issues were not detected after checking. You can also download the corresponding Node.js file from the official Node.js website.
The text was updated successfully, but these errors were encountered: