I've recently managed to get rid of the FUSE filesystem, which caused a lot of trouble. The new method to launch AppImages consumes a little bit more RAM, but should perform better.
The problem hasn't changed at all: we still need to bypass binfmt_misc, and the only way is to remove the magic bytes from the runtime. Instead of patching the existing files, copying them and patching them then or alike, AppImageLauncher now extracts the runtime from the AppImages into an in-memory file, erases the magic bytes and launches it.
This creates another issue: the runtime needs to be convinced to use the original AppImage. Recent type 2 AppImages support that out of the box (using $TARGET_APPIMAGE) and this was used in the past in some way (we shipped a custom runtime without the magic bytes, which is not a good idea for many other reasons). However, there's still old AppImages out there that need to run as well.
To fix this new problem, I wrote a library that provides a few custom implementations of libc methods (open, readlink etc.), recognizes the cases when the runtime tries to calculate its own path and returns the path to the original AppImage. It is injected in the runtime binary using $LD_PRELOAD. This approach is compatible with both type 1 and type 2 AppImages, and works fine with a few dozens of AppImages I had on hand. It's yet another a hack, but it's a lot less code, less internal state, and therefore should be much more robust than the filesystem already.
The original proof of concept is available in https://github.com/TheAssassin/appimage-binfmt-bypass. This code was imported into AppImageLauncher, refined and improved a lot and appears to work stable enough so that a new release is being prepared right now.
Please don't hesitate to get the latest continuous build and test it. I need feedback from as many people as possible. I've tested the new approach a bit and couldn't discover any issues, but my time is limited, so let's crowd-source this a bit. We can use this issue to collect feedback, and create new ones on demand if there should be bugs.
Note that while you can shut down the appimagelauncherfs systemd unit already, this will make all AppImages running at the moment crash sooner or later. The problem will be fixed by itself upon the next reboot. All newly launched AppImages should use the new method.
I'm closing all existing FUSE filesystem related issues soon, as they'll no longer be valid from the next release on.
P.S.: Note for self: replace old ELF size calculation code in libappimage with the new, improved C++ implementation in AppImageLauncher.
I've recently managed to get rid of the FUSE filesystem, which caused a lot of trouble. The new method to launch AppImages consumes a little bit more RAM, but should perform better.
The problem hasn't changed at all: we still need to bypass binfmt_misc, and the only way is to remove the magic bytes from the runtime. Instead of patching the existing files, copying them and patching them then or alike, AppImageLauncher now extracts the runtime from the AppImages into an in-memory file, erases the magic bytes and launches it.
This creates another issue: the runtime needs to be convinced to use the original AppImage. Recent type 2 AppImages support that out of the box (using
$TARGET_APPIMAGE) and this was used in the past in some way (we shipped a custom runtime without the magic bytes, which is not a good idea for many other reasons). However, there's still old AppImages out there that need to run as well.To fix this new problem, I wrote a library that provides a few custom implementations of libc methods (
open,readlinketc.), recognizes the cases when the runtime tries to calculate its own path and returns the path to the original AppImage. It is injected in the runtime binary using$LD_PRELOAD. This approach is compatible with both type 1 and type 2 AppImages, and works fine with a few dozens of AppImages I had on hand. It's yet another a hack, but it's a lot less code, less internal state, and therefore should be much more robust than the filesystem already.The original proof of concept is available in https://github.com/TheAssassin/appimage-binfmt-bypass. This code was imported into AppImageLauncher, refined and improved a lot and appears to work stable enough so that a new release is being prepared right now.
Please don't hesitate to get the latest continuous build and test it. I need feedback from as many people as possible. I've tested the new approach a bit and couldn't discover any issues, but my time is limited, so let's crowd-source this a bit. We can use this issue to collect feedback, and create new ones on demand if there should be bugs.
Note that while you can shut down the appimagelauncherfs systemd unit already, this will make all AppImages running at the moment crash sooner or later. The problem will be fixed by itself upon the next reboot. All newly launched AppImages should use the new method.
I'm closing all existing FUSE filesystem related issues soon, as they'll no longer be valid from the next release on.
P.S.: Note for self: replace old ELF size calculation code in libappimage with the new, improved C++ implementation in AppImageLauncher.