Ignore it. No reason to triage further. See this
A new release is cooking. 1.114.6 should fix all of this.
The root cause of the problem was that we are trying to support Windows versions older than Windows 10 or Windows Server 2016. We’ve had to rig up some trickiness to build with Go 1.20 for the Windows build instead of Go 1.21, which we use elsewhere. The trickiness ended up being too tricky, because it tricked the release script into thinking we weren’t doing a release build. The FreeBSD build was affected only because it came after Windows.
Those of us who are looking at this currently would like very much to drop support for older Windows and save ourselves a bunch of headaches, but that probably isn’t an option yet.
I use Windows 2012 r2, version 1.114.5 broke on it too, so it will no longer be supported? I also had the client automatically update from 1.113.2 to 1.114.5 and got a time sync error, although over time everything is fine. I had to return the version and delete the databases
8 posts were merged into an existing topic: 1.107.3 Error: collector unable to delete pieces
Как вариант сделать несколько сборок под windows os, для старых и новых версий os, c постепенным отказом от поддержки старых win os?
Very problematic, we already have issues with the release because of only one different version. With more than one, it would be a cumbersome. We already updated our requirements instead. You always can migrate the outdated and not supported OS to a newer OS version or to Linux or FreeBSD or even specialized NAS software like TrueNAS.
на русском
Очень проблематично и дорого. Даже отдельная версия для Windows уже создала проблемы с релизом. Поддерживать больше одной это будет ещё хуже.
Мы уже обновили требования, старые Windows больше не поддерживаются. Вы можете либо обновить их, либо мигрировать на Linux/FreeBSD или использовать специализированные ОС для NAS типа TrueNAS
Would that imply I should disable this storage2.trust.sources again?
Currently enabled:
# list of trust sources
storage2.trust.sources: https://static.storj.io/dcs-satellites
QUIC error indeed disappeared overnight as the system upgraded to 1.114.6
Well it seems that my decision to do manual update is not bad at all…
I think you do not need to switch the source. The problem outside of it - we built a dev images for Windows and FreeBSD, and they are not allowed to join a production satellites.
Since it should be fixed in 1.114.6, you do not need to change the source of the trusted satellites from default, especially because it was not enough.
Not sure about it, but perhaps it could help to reveal issues like this earlier (I shared this issue with the team, but it wasn’t considered as an issue, because we initially though that the problem is in the source list, which wasn’t fully propagated). Anyway, I shared my thoughts that it could be related to a non-prod version (which was the correct root cause), but I thought that it is more related to using a non-released versions (I know that almost all beta releases are with a dev defaults, and they will not be accepted by a production satellites). But I didn’t know, that there was a bug related to exactly this problem - all builds are considered as dev even marked for release,
see details there:
So many broken releases… aren’t there nodes run by Storj team on every platform with a binary in the Github? Just for testing and preventing these situations?
If not, could it be useful for Storj team to gain access to SNOs nodes on different platforms who are willing to share their setup for testing purposes?
The SNO would manage the hardware part and gain the payout, the Storj would manage the software part.
I believe there are SNOs willing to do this.
You don’t need to take out that line, since it is the same as the default. However, it might be best if you do—only because if we ever have to change the default again (hopefully never) you will probably want the new default.
6 posts were split to a new topic: Are .io domains under threat?
2 reasons why not joining public testing sats:
- not payed;
- you need skills and time for testing and debugging, which many SNOs lacks.
That’s why I made the sugestion.
Yes, it is not payed paid but you can report issues the same way we report issues from running a paid node.