Latest 1.50.4 fails to start if arch is not set

Node Operators troubleshooting
1

Just a heads up, my GOARCH environment was blank and this threw the URL to download the software. Set the GOARCH to for instance amd64 and it is good.

From logs…

downloading storagenode-updater

–2022-03-25 01:24:07-- https://version.storj.io/processes/storagenode-updater/minimum/url?os=linux&arch=
Resolving version.storj.io (version.storj.io)… 35.224.88.204

Connecting to version.storj.io (version.storj.io)|35.224.88.204|:443… connected.

HTTP request sent, awaiting response… 400 Bad Request

2022-03-25 01:24:09 ERROR 400: Bad Request

2 Likes
2

Hello @nickb ,
Welcome to the forum!

Could you please describe your setup? Is it a binary version or a new docker image?
What is your OS?
If Linux, please show results of

uname -a

and

uname -m

If this is Windows, then

systeminfo.exe
3

Hello,
Same issue here with the following system:

uname -a
Linux Nestor 5.13.19-3-pve #1 SMP PVE 5.13.19-7 (Thu, 20 Jan 2022 16:37:56 +0100) x86_64 GNU/Linux

uname -m
x86_64

Note that it went fine on this one :

uname -a
Linux Zeus 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) x86_64 GNU/Linux

uname -m
x86_64

Both systems have this docker version :
Docker version 20.10.12, build e91ed57

and were on version 1.49.5 before upgrade.

As Nickb said, setting the GOARCH variable and recreating the container fixed the issue.

1 Like
4

Hello @labooll ,
Welcome to the forum!

Do you use a docker version of storagenode or binary one?

5

Hello @Alexey
I use the docker version of storage node

1 Like
6

Hi Alexey,

currently it is running on as a docker app on a Synology NAS.

Linux NAS 4.4.180+ #42218 SMP Mon Oct 18 19:16:55 CST 2021 x86_64 GNU/Linux synology_geminilake_1520+

It was running on a Pi 4 before (also has a docker app) and the data and config were copied to the NAS before upgrading to 1.50.4. I don’t recall ever setting the GOARCH variable before so it has always been blank.

Let me know if you need any more detail.

Nick

1 Like
7

Nice to hear you were able to fix it. I’m at a loss as to why you have this issue, something has to be different in your case.

8

yes very strange, please find additional details if it could help :

Host that has failed runs many nodes (on separate disks), and the one that didn’t run only one node

  1. On the host that failed :

  • All nodes failed the same way

  • Nodes are updated via ouroboros

  1. On the host that didn’t fail :

  • The GOARCH variable is not set, and yet, the node has been updated without issue

  • The node is updated via watchtower