fuse-3?

[2011]

$ /path/to/any.AppImage 
dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
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

$ ls -al /usr/lib64/libfuse3.so*
lrwxrwxrwx 1 root root     13 2020-10-17 05:19:09 /usr/lib64/libfuse3.so -> libfuse3.so.3*
lrwxrwxrwx 1 root root     17 2020-10-17 05:19:09 /usr/lib64/libfuse3.so.3 -> libfuse3.so.3.9.1*
-rwxr-xr-x 1 root root 249552 2020-10-17 05:19:11 /usr/lib64/libfuse3.so.3.9.1*

I found nothing in the documentation mentioning version 3 of fuse, but do note that fuse-3.0.0 arrived in 2016, and the (dead) version 2 has seen no releases in more than two years. I don't understand why you still use version 2.

In searching through issues before making this post, I noticed somebody suggesting that you include (the relevant parts of) fuse in the AppImages. I heartily endorse that idea.

[probonopd]

Please install libfuse2 for now; systems like CentOS 6 and 7 still need it. Ubuntu xenial, the oldest still-supported Ubuntu LTS release, also uses it: https://packages.ubuntu.com/de/xenial/libfuse2 So we do not want to drop libfuse2 support.

As far as I know, no one has started working on (optional) support for libfuse3 so far. Would it be feasible to link libfuse statically into the embedded AppImage runtime, and would this solve these sorts of issues? This would increase size for the sake of increasing compatibility.

[TheAssassin]

You could just dlopen() and call the functions from there like it is done with libfuse2 currently. Would be easier. Also a chance to clean up the mess in the runtime, and extract all fuse-related things into some separate module.

[2011]

Would it be feasible to link libfuse statically into the embedded AppImage runtime, and would this solve these sorts of issues? This would increase size for the sake of increasing compatibility.

The entire libfuse3 dynamic library weighs in at less than 250K on my machine (I would expect an even smaller size for libfuse2). The increase in size for each AppImage (assuming you only linked in the relevant function calls) seems absolutely trivial relative to the gains in user experience. Plus it solves your problem of having to switch later. Some distributions have started to get very strict about removing apps that link to unmaintained software (Python 2.7.x or Gtk+ 2.24.x, to name two), and I expect that those distributions won't even package libfuse2 by the end of the year.

[probonopd]

distributions won't even package libfuse2

Then those distributions don't have a very backward/LTS compatible mindset. In my opinion, when a new major version of a library comes along, the last major version should be carried alongside at least until even the oldest still-supported LTS releases come with the new major version, plus some extra grace period.

[2011]

I don't mean to sound too argumenative here, but doesn't most LTS last about two years (people usually don't get that on many phones)? Libfuse2 has (already) died more than two years ago. Dead software doesn't have the number of eyes looking at it for potential security vulnerabilities, and distribution maintainers almost always have limited resources (and do always have demands that far exceed those resources). I can tell you that distribution packagers hate few things more that having to expend the effort required to maintain applications that demand deprecated versions of tools (and the tools often need patching themselves because other things have changed in the meantime).

Some upstream developers will simply never upgrade if they can get away with it (I know software that still requires a version from the last millennium of a common tool). Why doesn't the project upgrade? I have no idea, but can only guess some combination of arrogance, ignorance, and laziness.

[probonopd]

phones

Phones are clearly not our reference point. In fact, most phones become un-usable after just a few years due to them being abandoned shortly after they have been produced. I know people who are still running 10-year old desktop operating systems, ad I am typing this on a workstation that is over 10 years old and still working perfectly fine.

I can tell you that distribution packagers hate few things more that having to expend the effort required to maintain applications that demand deprecated versions of tools

And that is exactly why we need something like AppImage that embraces backward compatibility to older systems. Many distributions simply don't care and that is a problem.

Why doesn't the project upgrade? I have no idea, but can only guess some combination of arrogance, ignorance, and laziness.

Caring about users who do not want, or cannot, upgrade their operating system every couple of years.

In my personal optinion, distributions should continue to ship the -compat ("old") version of a library until it is absolutely clear that everyone (including users of distributions such as RHEL) have the new version. This would promote binary compatibility. Why don't distributions care about binary compatibility? I have no idea, but can only guess some combination of arrogance, ignorance, and laziness.

[2011]

This would promote binary compatibility.

So would not requiring libfuse at all, and placing the function calls needed directly in each AppImage.

Why don't distributions care about binary compatibility? I have no idea, but can only guess some combination of arrogance, ignorance, and laziness.

That seems specious to me. Distributions often have limited resources (and requests from users to add additional packages). Attempting to include deprecated libraries (especially those where the discovery of security flaws makes that more difficult) places a tremendous load on those resources. When the developer of a library moves to a new (and incompatible) version, application developers who continue to use to old library force every distribution that includes that application to do extra work. Eventually that becomes quite selfish (although libfuse2 remains recent enough that I don't mean to include applications that link to it in that description).

[probonopd]

So would not requiring libfuse at all, and placing the function calls needed directly in each AppImage.

True, unless we still need to invoke commands like fusermount that need to be binary compatible (which I have not investigated yet).

places a tremendous load on those resources

Maybe the sweet spot would be to carry (and co-install by default) the current-1 major version, and deprecate it thereafter. Something like that. So that there is an overlap in available major library versions in all distributions (from Enterprise/LTS to bleeding edge) at any point in time. But I suspect that this kind of thinking may be alien to many distributions.

Well, in pragmatic terms, I think we should try what @TheAssassin has suggested: If libfuse.so.2 cannot be dlopen()ed, then try to dlopen() libfuse.so.3 (and hope that nothing has changed in a breaking way).

If this doesn't work, we can always think about not requiring libfuse (and fusermount, in case we currently do) at all...

[haampie]

@probonopd what do you mean with using fusermount? I grepped it and didn't see it in the sources (including submodules).

I'm kinda interested in a static version of runtime that has libfuse linked into it. For my use case (high-performance computing) I really don't need all the desktop/icon/update/install stuff that come with AppImages, I just need the self-mounting squashfs. Indeed both libfuse3.so and libfuse.so are roughly 250K, so that's a size I can live with. Any obvious downsides to this?

[haampie]

squashfuse is used, not fusermount it seems

[probonopd]

Doesn't squashfuse use fusermount internally? Not 100% sure

[haampie]

I think squashfuse is just calling libfuse functions, and I would presume that ultimately calls fusermount yes, because at least on my distro (ubuntu 20.04) that is a setuid binary

[haampie]

Yeah, one way to figure this out is by running strace -f which dropt the setuid flag for those binaries, and then the program fails:

$ strace -f -o out.txt ./my.AppImage
fusermount: mount failed: Operation not permitted

[haampie]

I quickly looked into this, but the latest tagged version of squashfuse doesn't play well with libfuse 3 (apparently @TheAssassin's patches were upstreamed to Debian for the libsquashfuse0 package -- stuck on the same version then); meaning that most people likely use libfuse 2 anyways. I've created an issue in that repo to ask them to release a new version: https://github.com/vasi/squashfuse/issues/50.

[haampie]

Actually there is a licensing issue when you statically link libfuse, because it is licensed LGPL. dlopen doesn't run into these issues so should be preferred.

[TheAssassin]

Static linking sure isn't the way to go. I wonder why this licensing issue was found just now, not a couple days ago.

I think this is the perfect opportunity for some polymorphy. The strategy pattern comes into my mind, but since this is pure C, well... I guess a struct containing function pointers is going to have to do. We just need 2-3 functions in such an API, wrapping libfuse2 and libfuse3 respectively. A factory can initialize a struct accordingly, preferring libfuse3, but falling back to libfuse2 if needed:

#include <stdio.h>
#include <assert.h>

typedef struct {
    int (*mount)(char*, ...);
    int (*unmount)(char*, ...);
} fuse_handler_t;

fuse_handler_t* make_fuse_handler() {
    return NULL;
}

int main() {
    fuse_handler_t* fuse_handler = make_fuse_handler();

    assert(fuse_handler != NULL);

    fuse_handler->mount(...);

    /* wait until app in AppImage terminates */

    fuse_handler->unmount(...);
}

Such a FUSE handler could even hold some state, if needed.

[haampie]

Pardon my ignorance, but do you really need to call directly into libfuse in AppImageKit at all? Isn't everything handled through SquashFUSE? SquashFUSE 0.1.104 supports both libfuse2 and libfuse3, and the master branch (which is hopefully tagged soon) adds libsquashfuse_ll.a as a separate lib, so you would only have to move the (new) ll_main.c function into AppImageKit's runtime.c if you insist on not invoking squashfuse_ll as an executable.

Maybe squashfuse can be improved a bit to add support for using dlopen to load either libfuse2 or libfuse3 instead of fixing that at compile time.

[probonopd]

squashfuse is compiled in.

[TheAssassin]

We use a specific version of squashfuse, patched to load libfuse with dlopen.

[haampie]

There's currently some active development in squashfuse, I don't think it's a lot of fun to maintain those patches or stick to a fixed vendored version (also for me, cause I want to build an optimized runtime.c in spack without vendored deps (e.g. i want to use the latest zstd for compression)). Wouldn't it make more sense to just open an issue in the squashfuse repo about this use case? The facebook xar people basically have the same issue and are developing squashfuse too; they currently just assume that squashfuse_ll is in the PATH to work around api/abi issues of libfuse, but they also have an open issue where someone wants to link squashfuse_ll.a instead.

[haampie]

https://github.com/vasi/squashfuse/issues/60

[haampie]

They are unfortunately not interested in supporting fuse and fuse3 at the same time

[almereyda]

Another tool from the AppImage ecosystem, https://github.com/vinifmor/bauh/, is also offering to be used with fuse (2) and fuse3. Unfortunately it's written in Python, and therefore uses an abstraction that could not be reused here.

What is blocking us here from offering both, the dependency on squashfuse and having to use dlopen?

Two comments from the linked thread stand out:

@chipturner I am concerned all of these options add a bit of complexity for fairly niche use case. What systems only have libfuse2? libfuse3 is four years old and the last release of libfuse2 was Jan 2019.

seconding the argumentation from @2011 .

@vasi How bad would it be to just build separate binaries, and have a small wrapper choose between them at runtime? Most Linux games do something like that.

providing a suggestion which could maybe work here, too?

Please note that the error message displayed in the OP will also be sent as a notification to GNOME, and with the appimaged.service trying to restart every few seconds, this fills up the notification drawer, and also the journal.

`journalctl --user -u appimaged.service | grep 'restart counter' | tail -n 50`

``` Sep 01 22:32:13 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2049. Sep 01 22:32:17 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2050. Sep 01 22:32:20 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2051. Sep 01 22:32:23 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2052. Sep 01 22:32:26 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2053. Sep 01 22:32:30 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2054. Sep 01 22:32:33 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2055. Sep 01 22:32:36 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2056. Sep 01 22:32:39 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2057. Sep 01 22:32:43 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2058. Sep 01 22:32:46 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2059. Sep 01 22:32:49 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2060. Sep 01 22:32:52 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2061. Sep 01 22:32:56 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2062. Sep 01 22:32:59 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2063. Sep 01 22:33:02 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2064. Sep 01 22:33:05 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2065. Sep 01 22:33:09 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2066. Sep 01 22:33:12 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2067. Sep 01 22:33:15 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2068. Sep 01 22:33:18 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2069. Sep 01 22:33:22 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2070. Sep 01 22:33:25 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2071. Sep 01 22:33:28 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2072. Sep 01 22:33:31 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2073. Sep 01 22:33:35 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2074. Sep 01 22:33:38 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2075. Sep 01 22:33:41 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2076. Sep 01 22:33:44 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2077. Sep 01 22:33:48 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2078. Sep 01 22:33:51 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2079. Sep 01 22:33:54 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2080. Sep 01 22:33:57 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2081. Sep 01 22:34:01 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2082. Sep 01 22:34:04 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2083. Sep 01 22:34:07 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2084. Sep 01 22:34:10 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2085. Sep 01 22:34:14 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2086. Sep 01 22:34:17 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2087. Sep 01 22:34:20 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2088. Sep 01 22:34:23 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2089. Sep 01 22:34:26 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2090. Sep 01 22:34:30 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2091. Sep 01 22:34:33 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2092. Sep 01 22:34:36 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2093. Sep 01 22:34:41 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2094. Sep 01 22:34:45 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2095. Sep 01 22:34:49 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2096. Sep 01 22:34:52 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2097. Sep 01 22:34:56 ganglion systemd[15024]: appimaged.service: Scheduled restart job, restart counter is at 2098. ```

[alt-art]

I have a suggestion, introduce a vulnerability in fuse2 to make everyone migrate to fuse3.

[pkkid]

Steam on Ubuntu 22.04 requires fuse3 for xdg-desktop-portal. This seems to make it not really possible to have both Steam installed and use AppImages on the same system unless I am missing something. It's not this projects job to support all environments, but worth noting that an incompatibility with one of the most popular apps in Linux will make using AppImages a non starter for many.

[probonopd]

Are you saying fuse2 and fuse3 cannot be installed at the same time @pkkid? What happens if you do? AppImages require fuse2 to be installed and configured.

[pkkid]

In Ubuntu 22.04 it doesn't seem to let me install both. I have fuse3 installed right now, and if I try to install fuse, it shows the following. When I had fuse2 installed previously, Steam keeps prompting me and attempting to install fuse3 every time I open it. Maybe I can manually build and install both at the same time? Doesn't seem like something I really want venture into unless there was an AppImage I absolutely needed.

22:03:42 pkkid-ubuntu ~: sudo apt-get install fuse
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libfuse2
The following packages will be REMOVED:
  fuse3 xdg-desktop-portal xdg-desktop-portal-gtk
The following NEW packages will be installed:
  fuse libfuse2
0 upgraded, 2 newly installed, 3 to remove and 11 not upgraded.
Need to get 0 B/117 kB of archives.
After this operation, 1,120 kB disk space will be freed.
Do you want to continue? [Y/n] 

[haampie]

I think it would be easiest to just statically link libfuse; it should be OK with MIT being a compatible license, and it just affects the runtime. At the end of the day libfuse is a fancy way to execute fusermount (the setuid binary), and I don't think there's incompatibilities wrt command line arguments. I'm doing that here: https://github.com/eth-cscs/spack-batteries-included

[probonopd]

https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041530.html:

Fuse3 is a requirement for qemu 6 [1]. Since we don't want to support two versions of fuse in main, we'd like reverse-dependencies of fuse to switch to fuse3.

Argh. Trouble is to be expected. This means that all existing AppImages will not run on Ubuntu unless the user manually installs libfuse2 from a non-default official repository. Something that is too difficult for "normal end users" to do.

Please talk to upstreams and investigate what changes are required to these packages

Distributions often blindly assume that users are updating everything to the latest versions of everything all the time. Which is not how I see things. Once I have a version of an application that works well for me the last thing I want is to be forced to update it. (At most, I download the new version in addition to the known good one to check out the new features and check for new showstoppers.)

If I understand it right, it Looks like https://github.com/eth-cscs/spack-batteries-included is providing a solution for this. Should we backport these changes into the AppImage runtime?

[probonopd]

@pkkid please try sudo apt-get install libfuse2.

[pkkid]

@pkkid please try sudo apt-get install libfuse2.

That installed with no issue, thanks. I'm not at my personal PC right now, so can't really try opening an AppImage until I get home. EDIT: Things are working fine with just libfuse2 installed. I guess I was trying to install the wrong package, thanks.

[2011]

Fuse3 is a requirement for qemu 6 [1]. Since we don't want to support two versions of fuse in main, we'd like reverse-dependencies of fuse to switch to fuse3.

Argh. Trouble is to be expected. This means that all existing AppImages will not run on Ubuntu unless the user manually installs libfuse2 from a non-default official repository. Something that is too difficult for "normal end users" to do.

I did warn of this more than a year ago. Distributions don't want to maintain multiple versions. Fuse 3 arrived six years ago, and fuse 2 died three years ago. Who does not have fuse 3 available? Time to upgrade AppImage to work with fuse 3.

Distributions often blindly assume that users are updating everything to the latest versions of everything all the time. Which is not how I see things. Once I have a version of an application that works well for me the last thing I want is to be forced to update it. (At most, I download the new version in addition to the known good one to check out the new features and check for new showstoppers.)

I accept that few distributions make it easy to reject updates, but the vast majority of applications should work with current versions (abi compatible - not necessarily the latest releases) of standard system libraries.

[probonopd]

Things are working fine with just libfuse2 installed.

Thanks @pkkid for confirming.

So, installing libfuse2 is an immediate workaround until a proper solution is implemented. That solution must, however, not drop compatibility with systems using libfuse2.

[probonopd]

@haampie would you be willing to help us implement your solution?

[rwjack]

Ubuntu 22.04, temporary fix:

sudo add-apt-repository universe
sudo apt install libfuse2

[dinbtechit]

For someone who is running Ubuntu 22.04 on Virtual Machine can no longer copy files/clipboard info from the host machine (windows) after installing the fuse using the official instructions.

sudo apt install fuse libfuse2
. . .

But following @rwjack's instructions works like a charm.

sudo add-apt-repository universe
sudo apt install libfuse2

[BobSynfig]

From https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1965636

The AppImage format for distributing applications is centered around the idea that a user can boot the Ubuntu Live ISO, download an application in AppImage format, make it executable, and run it without having to install anything.

If you download your AppImage, it means you have access to the internet, the workaround is not too much time consuming nor complex.

In case you have already have your AppImages on a usb stick for example, there is a workaround if you don't have access to the internet:

• Download the libfuse2 package and extract the 2 libs
• Rename libfuse.so.2.9.9 as libfuse.so.2 and libulockmgr.so.1.0.1 as libulockmgr.so.1 and place them in the same directory as your AppmImages
• Create a little script AppRun.sh (same directory) to run an AppImage from the terminal containing

  #!/bin/bash
  LD_PRELOAD="./libfuse.so.2 ./libulockmgr.so.1" $1 $2 $3 $4 $5 $6 $7 $8 $9

  Just run ./AppRun.sh ./my-app.appimage Not marvelous but useful without connection ;)

[probonopd]

Instead of $1 $2 $3 $4 $5 $6 $7 $8 $9 use "$@".

[Ob1To]

Guys ... Many people using Ubuntu 22.04 started to write me about my application not running because Fuse2 was missing. I'm telling them to execute sudo add-apt-repository universe sudo apt install libfuse2 but they are not happy and more and more people start having problems. When a permanent fix would be implemented with Appimage?

[probonopd]

When a permanent fix would be implemented with Appimage?

Hello @Ob1To. Please direct feedback regarding Ubuntu's decision to suddenly start shipping libfuse2 by default to https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1965636.

The AppImage project is aware of the situation and we are currently evaluating different approaches. No ETA is available yet.

[Ob1To]

Can't you just implement Fuse3 support as well? I mean ... something like if(Fuse2 installed -> mount) else mount with Fuse 3? I'm not aware of how it works so I'm just curious why it can't be done. I doubt that Ubuntu will change its politics and support Fuse2 again when the decision has already been made. The problem is that more and more people are installing the latest LTS Ubuntu and our support is on constantly harassed about that problem.

[andylamp]

Note, for those who use Ubuntu and depend on projects using Applmage (such as Jetbrains Toolbox, Redis Insight). If you upgraded in 22.04 in order to fix the apps not launching you installed the missing fuse libraries then please note that they break the desktop. The icons disappear and the desktop becomes a non-interactive empty surface. To fix this you have to force reinstall ubuntu desktop in order to fix the issue. However, it is important to note that this breaks again AppImage as fuse package seems to be removed in the process.

[TheAssassin]

It's AppImage with an I.

Installing fuse apparently breaks stuff, but installing just libfuse2 seems to work.

As an update to this issue, in the background work is going on to provide fully static runtimes (or maybe runtimes that just depend on libc) in the future, including libfuse3.

[andylamp]

@TheAssassin sorry, I this was a typo in the first mention :). In the second, I got it right. Good to hear that work is underway... and huge thanks for the effort!

[probonopd]

Can't you just implement Fuse3 support as well?

Then it would break again when the next Linux distribution decides to no longer ship that one. So, this time we want a solution that will hopefully not break again.

Discussion continues at

• https://github.com/AppImage/AppImageKit/issues/877

[realnc]

Can't you just implement Fuse3 support as well?

Then it would break again when the next Linux distribution decides to no longer ship that one. So, this time we want a solution that will hopefully not break again.

Why not as a short-term fix for Ubuntu 22.04? The static runtime might take a while.

[probonopd]

Why not as a short-term fix for Ubuntu 22.04?

Only Ubuntu could do a short-term fix, namely, install libfuse2 by default. Some Ubuntu derivatives are already doing it (those with "Fix Released" on https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1965636). I recommend to use those Ubuntu derivatives for now because I doubt Ubuntu is going do do it (they value their distribution policies higher than ease-of-use for existing AppImages).

The static runtime might take a while.

No, in fact we have an experimental version available already.

[danryu]

Hopefully a fix will be implemented for this (despite it being marked Closed) as this is a show-stopper for AppImages on the current version of the dominant Linux desktop. Having to add repos and install deprecated libraries runs completely contrary to the streamlined UX I started integrating AppImage to provide :/

I fully understand the backward-compatibility arguments, but a bit of pragmatism would be useful in this scenario, bearing in mind Ubuntu 18.04 does not go out of support until mid-2023. That's a hell of a long overlap to expect up-to-date systems to have to jump through hoops.

https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1965636 shows status as "Won't Fix" for Ubuntu - the main version.

[probonopd]

Technically solved. We just need to make https://github.com/probonopd/go-appimage/releases/tag/continuous the official one sooner or later.

[danryu]

We just need to make https://github.com/probonopd/go-appimage/releases/tag/continuous the official one sooner or later.

That would be great - please go ahead and pull the trigger :)

Otherwise if there's a quick workaround or howto for using the test build in the meantime, that would also be much appreciated (CI workflow currently using linuxdeploy).