Changelog v1.52.2

Updated arm32 image, running on asustor marvel, so far so good.

3 Likes

Has anyone tried the new image on a raspberry pi yet? I’m wary of doing this because my setup has been hands off for half a year now.

1 Like

Yeah I did it 49 hours ago now and it’s been up and running fine on rPi4

4 Likes

Hi, I am now running the new version bfc3d4c9d-v1.52.2-go1.17.5 on the Qnap (TS-431P3 operating system 5.0.0.1986) with Docker (ContainerStation 2.5.3.451). The node is a year old and runs error free in version 1.52.2.

AnnapurnaLabs, an Amazon company Alpine AL314, 4-core, 1.7GHz
32-bit ARM

When can I switch back to latest?

Hi @Luckymaster just reissue the docker command replacing the end with latest

2 Likes

When the arm v5 would be published to the latest: Docker
At the moment it has only 64 bit images

1 Like

I’m still running 1.49.5 and my ingress has dropped to 0. Do the satellites prefer updated storagenodes, was there a breaking change after 1.49.5, or is it just coincidence?

I observed the same thing and had therefore switched.

If I were to upgrade my raspberry pi 4 to 64 bit OS, would that have avoided this issue altogether?

The docker images have been pushed. Thank you for helping us testing especially the arm image. You can now switch back to latest

1 Like

We still not published arm 32 bit as latest. You need to use tag above.

@littleskunk there is no arm32 image in latest accordingly docker hub: Docker

Yes. And I would say that you will skip many problems in the future.

1 Like

Faced some issue with ARM 32bit version, see:

Hopefully you guys can fix it before it gets released ^^

1 Like

When do you plan to release it as latest? I haven’t checked but is it correct that your cutting off the 1.49.5 nodes from ingress but haven’t yet released the proper image?
What are you waiting for?

We shouldn’t have any nodes that stop receiving data when configured to auto-updated on the official latest image, I agree. It feels like the scheduling is off on this version release.

On the other hand, they probably shouldn’t rush publishing it as it appears to be problematic to some people…
Surely it’s better for ARM32 nodes to be excluded from ingress for a few days instead of being completely broken while they fix the version :slight_smile:

1 Like

If it is a few days…

1 Like

How can i upgrade my pi4 to 64os?

https://www.bastianoso.de/tipps-tricks/raspberry-pi/raspberry-pi-os-auf-64-bit-umstellen.html

Far as I know older rpi with 32bit processors cannot upgrade to 64bit no matter what so it cant be killed off or all the older Arm processors are completely useless here on out.

We pushed the arm32 v5 variant a few hours ago, it should now work with latest.

2 Likes

Just pulled it, and tried it on one of my nodes: I did not face the missing directory issue I had with storjlabs/storagenode:bfc3d4c9d-v1.52.2-go1.17.5.

I have a few errors in the logs, but the node did start and seems okay:

2022-04-21 18:08:41,281 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
2022-04-21 18:08:41,336 INFO RPC interface 'supervisor' initialized
2022-04-21 18:08:41,336 CRIT Server 'inet_http_server' running without any HTTP authentication checking
2022-04-21 18:08:41,337 INFO supervisord started with pid 1

But, when listing docker images, it seems “latest” and “bfc3d4c9d-v1.52.2-go1.17.5” are the same:

pi@raspberrypi:~/storj $ sudo docker images
REPOSITORY              TAG                          IMAGE ID            CREATED             SIZE
storjlabs/storagenode   bfc3d4c9d-v1.52.2-go1.17.5   35fb3de8edde        2 weeks ago         110MB
storjlabs/storagenode   latest                       35fb3de8edde        2 weeks ago         110MB
[...]

So I’m not sure my test shows anything meaningful, as I guess it only works fine because I created the “supervisor” directory previously? :thinking: