You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Disclaimer: It is my assumption that the auto-update function is the cause, and below is my thought process.
I have been using this Docker image for a while now, and I have realized that sometimes when I restart the container, proton-bridge binary no longer starts. It gives exec format error in the logs, which probably means that the binary is for another architecture than what is on the host. But it was running fine up until I restarted the container.
Why does the architecture of the binary suddenly change, when previously it was running without problem? I also noticed that the binary that it tried to run has a different version number than the one which I had previously built. The last time I rebuilt the image it was 3.14.0, but the logs now show me that it is trying to launch 3.16, which I did not build.
So putting two and two together, my guess is that the binary tries to look for a newer version at startup, and found a newer version from official source (Proton). It downloads the newer binary, without checking the architecture. The amd64 newer binary replaced the arm64 older binary that I built, and then it fails to start because of wrong architecture.
What this essentially means is that whenever a newer version is available from Proton, older version of this unofficial Docker image will stop working. This also means the build tag of the image only run built binaries until there is a newer version available from Proton, then it'll run the downloaded binary instead.
The solutions are unfortunately impractical/hard to implement:
Disable auto update by modifying upstream source (there's no command line option to disable currently)
Make binary check architecture before downloading update, which also need changes from upstream
Do auto update in this container image instead, build new arm64 version if there is new version available
The text was updated successfully, but these errors were encountered:
yeah it's busted. it's not possible to disable the auto update atm, but it's going to be possible when the proton-bridge config tool parsing code in (#110) gets added.
Disclaimer: It is my assumption that the auto-update function is the cause, and below is my thought process.
I have been using this Docker image for a while now, and I have realized that sometimes when I restart the container,
proton-bridge
binary no longer starts. It givesexec format error
in the logs, which probably means that the binary is for another architecture than what is on the host. But it was running fine up until I restarted the container.Why does the architecture of the binary suddenly change, when previously it was running without problem? I also noticed that the binary that it tried to run has a different version number than the one which I had previously built. The last time I rebuilt the image it was 3.14.0, but the logs now show me that it is trying to launch 3.16, which I did not build.
So putting two and two together, my guess is that the binary tries to look for a newer version at startup, and found a newer version from official source (Proton). It downloads the newer binary, without checking the architecture. The
amd64
newer binary replaced thearm64
older binary that I built, and then it fails to start because of wrong architecture.What this essentially means is that whenever a newer version is available from Proton, older version of this unofficial Docker image will stop working. This also means the
build
tag of the image only run built binaries until there is a newer version available from Proton, then it'll run the downloaded binary instead.The solutions are unfortunately impractical/hard to implement:
arm64
version if there is new version availableThe text was updated successfully, but these errors were encountered: