Sorry I replied to your message accidentally.
It was a general question to @Alexey
Doesn’t matter, because you have specified the exact tag.
I mean when the Linux update is in the image is watchtower then obsolete?
It would be still useful to update the base image.
What is then the sense to have the updater in the updater itself ? I didn’t get the point
As a backup solution. For example if we push the broken updater, we can just update the base image with a correct one and watchtower will update the base image.
1 Like
Ah cool get the point.
I am still using the old version and I use watchtower to update. Do I even need to care about this update or will it update automatically as usual.
It’ll update automatically at some point, but in this case I recommend testing with this image right now. It is quite impactful and I tested it on the testnet and ran into issues. I see some issues reported here as well. I think it’s best as many people as possible test it before it is pushed as the latest image. You can easily revert now and report problems. But if the latest image has been upgraded, those problems will likely lead to your node being down for a while.
So yeah, this time, don’t wait, test now.
1 Like
Your date and time are wrong. Maybe thats the reason for the ssl error.
but it’s wrong only on the new container logs
it’s right on my system
$ date
mar 22 mar 2022, 13.03.56, CET
and on the “old” container
2022-03-22T12:05:36.064Z INFO piecestore downloaded
I’m not sure if this has something to do with the broken network issue on alpine.
There is a workaround here (alpinelinux/docker-alpine#135 (comment)) which requires raspberry pi users to upgrade to a newer libseccomp2 from Debian Buster until Raspbian upgrades:
wget http://ftp.de.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.5.1-1_armhf.deb
dpkg -i libseccomp2_2.5.1-1_armhf.deb
Edit: upgrade libseccomp2 to 2.5.3-2 package; 2.5.1-1 is unavailable
wget http://ftp.de.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.5.3-2_armhf.deb
dpkg -i libseccomp2_2.5.3-2_armhf.deb
@bota87, to help debug this, could you please pull the official alpine image and open the terminal:
docker run -it --rm alpine:3.15 ash
Check date:
/ # date
Test wget:
/ # wget -O- https://version.storj.io/processes/storagenode-updater/minimum/url?os=linux&arch=arm
before upgrading libseccomp2 (current version 2.3.3-4)
$ docker run -it --rm alpine:3.15 ash
Unable to find image 'alpine:3.15' locally
3.15: Pulling from library/alpine
205cbce5da6d: Already exists
Digest: sha256:d6d0a0eb4d40ef96f2310ead734848b9c819bb97c9d846385c4aca1767186cd4
Status: Downloaded newer image for alpine:3.15
/ # date
Fri Jul 3 18:27:44 UTC 2071
/ # wget -O- https://version.storj.io/processes/storagenode-updater/minimum/url?os=linux&arch=arm
/ # wget: bad address 'version.storj.io'
after upgrading libseccomp2 to 2.5.3-2 package (the one you provided was unavailable)
$ docker run -it --rm alpine:3.15 ash
/ # date
Tue Mar 22 14:23:43 UTC 2022
/ # wget -O- https://version.storj.io/processes/storagenode-updater/minimum/url?os=linux&arch=arm
/ # Connecting to version.storj.io (35.224.88.204:443)
wget: server returned error: HTTP/1.1 400 Bad Request
so the date is correct now, but download still fail
Download might fail on the official alpine docker image since it uses BusyBox wget instead of GNU wget. We use GNU wget in the storagenode image so download should work.
Now that you’re done upgrading the libseccomp2 package, you can test the storagenode docker image again.
It’s working now! But I see a lot of errors, it’s all ok?
I removed the --dns entry suggested by @Alexey
Logs
Anyone using Synology and running version 1.50.4? If it doesn’t work. I don’t have time to fix it.
Right? Not sure, because no one has responded.
I think that you have to change the docker run command, replace the latest with the new version
1 Like
Right, see the first post