AppImages don't work in Docker containers any more

[TheAssassin]

A few weeks ago, I first noticed that some AppImages no longer run in Docker containers. This is a bit annoying especially when working with software like e.g., linuxdeploy, to build AppImages in those containers.

Now, the strange part is that I couldn't reproduce this on Travis yet. But tonight I found out that it must have something to do with the magic bytes in the ELF header. As mentioned previously (e.g., in #699), by embedding the magic bytes as we do currently, we occupy some "might be evaluated by interpreter" ones, which break other software, e.g., qemu. It seems like this is the case in those containers as well.

Temporary fix:

dd if=/dev/zero bs=1 count=3 seek=8 conv=notrunc of=my.AppImage

We should analyze whether this is a bug we caused while we changed the building of the runtime recently (see #818), or whether some component e.g., received an update, in the container. I'm pretty sure I've seen this issue before that PR was merged, though, and actually it'd be better if this was a bug in this container in my opinion.

A start would be to test this in other container images. I ran ubuntu:trusty containers, and we could check whether e.g., centos or opensuse containers yield the issue as well. We could also try this on the latest Ubuntu trusty live ISO.

Note: I tested a variety of AppImages and also the pure runtime, this is not limited to linuxdeploy only.

[luzpaz]

Is this still an issue ?

[probonopd]

I am running AppImages in Docker containers all the time on GitLab CI, it seems to work with --appimage-extract-and-run at least.

[luzpaz]

@probonopd Thanks for that. That is a relief because over at FreeCAD there is an idea of integrating AppImage generation via Docker builds.

[aniongithub]

This is still happening - I cannot use --appimage-extract-and-run for the Unity Hub AppImage and I can't use it from wothin docker at the moment. Help!?

Error: --appimage-extract-and-run is not yet implemented in version continuous-9-gaee2232

[probonopd]

Please ask Unity to use a more recent version of the AppImage tools from https://github.com/AppImage/AppImageKit/releases/tag/continuous. Then the AppImage will support --appimage-extract-and-run. In the meantime, maybe you can use --appimage-extract and the run AppRun manually?

[TheAssassin]

Another workaround: download the raw runtime from the release page @probonopd mentioned, then run like so:

> chmod +x runtime-x86_64
> env TARGET_APPIMAGE=my.AppImage APPIMAGE_EXTRACT_AND_RUN=1 ./runtime-x86_64 ...

[ExpandingMan]

I have been unable to run appimages inside of docker apparently because I can't seem to use FUSE.

I get fuse: device not found, try 'modprobe fuse' first. Needless to say, using modprobe does not work. This may be relevant.

Needless to say, this is pretty disruptive. Requiring different ways to deploy binaries in docker and on hardware is a pretty major obstacle to creating a reproducible setup.

[TheAssassin]

How is it AppImage's fault if your runtime doesn't provide the minimum requirements (which are, by the way, indeed documented, see https://docs.appimage.org/user-guide/troubleshooting.html#i-get-some-errors-related-to-something-called-fuse.

Also, this is not really a new issue. Beginning with Ubuntu xenial, Docker didn't permit FUSE access, as it can be unsafe to let Docker access those kernel features.

Anyway. You can use --appimage-extract-and-run or APPIMAGE_EXTRACT_AND_RUN=1, and it'll work just fine.

Requiring different ways to deploy binaries in docker and on hardware is a pretty major obstacle to creating a reproducible setup.

As said, Docker is not 100% equivalent to a bare metal installation. Your assertation is just incorrect IMO.

[ExpandingMan]

I'm not blaming AppImage, I'm just saying it's an issue.