chore(image): bump upstream Gateway pin 10.45.1g → 10.45.1j - #27
Merged
Conversation
Same gnzsnz `:stable` line, three upstream patch releases forward, digest sha256:91165c07... On arm64 the bump also drops 112 MB of dead weight. The 10.45.1g aarch64 image carries jxbrowser-linux64-8.9.4.jar, and the libtoolkit.so inside it is an x86-64 ELF binary (e_machine 0x3e) that cannot execute on aarch64. That was a side effect of the pre-#397 build, which assembled aarch64 images from IBKR's x64 installer plus a Zulu JRE; upstream gnzsnz/ib-gateway-docker#397 moved aarch64 to IBKR's native arm installer, first published at 10.45.1h. Nothing usable is lost -- IBKR's arm installer does not carry the browser either way (their 10.45.1j artifacts are 320 MiB x64 against 206 MiB arm). The arm64 Java runtime changes with it: 10.45.1g used /usr/local/zulu17..., while 10.45.1j has no Zulu at all and uses install4j's own JRE registry under /usr/local/i4j_jres. The release-image.yml comment describing arm64 as Zulu-based is corrected accordingly. Validated rather than assumed: a controller image built on 10.45.1j passes tests/integration/gateway_autorestart_drill.py 17/17, so the install4j launcher, agent injection and the issue #23 restart-adoption path all work on the changed arm64 build. The same drill passes on 10.45.1g and on 10.50.1e. Login, 2FA and the dialog handlers are untouched by this bump and are not re-verified against a real account here. Noted while testing, not addressed here: on 10.45.1j arm64 the installed .install4j/inst_jre.cfg still points at the installer's build-time temp directory (/tmp/setup/...-arm.sh.NNNN.dir/jre), which does not exist at runtime. Upstream's template only rewrites that file when a <version>/jre directory exists, which the arm installer does not produce. Harmless today -- the launcher falls back to the i4j_jres registry, as the drill demonstrates -- but worth reporting upstream.
code-hustler-ft3d
force-pushed
the
chore/bump-stable-pin-10.45.1j
branch
from
September 7, 2026 16:19
d96c978 to
92b5313
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Same gnzsnz
:stableline, three patch releases forward, digestsha256:91165c07….Why now
Our pin dates from May. Beyond the usual upstream fixes, it is the last release built the old way on arm64, and that turns out to matter.
The 10.45.1g aarch64 image carries 112 MB that cannot run. It ships
jxbrowser-linux64-8.9.4.jar, and thelibtoolkit.soinside is an x86-64 ELF binary (e_machine0x3e) on an aarch64 image. That is a side effect of the pre-#397 build, which assembled aarch64 images from IBKR's x64 installer plus a Zulu JRE. Upstream gnzsnz/ib-gateway-docker#397 switched aarch64 to IBKR's native arm installer, first published at 10.45.1h — IBKR published no arm installer at all for 10.45.1g.Nothing usable is lost: IBKR's arm installer does not carry the browser either way (their 10.45.1j artifacts are 320 MiB for x64 against 206 MiB for arm).
The arm64 Java runtime changes with it. 10.45.1g used
/usr/local/zulu17…; 10.45.1j has no Zulu present and uses install4j's own JRE registry under/usr/local/i4j_jres. Therelease-image.ymlcomment describing arm64 as Zulu-based is corrected here.Validation
That runtime change is exactly the sort of thing that breaks launcher and JRE discovery, so this is measured rather than assumed. A controller image built on 10.45.1j passes
tests/integration/gateway_autorestart_drill.py17/17 — the real install4j launcher, agent injection into the real Gateway JVM, and the full issue #23 restart-adoption path. The same drill passes on 10.45.1g and on 10.50.1e.Login, 2FA and the dialog handlers are untouched by this bump and are not re-verified against a real account here.
Notes
.install4j/inst_jre.cfgstill points at the installer's build-time temp directory (/tmp/setup/…-arm.sh.NNNN.dir/jre), which does not exist at runtime. Upstream's template only rewrites that file when a<version>/jredirectory exists, which the arm installer does not produce. Harmless today — the launcher falls back to thei4j_jresregistry, as the drill shows — but worth reporting upstream.