Hello all!
I am using AppImage to distribute an application. Up to now I didn't have any issues. Though a user [reported](https://github.com/teras/Jubler/issues/50) this strange error:
```
$ Jubler-8.0.0.x86_64_f04b7b62a0f9cbd9395031e743740db9.appimage
Squashfs image uses (null) compression, this version supports only xz, zlib.
ERROR: appimage_shall_not_be_integrated : sqfs_open_image error: ~/.local/bin/Jubler-8.0.0.x86_64_f04b7b62a0f9cbd9395031e743740db9.appimage
AppImageLauncher error: appimage_shall_not_be_integrated() failed (returned -1)
Squashfs image uses (null) compression, this version supports only xz, zlib.
ERROR: appimage_is_terminal_app : sqfs_open_image error: ~/.local/bin/Jubler-8.0.0.x86_64_f04b7b62a0f9cbd9395031e743740db9.appimage
AppImageLauncher error: appimage_is_terminal_app() failed (returned -1)
execv error: No such file or directory
```
I tried to my system and the [file](https://github.com/teras/Jubler/releases/download/v8.0.0/Jubler-8.0.0.x86_64.appimage) works perfectly. He mentioned that he's on Pop! OS 22.04 LTS, if this rings any bells. Any help?
Hello. How was that AppImage produced? What is the output of `--appimage-version`? Generally we are trying to standardize on zstandard compression. But I agree, the possibility of using null compression would also be desirable, e.g., to trade loading speed for size.
I am using a self-baked docker that makes the AppImage for me. I didn't explicit set and compression mechanism. I didn't find any command line argument for this, either.
The appimagetool declares itself as version "169". The created appimage `AppImage runtime version: https://github.com/probonopd/static-tools/commit/9bf80ec` .
The command that runs inside docker is something like: `bash -c 'export VERSION=8.0.0 && /opt/appimage/AppRun Jubler.x86_64.appdir"`
If you want to see the full log of the creation mechanism here it is. Of course it wasn't the original transcript, but it is the one I can rebuild (thank you docker). Also I don't want GPG and I don't want update information or anything like that, it makes more harm than good, from my point of view.
```
2025/07/28 13:23:25 Running inside Docker. Please make sure that the environment variables from Travis CI
2025/07/28 13:23:25 available inside Docker if you are running on Travis CI.
2025/07/28 13:23:25 This can be achieved by using something along the lines of 'docker run --env-file <(env)'.
2025/07/28 13:23:25 Please see https://github.com/docker/cli/issues/2210.
Jubler
2025/07/28 13:23:25 Architecture from AppRun: x86_64
2025/07/28 13:23:25 Apparently not in a git repository
2025/07/28 13:23:25 Target AppImage filename: Jubler-8.0.0-x86_64.AppImage
2025/07/28 13:23:25 Icon file: Jubler.x86_64.appdir/jubler.png
2025/07/28 13:23:25 WARNING: AppStream upstream metadata is missing, please consider creating it in
Jubler.x86_64.appdir/usr/share/metainfo/jubler.appdata.xml
Please see https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
for more information or use the generator at
https://appimagecommunity.github.io/simple-appstream-generator/
/opt/appimage/usr/bin/mksquashfs Jubler.x86_64.appdir Jubler-8.0.0-x86_64.AppImage -offset 594264 -fstime 1753709005 -comp zstd -root-owned -noappend -b 1M
Parallel mksquashfs: Using 32 processors
Creating 4.0 filesystem on Jubler-8.0.0-x86_64.AppImage, block size 1048576.
Exportable Squashfs 4.0 filesystem, zstd compressed, data block size 1048576
compressed data, compressed metadata, compressed fragments,
compressed xattrs, compressed ids
duplicates are removed
Filesystem size 40760.43 Kbytes (39.81 Mbytes)
59.59% of uncompressed filesystem size (68406.62 Kbytes)
Inode table size 1610 bytes (1.57 Kbytes)
26.33% of uncompressed inode table size (6114 bytes)
Directory table size 1741 bytes (1.70 Kbytes)
49.01% of uncompressed directory table size (3552 bytes)
Number of duplicate files found 3
Number of inodes 168
Number of files 118
Number of fragments 15
Number of symbolic links 24
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 26
Number of hard-links 0
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
Embedding ELF...
Marking the AppImage as executable...
Calculating the sha256 digest...
Assuming section .sha256_sig offset 583376 length 1024 to contain only '0x00's
Assuming section .sig_key offset 584400 length 8192 to contain only '0x00's
...hashing 583376 bytes
...hashing 1024 bytes as if they were 0x00
...hashing 8192 bytes as if they were 0x00
...hashing 41744008 bytes
Embedded .sha256_sig section Offset: 583376
Embedded .sha256_sig section Length: 1024
Writing into .sha256_sig section... 1024
Embedded .sha256_sig section now contains:
a3c73f43d64dd074176ad5e118b1151620ffd64f9ba9d6936185370cd0703f86
Could not read /pubkey.asc: open /pubkey.asc: no such file or directory
Almost a success
The AppImage was created, but is lacking update information.
Possibly it was built on a local developer machine.
Such an AppImage is fine for local use but should not be distributed.
```
One more comment, when creating it clearly states that it's "zstd" compressed. Could it be that on the host system, some kind of libraries are missing?
I can make the experiment. Still, as I said, it is not on a appimage that I used myself, but an appimage distributes and checked on a machine that I have no control.
I'll ask the person who made me the bug report to test with the new appimagetool.
btw, on the exec that you sent me, there's a tiny typo:
``` --comp Squashfs compression (default: zstd```
The parenthesis didn't close.
Also it is not obvious how to use the parameter (does it use arguments? what is the list of the valid arguments?) . Same goes for other parameterized options too.
It's really simple. I was using the simplest command line version that produces the AppImage. I would expect that it will use default compression.
I am not even sure if compression os on or off. How can I test it?
On the other hand when creating the image it says:
```
Exportable Squashfs 4.0 filesystem, zstd compressed, data block size 1048576
compressed data, compressed metadata, compressed fragments,
compressed xattrs, compressed ids
duplicates are removed
```
I was expecting that compression is on. If not, then something in-between is misleading.
"zstd compressed" - so it is using zstandard compression, as it should. And you are saying this AppImage is giving the error? On which systems can you reproduce it?
The system I tried didn't have issues. But still, this is a problem from my point of view. AppImage shouldn't do that stuff. It is designed to work. If it doesn't maybe there should ba a reason about it and needs to be investigated.
Of course this issue is not an easy one. If it were, I'd have solved it myself 😄
The user found what the issue was.
In the past he installed appimagelauncher which was breaking other appimages. When he unistalled this package then everything worked.
This is his report:
>
> I issued an strace and looked for anything that seemed odd. It generated a LOT of lines, many of which were No such file or directory. Some referred to appimagelauncher. I looked at the AppImage documentation and could find no mention of appimagelauncher. So, I went through my old notes, where I found an entry for August 12, 2021.
>
> As I stated above:
>
> > In 2021, due to another AppImage failing, I applied the recommended fix: Install AppImageLauncher (https://github.com/TheAssassin/AppImageLauncher/). I downloaded and installed the .deb.
>
> It was not there already. It is not part of the official AppImage project. I had to go to the GitHub repository, download it and install it in 2021 as suggested by the application developer:
>
> ```wget https://github.com/TheAssassin/AppImageLauncher/releases/download/v2.2.0/appimagelauncher_2.2.0-> travis995.0f91801.bionic_amd64.deb
> sudo apt install ./appimagelauncher_2.2.0-travis995.0f91801.bionic_amd64.deb
> ```
>
> And yes: I removed the one and only appimagelauncher that I installed in 2021.
Hi @teras, based on the information available so far we cannot do much unfortunately, since we cannot reproduce the issue.
So if you have the time, please test on 10-20 different Linux distributions and let us know where it works and where it does not work.
We need systematic bug reports, not "it does not work for one user but we cannot reproduce it".
Thank you very much.
I understand you point of view. Since this was just one incident, and the tests I've personally performed were up to now without problems, I'd consider the case closed. Still I gave the maximum of feedback I could to you, to help possibly future problems. Especially since the problem originated from a package that has origin from this repository.
Thank you for the discussions.