AppImage / AppImage/AppImageKit

AppImages don't work in Docker containers any more (cause: magic bytes)

Open
#828 28 comments 1 reaction 0 assignees View on GitHub
bug needs verification
Dominant language
No language data
Stars
9.4k
Forks
588
PR merge metrics
PR metrics pending

Description

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.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.