Repository navigation
ci: the AppImage tooling runs without FUSE - #29
Merged
Merged
Conversation
Every Linux packaging job that goes through these actions dies after
about twenty minutes of building, at the first AppImage it has to write:
/usr/bin/fusermount3: mount failed: Operation not permitted
Cannot mount AppImage, please check your FUSE setup.
open dir error: No such file or directory
##[error]Process completed with exit code 127.
appimagetool is itself an AppImage, so running it needs either FUSE --
unavailable under rootless docker on the self-hosted host -- or
APPIMAGE_EXTRACT_AND_RUN. score's own appimage.yml sets that on the job,
with the same reasoning in a comment, and ci/appimage.deps.sh says in so
many words that libfuse2 is therefore not required; a caller reaching
the same scripts through these actions has to set it too, and did not.
Two steps need it, one per AppImage that gets written:
- custom-score-build's Build, which runs score's ci/appimage.build.sh
(this is where sat-mtl/livepose#83 failed)
- package-custom-app's Create custom app packages, which runs
tools/create-app-linux.sh for the app's own AppImage -- the next place
it would have failed
Checked with appimagetool on an AppDir with no fusermount on $PATH:
unset, exit 127 with the same "open dir error" line and no output file;
with the variable, exit 0 and the AppImage is written. The
`--appimage-extract` at create-app-linux.sh:57 was checked the same way
and needs no FUSE, so those two steps are the whole exposure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
jcelerier
added a commit
to ossia/score
that referenced
this pull request
Oct 11, 2026
`ci/appimage.build.sh` runs appimagetool, which is itself an AppImage, so
it needs either FUSE or APPIMAGE_EXTRACT_AND_RUN. FUSE is unavailable
under rootless docker on the self-hosted host, which is why
appimage.yml sets the variable on the job and appimage.deps.sh says in
so many words that libfuse2 is therefore not required.
The tool repositories reach the same script through
ossia/actions/custom-score-build, which did not set it, so every
packaging job that went that way died at the same place:
/usr/bin/fusermount3: mount failed: Operation not permitted
Cannot mount AppImage, please check your FUSE setup.
open dir error: No such file or directory
##[error]Process completed with exit code 127.
That is fixed in the action itself, in ossia/actions#29, which is what
actually unblocks the tools -- they pin the action at @master. The
default here is for anyone running the script by hand on a machine
without FUSE, and `${VAR:-1}` leaves a caller that wants FUSE able to
ask for it.
Reproduced and checked locally by running appimagetool on an AppDir with
no fusermount on $PATH: unset, it exits 127 with the same "open dir
error" line; with the variable, exit 0 and the AppImage is written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
jcelerier
added a commit
to ossia/score
that referenced
this pull request
Oct 12, 2026
`ci/appimage.build.sh` runs appimagetool, which is itself an AppImage, so
it needs either FUSE or APPIMAGE_EXTRACT_AND_RUN. FUSE is unavailable
under rootless docker on the self-hosted host, which is why
appimage.yml sets the variable on the job and appimage.deps.sh says in
so many words that libfuse2 is therefore not required.
The tool repositories reach the same script through
ossia/actions/custom-score-build, which did not set it, so every
packaging job that went that way died at the same place:
/usr/bin/fusermount3: mount failed: Operation not permitted
Cannot mount AppImage, please check your FUSE setup.
open dir error: No such file or directory
##[error]Process completed with exit code 127.
That is fixed in the action itself, in ossia/actions#29, which is what
actually unblocks the tools -- they pin the action at @master. The
default here is for anyone running the script by hand on a machine
without FUSE, and `${VAR:-1}` leaves a caller that wants FUSE able to
ask for it.
Reproduced and checked locally by running appimagetool on an AppDir with
no fusermount on $PATH: unset, it exits 127 with the same "open dir
error" line; with the variable, exit 0 and the AppImage is written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
jcelerier
added a commit
to ossia/score
that referenced
this pull request
Oct 12, 2026
`ci/appimage.build.sh` runs appimagetool, which is itself an AppImage, so
it needs either FUSE or APPIMAGE_EXTRACT_AND_RUN. FUSE is unavailable
under rootless docker on the self-hosted host, which is why
appimage.yml sets the variable on the job and appimage.deps.sh says in
so many words that libfuse2 is therefore not required.
The tool repositories reach the same script through
ossia/actions/custom-score-build, which did not set it, so every
packaging job that went that way died at the same place:
/usr/bin/fusermount3: mount failed: Operation not permitted
Cannot mount AppImage, please check your FUSE setup.
open dir error: No such file or directory
##[error]Process completed with exit code 127.
That is fixed in the action itself, in ossia/actions#29, which is what
actually unblocks the tools -- they pin the action at @master. The
default here is for anyone running the script by hand on a machine
without FUSE, and `${VAR:-1}` leaves a caller that wants FUSE able to
ask for it.
Reproduced and checked locally by running appimagetool on an AppDir with
no fusermount on $PATH: unset, it exits 127 with the same "open dir
error" line; with the variable, exit 0 and the AppImage is written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
jcelerier
added a commit
to ossia/score
that referenced
this pull request
Oct 13, 2026
`ci/appimage.build.sh` runs appimagetool, which is itself an AppImage, so
it needs either FUSE or APPIMAGE_EXTRACT_AND_RUN. FUSE is unavailable
under rootless docker on the self-hosted host, which is why
appimage.yml sets the variable on the job and appimage.deps.sh says in
so many words that libfuse2 is therefore not required.
The tool repositories reach the same script through
ossia/actions/custom-score-build, which did not set it, so every
packaging job that went that way died at the same place:
/usr/bin/fusermount3: mount failed: Operation not permitted
Cannot mount AppImage, please check your FUSE setup.
open dir error: No such file or directory
##[error]Process completed with exit code 127.
That is fixed in the action itself, in ossia/actions#29, which is what
actually unblocks the tools -- they pin the action at @master. The
default here is for anyone running the script by hand on a machine
without FUSE, and `${VAR:-1}` leaves a caller that wants FUSE able to
ask for it.
Reproduced and checked locally by running appimagetool on an AppDir with
no fusermount on $PATH: unset, it exits 127 with the same "open dir
error" line; with the variable, exit 0 and the AppImage is written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq
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
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.
Every Linux packaging job that goes through these actions dies after about
twenty minutes of building, at the first AppImage it has to write. This is what
sat-mtl/livepose#83 only failing check was:
appimagetool is itself an AppImage, so running it needs either FUSE — which is
unavailable under rootless docker on the self-hosted host — or
APPIMAGE_EXTRACT_AND_RUN. score's ownappimage.ymlsets it on the job, withthis same reasoning in a comment, and
ci/appimage.deps.shsays in so manywords that libfuse2 is therefore not required. A caller reaching those same
scripts through these actions has to set it too, and did not.
Two steps, one per AppImage that gets written
custom-score-buildci/appimage.build.shpackage-custom-apptools/create-app-linux.shThe second one matters: livepose never got that far, so fixing only the first
would have moved the failure rather than removed it.
Verified
appimagetool on a minimal AppDir with no
fusermounton$PATH:open dir error: No such file or directory, no output file — the CI failure verbatimAPPIMAGE_EXTRACT_AND_RUN=1The
--appimage-extractatcreate-app-linux.sh:57was checked the same wayand exits 0 with no FUSE, so those two steps are the whole exposure.
Both files parse as YAML and the variable lands on the intended step only.
Why here rather than only in score
score is getting the same default in
ci/appimage.build.shthroughossia/score#2330, but every tool repo pins
ossia/actions/...@masterand builds score from score'smaster, so a fix thatlives only in score reaches none of them until that PR merges. This one takes
effect as soon as it lands.
🤖 Generated with Claude Code
https://claude.ai/code/session_019QYyvhRXvSMSRQPaq12Teq