Runtime binary testing

[azubieta]

We need to verify that the runtime contained in this repository runs in the all the system that the previous runtime used to and those with fuse3.

We have created a simple bash AppImage that uses this runtime, it's available at: https://github.com/azubieta/appimage-runtime/releases/tag/test

Please help us to run test it in your system. You just need to download and run it. In both scenarios please leave a comment with your tests results.

$ ./org.gnu.bash-x86_64.AppImage --version

GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Tests so far:

• Ubuntu 22.04 x86_64
• KDE Neon Unstable Edition x86_64
• Archlinux
• Fedora
• Centos

[stdevPavelmc]

Link is broken...

[stdevPavelmc]

Link fixed, downloading... RETECSA de fiesta, so hang on...

Working on Ubuntu 22.04 LTS amd64

[probal31]

Hello,

OS: KDE neon Unstable Edition x86_64

➜  Applications ./org.gnu.bash-x86_64.AppImage --version
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[probonopd]

I think we should test the "edge case" systems like Alpine Linux, NixOS, FreeBSD etc. and make sure that it runs well there. If it works even there, then more mainstream systems should probably also have no issues.

[nixos@nixos:~]$ chmod +x Downloads/org.gnu.bash-x86_64.AppImage 

[nixos@nixos:~]$ Downloads/org.gnu.bash-x86_64.AppImage 
execv error: No such file or directory

[nixos@nixos:~]$ cat /etc/os-release 
NAME=NixOS
ID=nixos
VERSION="21.11 (Porcupine)"
VERSION_CODENAME=porcupine
VERSION_ID="21.11"
BUILD_ID="21.11.337397.5656d7f92aa"
PRETTY_NAME="NixOS 21.11 (Porcupine)"
LOGO="nix-snowflake"
HOME_URL="https://nixos.org/"
DOCUMENTATION_URL="https://nixos.org/learn.html"
SUPPORT_URL="https://nixos.org/community.html"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"

This is not a bug of the runtime, merely the result of the contents of the AppImage not really bundling everything. We get the same message on the extracted AppDir.

[nixos@nixos:~]$ ./squashfs-root/AppRun 
bash: ./squashfs-root/AppRun: No such file or directory

So I think the runtime itself runs fine on NixOS.

It would be even greater to test an AppImage that can run on non-gibc systems as well.

[probonopd]

On helloSystem FreeBSD https://github.com/helloSystem/ISO/releases/tag/r0.7.0:

FreeBSD% ./org.gnu.bash-x86_64.AppImage      
fuse: mount failed: Filename too long

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
open dir error: No such file or directory

FreeBSD% cat /etc/os-release 
NAME=FreeBSD
VERSION=13.0-RELEASE-p5
VERSION_ID=13.0
ID=freebsd
ANSI_COLOR="0;31"
PRETTY_NAME="FreeBSD 13.0-RELEASE-p5"
CPE_NAME=cpe:/o:freebsd:freebsd:13.0
HOME_URL=https://FreeBSD.org/
BUG_REPORT_URL=https://bugs.FreeBSD.org/

The fuse: mount failed: Filename too long may be a bit misleading:

This is likely caused by https://reviews.freebsd.org/D30606 which suggests that the culprit is the long fstypename that squashfuse is using.

When you have a couple of AppImages running (on a Linux system) and type mount, then instead of seeing simple filesystem names like squashfuse you see that the AppImages have long-winded filesystem names like fuse.scribus-1.5.6.1-linux-x86_64.AppImage. And FreeBSD doesn't like these.

If we could patch squashfuse and/or libfuse so that it uses fuse.squashfuse or fuse.appimage or squashfuse instead of things like fuse.scribus-1.5.6.1-linux-x86_64.AppImage, then it would probably work.

man fuse says:

       These are FUSE specific mount options that can be specified for
       all filesystems:

       fsname=NAME
              Sets the filesystem source (first field in /etc/mtab). The
              default is the name of the filesystem process.

       subtype=TYPE
              Sets the filesystem type (third field in /etc/mtab). The
              default is the name of the filesystem process. If the
              kernel supports it, /etc/mtab and /proc/mounts will show
              the filesystem type as fuse.TYPE

              If the kernel doesn't support subtypes, the source field
              will be TYPE#NAME, or if fsname option is not specified,
              just TYPE.

So it's possibly a matter of passing them in.

(This was apparently fixed in the FreeBSD source but so far the fix has not arrived on real world ISOs, so fixing this also in the AppImage runtime would be a good idea.)

Reference:

• Use "fuse" fstype instead of "fuse.<name-of-the-AppImage>" AppImage/type2-runtime#83
• Backport TARGET_APPIMAGE and set fsname and subtype to squashfuse probonopd/static-tools#29

[mmtrt]

Test appimage fails on Ubuntu 22.10.
static.log