Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting rid of FUSE filesystem #361

Closed
TheAssassin opened this issue Sep 28, 2020 · 2 comments
Closed

Getting rid of FUSE filesystem #361

TheAssassin opened this issue Sep 28, 2020 · 2 comments
Labels
enhancement New feature or request high priority Should be worked on before looking at other issues

Comments

@TheAssassin
Copy link
Owner

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.

@Finn0811
Copy link

Works great after a quick first test on a raspberry pi 4, raspbian buster. Thanks a lot for this update!

@TheAssassin
Copy link
Owner Author

Released as part of 2.2.0. The FUSE filesystem is now gone completely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request high priority Should be worked on before looking at other issues
Projects
None yet
Development

No branches or pull requests

2 participants