2 OCTOBER 2026 · LINUX ARM64
PR #7765
ARM64 runtime validation
Build AppImage with the static runtime toolset
Runtime passes; full UI remains unverified
The static ARM64 AppImage mounted normally and started T3's backend in an isolated Ubuntu 24.04.5 ARM64 VM without system libfuse2. Emulation became too slow to complete a reliable visual and restart check. This is a partial validation, not a full ARM64 application pass.
| Check | Observed result |
|---|
| Artifact architecture | Both control and static artifacts are AArch64 ELF binaries. |
| Application equality | T3 app.asar and the Electron executable have identical SHA-256 hashes in both packages. |
| Legacy control | Fails on missing libz.so. Providing an isolated compatibility link to the installed libz.so.1 exposes the expected missing-libfuse.so.2 failure. |
| Static runtime | Mounts as a real read-only FUSE filesystem. No extraction mode and no compatibility library shim. |
| Sandbox fallback | Ubuntu rejects the user-namespace probe. The launcher automatically adds --no-sandbox exactly once to the main Electron command. |
| T3 startup | Backend readiness confirmed at 00:14:53 UTC; main-window creation logged at 00:15:35 UTC. |
| Rendered interface and restart | Unverified. No usable UI screenshot was obtained. |
What was tested
Used the released Linux ARM64 T3 Code 0.0.44 payload, built with Electron 44.4.2. Repackaged it twice with electron-builder 26.15.6: once with the PR's toolsets.appimage = "1.0.3" setting and once without it. The application payload was not rebuilt from PR head 8ddfb92b0f.
The guest ran an ARM64 Linux kernel under QEMU on an x64 host. It had a working /dev/fuse device, FUSE 3, and no system libfuse.so.2. Tests used a fresh isolated T3 home. The graphical attempt used Xvfb and --disable-gpu.
Ubuntu's package-manager metadata generation was slow under emulation. Required ARM64 desktop packages were downloaded on the host from signature-verified Ubuntu repositories and unpacked into the disposable guest. No T3 application code was changed.
Recorded evidence
Architecture: aarch64
Kernel: 6.8.0-142-generic
fuse3: 3.14.0-5build1
No system libfuse.so.2
Namespace probe: Operation not permitted
Legacy control, with the isolated zlib compatibility link:
dlopen(): error loading libfuse.so.2
Static runtime mount:
static.AppImage /tmp/.mount_staticmdLPPl fuse.static.AppImage
ro,nosuid,nodev,relatime,user_id=1000,group_id=1000
Main Electron command:
/tmp/.mount_statickDEKiD/t3code --no-sandbox --disable-gpu
00:14:53.581 INFO: backend ready
00:15:35.952 INFO: main window created
The static artifact contains no libfuse.so.2 reference in its runtime. Its generated desktop entry uses Exec=AppRun %U; the control uses Exec=AppRun --no-sandbox %U.
What remains uncertain
The first cold start exceeded several 60-second readiness windows, then the backend became ready without changing the timeout. Rendering and screenshot capture remained unreliable. After resource adjustments, the guest eventually failed inside systemd initialization with “Failed to fork off sandboxing environment for executing generators: Protocol error”, before T3 could run.
These results support the ARM64 packaging fix. They do not establish a full graphical launch or restart pass, and they do not identify a PR regression. Native ARM64 hardware or a hardware-accelerated ARM64 VM is the appropriate place to finish those checks. ARM64 updater transitions, tray behavior, notifications, and accelerated graphics were not tested.
Merge assessment: the demonstrated runtime fix adds confidence to the earlier x64 validation. The ARM64 UI and restart gap remains explicit for Julius's review.
The VM, temporary disk, SSH key, builds, and test server have been removed. The repository was left unchanged. No GitHub comment, approval, or merge was performed.