AppImage / AppImage/AppImageKit
AppImages don't work in Docker containers any more (cause: magic bytes)
- Vorherrschende Sprache
- Keine Sprachdaten
- Sterne
- 9.4k
- Forks
- 588
- PR-Merge-Kennzahlen
- PR-Kennzahlen ausstehend
Beschreibung
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.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Bewertung
Dieses Issue wurde noch nicht bewertet.