fix(build): unpack the Linux builder where binfmt_misc hands AppImages to appimage-run (#66) #67

Merged

HumanBean merged 1 commit from mrdev023/LongshotLauncher:fix/66-appimage-binfmt into main

2026-11-14 20:03:04 +00:00

mrdev023 commented

2026-11-14 17:51:22 +00:00

Contributor

On NixOS with programs.appimage.binfmt (and with AppImageLauncher), step 1 never finishes: the builder's AppImage "could not be unpacked (137)". Fixes #66.

The kernel's binfmt_misc hands any file carrying AppImage's magic (AI\x02 at offset 8) to appimage-run, which unpacks the builder into its own cache and runs its AppRun --appimage-extract: the builder starts (its "no window of its own" dialog) and no squashfs-root is made.

Toolchains.HasAppImageBinfmt reads /proc/sys/fs/binfmt_misc: an enabled handler whose magic ends with 414902 (NixOS's at offset 0, AppImageLauncher's at offset 8). None where the folder is missing or unreadable.
Only then, ClearAppImageMagic zeroes those 3 bytes of the checked download before its --appimage-extract, so the kernel runs the AppImage's own runtime, which unpacks it in place. Elsewhere nothing changes.

Tested:

python -I tests/test_launcher_core.py: 964 checks passed (5 new: no handler, a disabled one, NixOS's, one at offset 8, the magic cleared and nothing else)
python -I tests/test_release.py: 28 tests OK
On NixOS with programs.appimage.binfmt = true: an AppImage made with scripts/package.sh from this branch installs the Nightly 143 builder, where the current nightly fails as in #66

Not covered: a handler whose mask makes it take AppImages without its magic ending with 414902.

AI Note:

Supervised by me: idea of the patch with conditional path for binfmt to avoid patch for everyone.
Code from Claude Code: Magic Code number and details come from Claude Code
Tested by me manually on NixOS with programs.appimage.binfmt = true;

On NixOS with `programs.appimage.binfmt` (and with AppImageLauncher), step 1 never finishes: the builder's AppImage "could not be unpacked (137)". Fixes #66. The kernel's binfmt_misc hands any file carrying AppImage's magic (`AI\x02` at offset 8) to `appimage-run`, which unpacks the builder into its own cache and runs its `AppRun --appimage-extract`: the builder starts (its "no window of its own" dialog) and no `squashfs-root` is made. - `Toolchains.HasAppImageBinfmt` reads `/proc/sys/fs/binfmt_misc`: an enabled handler whose magic ends with `414902` (NixOS's at offset 0, AppImageLauncher's at offset 8). None where the folder is missing or unreadable. - Only then, `ClearAppImageMagic` zeroes those 3 bytes of the checked download before its `--appimage-extract`, so the kernel runs the AppImage's own runtime, which unpacks it in place. Elsewhere nothing changes. Tested: - `python -I tests/test_launcher_core.py`: 964 checks passed (5 new: no handler, a disabled one, NixOS's, one at offset 8, the magic cleared and nothing else) - `python -I tests/test_release.py`: 28 tests OK - On NixOS with `programs.appimage.binfmt = true`: an AppImage made with `scripts/package.sh` from this branch installs the Nightly 143 builder, where the current nightly fails as in #66 Not covered: a handler whose `mask` makes it take AppImages without its magic ending with `414902`. AI Note: - Supervised by me: idea of the patch with conditional path for binfmt to avoid patch for everyone. - Code from Claude Code: Magic Code number and details come from Claude Code - Tested by me manually on NixOS with `programs.appimage.binfmt = true;`

mrdev023 added 1 commit

2026-11-14 17:51:22 +00:00

fix(build): unpack the Linux builder where binfmt_misc hands AppImages to appimage-run (#66 )

CI / Conventional Commit title (pull_request) Blocked by required conditions

Details

CI / Compile and test (pull_request) Blocked by required conditions

Details

95cf13c6ba

On NixOS with programs.appimage.binfmt (and with AppImageLauncher), the
kernel hands any file carrying AppImage's magic to appimage-run, which
unpacks the builder into its own cache and runs its AppRun with
--appimage-extract: the builder starts, shows its "no window" dialog and
exits, and no squashfs-root is made ("could not be unpacked (137)").

When an enabled binfmt_misc handler takes type 2 AppImages, the checked
download's magic is cleared before its --appimage-extract runs, so the
kernel runs the AppImage's own runtime, which unpacks it in place.

Co-Authored-By: Claude Opus 5.5 <<EMAIL_ADDRESS>>