distributions: [ERROR] Node.js 20 on debian Bullseye Installation fails due to checksum error

FYI, I’m indirectly affected by this through Playwright which uses nodesource in its Dockerfile: https://github.com/microsoft/playwright/blob/main/utils/docker/Dockerfile.focal#L12 (Edit: permalink)

It is solved by editing /etc/apt/sources.list.d/nodesource.list and changing https to http in the URLs, thus:

deb [signed-by=/usr/share/keyrings/nodesource.gpg] http://deb.nodesource.com/node_16.x focal main deb-src [signed-by=/usr/share/keyrings/nodesource.gpg] http://deb.nodesource.com/node_16.x focal main

And then typing:

apt update

apt upgrade

If you’re using the install script, something like this works: curl -sL https://deb.nodesource.com/setup_16.x | sed 's/https:\/\/deb.nodesource.com/http:\/\/deb.nodesource.com/g' | bash - Not very comfortable with such a hacky method but better than complete breakage?

I did several cache purges yesterday. I will contact our CDN provider.

edge servers are mirrors of the origin server, the edge server is typically chosen to be somehow the nearest to your client it seems, that some of these edge servers are out of sync with the origin, leading to above reported issue while others are working properly

different edge servers have different IPs, so, if you have some edge server which is working (you can try e.g. on some remote host or use some other provider), then you use this edge server in the region where you see the error

simplest way was, to just put the IP and the domain name into your /etc/hosts file

e.g. this was working for me

23.216.155.10 deb.nodesource.com

I added it to end of my /etc/hosts

@kay-ramme

And how would I go about doing that? I don’t know what that means. 😃

Same issue on Debian bullseye, and node 16 LTS:

Réception de :5 https://deb.nodesource.com/node_16.x bullseye/main amd64 Packages [775 B]
Err :5 https://deb.nodesource.com/node_16.x bullseye/main amd64 Packages
  Le fichier a une taille incohérente (776 != 775). Le miroir est peut-être en cours de mise à jour ? [IP : 2a02:26f0:9400::215:22bb 443]
  Hashes of expected file:
   - Filesize:775 [weak]
   - SHA256:0c6d8382f60bbb4bcc24ce922521673cd749c7530b2128b8dffb3e11297d1a15
   - SHA1:1e1b1951e616fb84373ee32a26944b356a83149d [weak]
   - MD5Sum:fdee69ee72123acebf6c975c753f6182 [weak]
  Release file created at: Wed, 21 Jun 2023 21:26:27 +0000

Hi guys we’ve received some reports about this, I’m checking into this.

HTTPS is working again for Node 20.x, bookworm, arm64.

Is it possible that the origin servers are briefly receiving outdated artifacts as part of the build process, resulting in a race condition with the edge servers? If a request is made to an affected file on an edge server during this period, it would presumably cache on outdated artifact.

That would also explain why HTTPS is more often affected than HTTP: since the script defaults to HTTPS, more systems are making requests to the HTTPS URL, so the race condition is more likely to arise.

I really dislike switching to http… any workarounds?

Have the same issue with Laravel Sail.

Still affected:

E: Failed to fetch https://deb.nodesource.com/node_16.x/dists/focal/main/binary-amd64/Packages.gz  File has unexpected size (775!= 776). Mirror sync in progress? [IP: 23.220.206.29 443]
   Hashes of expected file:
    - Filesize:776 [weak]
    - SHA256:e5d3c880cdb1ec15f193329e5a3abe68056c59f6026144de4d4b52fcce2131e6
    - SHA1:87f1583949354fe006bc0137a84d8cfe90b0229d [weak]
    - MD5Sum:c881892f3a46cc943e7ff44162cbee62 [weak]
   Release file created at: Wed, 19 Apr 2023 16:10:36 +0000

^ Same issue, was working a few hours ago.

E: Failed to fetch https://deb.nodesource.com/node_16.x/dists/focal/main/binary-amd64/Packages.gz  File has unexpected size (775 != 776). Mirror sync in progress? [IP: xx.xxx.xxx.xxx 443]
--
312 | Hashes of expected file:
313 | - Filesize:776 [weak]
314 | - SHA256:e5d3c880cdb1ec15f193329e5a3abe68056c59f6026144de4d4b52fcce2131e6
315 | - SHA1:87f1583949354fe006bc0137a84d8cfe90b0229d [weak]
316 | - MD5Sum:c881892f3a46cc943e7ff44162cbee62 [weak]
317 | Release file created at: Wed, 19 Apr 2023 16:10:36 +0000

I guys, sorry about this issue again, I’ve forced again the cache purge. I’ll rise a ticket with our CDN vendor.

Can confirm that it’s working now. Thanks!

ok, that was useful. would you mind to try it again in some mins over HTTPS? thank you

With this Dockerfile :

FROM ubuntu:22.04
RUN apt update
RUN apt -y install apt-utils curl jq
RUN curl -fsSL https://deb.nodesource.com/setup_20.x | bash -

I’ve got the same error when I try to build this image on gitlab CI (without any specific configuration)

Step 4/19 : RUN curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
 ---> Running in 2a49b933c937
## Installing the NodeSource Node.js 20.x repo...
## Populating apt-get cache...
+ apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Hit:2 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
Reading package lists...
## Installing packages required for setup: lsb-release gnupg...
+ apt-get install -y lsb-release gnupg > /dev/null 2>&1
## Confirming "jammy" is supported...
+ curl -sLf -o /dev/null 'https://deb.nodesource.com/node_20.x/dists/jammy/Release'
## Adding the NodeSource signing key to your keyring...
+ curl -s https://deb.nodesource.com/gpgkey/nodesource.gpg.key | gpg --dearmor | tee /usr/share/keyrings/nodesource.gpg >/dev/null
## Creating apt sources list file for the NodeSource Node.js 20.x repo...
+ echo 'deb [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_20.x jammy main' > /etc/apt/sources.list.d/nodesource.list
+ echo 'deb-src [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_20.x jammy main' >> /etc/apt/sources.list.d/nodesource.list
## Running `apt-get update` for you...
+ apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Hit:2 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Get:4 https://deb.nodesource.com/node_20.x jammy InRelease [4563 B]
Hit:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
Get:6 https://deb.nodesource.com/node_20.x jammy/main amd64 Packages [776 B]
Err:6 https://deb.nodesource.com/node_20.x jammy/main amd64 Packages
  File has unexpected size (777 != 776). Mirror sync in progress? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  Hashes of expected file:
   - Filesize:776 [weak]
   - SHA256:b8ca63ac4fbe9dad6950b850a9258db453c68c7b1c60f25457b9709684154e47
   - SHA1:35c0928a4089a3064e90b1c3cd0eb3f90d96983f [weak]
   - MD5Sum:333f082eb4c6371f533f47acb4774153 [weak]
  Release file created at: Tue, 16 May 2023 15:52:19 +0000
Fetched 4563 B in 0s (13.6 kB/s)
Reading package lists...

That’s not actually going to fix it. It might work around it once or twice, but it’ll break again. There are instructions above, but you probably shouldn’t use them.

I’m seeing 775 and up-to-date timestamps in all of the following:

• https://deb.nodesource.com/node_16.x/dists/bullseye/Release
• https://deb.nodesource.com/node_16.x/dists/bullseye/InRelease
• http://deb.nodesource.com/node_16.x/dists/bullseye/Release
• http://deb.nodesource.com/node_16.x/dists/bullseye/InRelease

I’m still betting on this being a race condition with caching. If that’s the case, clearing the CDN’s cache is always just going to be a temporary fix.

Does the origin have multiple servers that auto-scale or similar? If so, do servers ever come online prior to ensuring that they’re up-to-date? That would cause this issue, and the CDN wouldn’t be to blame.

node 16 on ubuntu 20.04, not working, same error

it’s working fine now, no change from my side, no workaround! Maybe it was a caching issue somewhere, I doubt it was my server since I tried clearing the cache

It is solved by editing /etc/apt/sources.list.d/nodesource.list and changing https to http in the URLs, thus:

deb [signed-by=/usr/share/keyrings/nodesource.gpg] http://deb.nodesource.com/node_16.x focal main deb-src [signed-by=/usr/share/keyrings/nodesource.gpg] http://deb.nodesource.com/node_16.x focal main

And then typing:

apt update

apt upgrade

Fallo al obtener https://deb.nodesource.com/node_16.x/dists/focal/main/binary-amd64/Packages.gz El archivo tiene un tamaño inesperado (776 != 775). ¿La sincronización de la réplica está en progreso?

[IP: 130.206.192.15 443] Hashes of expected file: - Filesize:775 [weak] - SHA256:0c6d8382f60bbb4bcc24ce922521673cd749c7530b2128b8dffb3e11297d1a15 - SHA1:1e1b1951e616fb84373ee32a26944b356a83149d [weak] - MD5Sum:fdee69ee72123acebf6c975c753f6182 [weak] Release file created at: Wed, 21 Jun 2023 21:26:29 +0000 E: No se han podido descargar algunos archivos de índice, se han omitido, o se han utilizado unos antiguos en su lugar.

Can confirm that it’s working now. Thanks!

I am trying to download node - 16. in ubuntu. getting same error.

Looks like it’s working everywhere I need (arm64 bullseye, amd64 bullseye, amd64 bookworm, armhf bullseye) 😄

Node 14.x reached EOL in April: https://nodejs.dev/en/about/releases/ I would assume it’s not supported. Although you shouldn’t, I’m sure you can get it working if you resolve the dependency problems, but that’s a separate issue–it’s not related to the HTTP/HTTPS staleness issue.

Much appreciated! Let me know if there’s any additional debugging info I can provide.

In the meantime, anyone experiencing this issue can probably work around it by using HTTP instead of HTTPS. This isn’t ideal, but the packages are still signed, so it should at least ensure package integrity.

Interestingly, this doesn’t always happen. On one device (host with ubuntu 20.04) the following fails with the mentioned error message, where on other device (host with ubuntu 22.04) things work fine.

I think that this is probably a configuration thing. I’d say the system that does not fail is not using the weak file size test, however I haven’t been able to discover how to disable the filesize test or even where its implemented 😦

The hash tests are more robust.

My guess is the file was edited after hashes were generated.

Interestingly, this doesn’t always happen. On one device (host with ubuntu 20.04) the following fails with the mentioned error message, where on other device (host with ubuntu 22.04) things work fine.

• Start some docker container: docker run --rm -it openjdk:11-jre-slim-buster bash
• Run the following commands:

apt update && apt install -y curl
curl -fsSL https://deb.nodesource.com/setup_20.x | bash - && \
apt-get install -y nodejs