Changelog v1.52.2

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 Hub

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

Hello :slight_smile:

I’m not aware of an in place upgrade for Raspbian32 as the underlying Kernel distribution has been changed for the 64Bit release, so afraid there is no apt dist-upgrade command :frowning: - please use caution following guides on how to switch out kernels to 64bit version, you could be making things really bad for your Pi !

If you want to go to the 64bit release, it’s a fresh install - and that could mean you have to remember to backup things like node identity, and networking settings - Make sure you have a good backup of your Pi !

I would personally wait a bit - There has clearly been some issues with the Armv5 32 build and release, and I’m sure Storj will fix this - maybe log an issue on their github will get more focus.

If it’s still not fixed in 7 days, then maybe there would be a need to upgrade to 64bit if ingress traffic is a concern for you - but that would be really bad communication if 32bit support is being killed of like this…

CP

3 Likes

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:

If you created it inside the container - it has been flushed away with removing of the container.

Well, I removed the container:

sudo docker stop -t 600 "storj_node_2"
sudo docker rm "storj_node_2"

Then pulled the new image with:

sudo docker pull storjlabs/storagenode:latest

Then I started the node again with my full command:

sudo docker run -d --restart unless-stopped \
    [... many stuff such as ports, wallet address, email ...]
    --name "storj_node_2" \
    storjlabs/storagenode:latest \
   [... other stuff such as zksync ...]

So, do you confirm the latest ARM32 image is fixed with regards to the missing supervisor folder? How could both images have the same ID then? :thinking:

I do not have arm32 anymore, so cannot confirm, sorry.

Alright that’s fine, no worries :slight_smile:
It works fine now on my end, so all is good :+1:

1 Like

The CRITICAL logs are safe to ignore for now. See my response here: [Tech Preview] Storagenode Updater inside Docker - #33 by clement and [Tech Preview] Storagenode Updater inside Docker - #32 by clement

However, we have PRs ready to get rid of the CRITICAL error logs:
https://review.dev.storj.io/c/storj/storj/+/7332
https://review.dev.storj.io/c/storj/storj/+/7341
https://review.dev.storj.io/c/storj/storj/+/7342

2 Likes