AppImage / AppImage/AppImageKit

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

Ouverte
#828 28 commentaires 1 réaction 0 personnes assignées Voir sur GitHub
bug needs verification
Langage dominant
Aucune donnée de langage
Étoiles
9.4k
Forks
588
Métriques de merge des PR
Métriques de PR en attente

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.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.