won't run (fuse error) #3
Comments
|
This is a kind of AppImage that don't needs libfuse2 This issue seems to be a known one AppImage/type2-runtime#15 I'm investigating, please wait. |
|
What is your distro? I need to know how your fusermount installation is done. For me /usr/bin/fusermount is a symlink to /usr/bin/fusermount3 (i use Debian) |
|
Just found a discussion with an Arch Linux user in one of my projects: but the issue was been fixed. In brief, on Arch Linux fusermount is a binary from the fuse2 package and fusermount3 is a binary from fuse3, while on Debian fusermount is a symlink to fusermount3. @Samueru-sama was this been fixed in probonopd/go-appimage#278 ? |
|
EndeavourOS is based on Arch Linux, so fusermount is a binary from the fuse2 package and fusermount3 is a binary from fuse3, but this AppImage works for me
|
Thank you for all of the quick replies. Yes, you have certainly found the issue. I run Gentoo, and as you can see from my description of the issue, the fusermount binaries have permissions 4711. Changing the permissions solves the problem (though I won't want to leave them as 4755 forever, and any updates will return them to 4711). Thank you again. |
|
forgive my ignorance, can adding your user to some groups make a difference? |
|
The issue I had on archlinux was that I still needed fuse2 to run the furse3 appimages because the runtime was still looking for fusermount instead of fusermount3. On debian this issue didn't happen because fusermount is symlinked to fusermount3. However the issue was fixed and I can now run fuse3 appimages without needing fuse2 installed. The issue didn't have to do with permissions. On arch both @2011 Do you have this issue when running the EDIT: Also I think this is something that needs to be reported to gentoo, all other distros use 4755 for fusermount, I even used voidlinux for a few days and didn't have this issue, although I didn't check if I had fuse3 installed in voidlinux and it was defaulting to fuse2. |
I can't think of any. The binaries (as shown in my original post) get installed as root:root, but with the suid bit set.
Gentoo has different "slots" for fuse2 and fuse3 (meaning one can have both of them installed at the same time.
On Gentoo, I renamed
Yes (with permissions at 4711, it won't run - with the same error message as shown in my original post).
I can mention this in their forums, but I would expect to get a lot of resistance for a change like that (it would require many more users to complain to make something happen). From reading the linked issue in the first reply by @ivan-hc, it appears that the test for the existence of I see no activity on that issue over the past seven months. Not too surprising (things happen slowly in the AppImage world). I first brought up the issue of fuse 3 (to initial scorn, which soon changed to minor panic as distributions started dropping fuse 2) in AppImage/AppImageKit#1120 more than three years ago. |
Can you now try the appimage of amdgpu_top as that one is built with cargo appimage, it is also fuse3 compatible. This appimage didn't have the issue with the lack of symlink that I had before with go-appimage. Maybe it doesn't have this issue.
Also a bit off topic, but how much a small panic was this? On arch fuse2 is a dependency for ntfs-3g and mtpfs ,so I don't think any distro will remove fuse2 from their repos anytime soon. |
Exact same behavior.
If you read the replies to that issue, you would have seen it start when Ubuntu 22.04 came out (with fuse 3 and without the ability to install fuse 2 simultaneously), leading to lots of "I can't run AppImages any more" reports. Ubuntu did provide plenty of warning: https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041530.html
Gentoo uses fuse 3 for both of those. I would assume that Gentoo has kept fuse 2 around only to run AppImages. |
Oh boy, this isn't gonna be easy then. I think there is another implementation of appimagetool written in shell but I don't have high hopes that it will work.
I see, I knew that fusermount2 didn't come by default on ubuntu, but I didn't know that you couldn't have both installed. |
|
I don't know if this would be useful, but in case you wish to maintain just fuse3, my package manager "AM" allows you to install also just libfuse2 from the official Debian package using the command I don't really know how can I help you in ths case. |
I don't either, it's a shame cargo appimage also has the issue, because I have no problem switching all my appimages to use it. |
You probably can (manually, by renaming files and changing install directories, but Ubuntu doesn't support installing both simultaneously with their package manager).
As much as I override default behaviors in Gentoo, I feel comfortable simply having both versions around as long as Gentoo supports it (and just temporarily changing the file permissions on fusermount when required). Edit to add: The lists of files in each package suggests how Gentoo handles having both versions installed: |
You may want to write a script that automatically does this and checks the permissions of |
|
I had same issue with |
So the problem is that the appimage is hardcoded to look for If the symlink solves the issue even when you don't have read access, the solution is very simple then: Simply change the appimage to look for I think probono is going to reinstate the look for binary path, which was removed due to security concerns, but if the issue is that it was looking for |
|
I booted into alpine with distrobox, alpine also install fusermount to I tried this htop appimage since it contains a static binary and uses go-appimage with the static runtime.
@probonopd I think that all that needs to be done is look for |
|
Hi @Samueru-sama, I think this pull request might fix this: |
That doesn't work for me. I tried creating symlinks in /bin/, and running certain AppImages produces the same error as before. The suggested solution seems completely wroing to me. Instead of testing to see if the AppImage can read /usr/bin/fusermount or /usr/bin/fusermount3, the AppImage should test if it can execute /usr/bin/fusermount or /usr/bin/fusermount3. |
|
If there is a fusermount binary on the $PATH which cannot be executed, it's a broken FUSE setup. |
|
So some of the newly compiled ArchImage AppImages don't work for me, either. Debian Trixie, libfuse2t64 is installed, symlink to fusermount3 present: Also, they worked two days ago, maybe I've deleted something. |
|
@kenderipa Just to be sure that it is an issue with fuse, does the appimage work if you launch it with the |
Actually, it doesn't. It still shows the same fuse2 error. |
Okay that's very weird. EDIT: Do you have the same issue with any of the appimages that I maintain myself? example |
This one starts normally. |
Uhm... is it an issue of Archimages only? Please test from whatever you want from this list https://github.com/ivan-hc#my-appimage-packages |
I'm using both Abiword and Gnumeric, they work. |
|
Also, a VLC AppImage that I've compiled earlier based on ArchImage works, too. |
|
Hell, all other AppImages run, including Hedgewars, ScummVM and MAME, that I've compiled two days ago. Except yt-dlg and makemkv. |
|
So, I've tested around a bit. If an AppImage is started through launching the .AppIimafe file, it always works. If It's started via a symlink (for example, though zap integration, in my case, at ~/.local/bin), it throws a fuse2 error. Any suggestions? EDIT: symlink from /usr/bin works. |
symlink from |
|
@kenderipa You said "~/.local/bin", then... are you sure that this path is in $PATH? Try to install it using AppMan https://github.com/ivan-hc/AppMan , it prompts if you have not ~/.local/bin in $PATH |
It's in $PATH, yeah. Also, if I'm creating a symlink like this:
then the image doesn't work. With a symlink created like this:
it works. I'm assuming that AppMan integration doesn't change anything in this regard. |
Are you sure you are getting fuse2 errors? Can I see the entire error log? Because you said before that |
|
@Samueru-sama yt-dlg: |
|
@kenderipa how are done your archimages? can I see your scripts? |
|
I just booted into debian trixie with distrobox.
The chrome appimage works. @kenderipa where did you get the yt-dlg and makemkv appimages from? |
Built them myself. I'll post both scripts later. |
|
Here are those scripts. Nothing wild, as you can see. makemkvyt-dlg |
|
makemkv is still a Type2 AppImage, this is why it is looking for FUSE (libfuse2), you should update this script I'v erecognized that this is an old template (Archimage 3.2) |
|
About "yt-dlg", was this working before? I remember your previous issue where you have given up ivan-hc/ArchImage#25 |
I've probably built it earlier. It works, except when symlinked to .local/bin. |
|
@kenderipa I just build yt-dlg and ran it in both artix linux and the debian trixie container:
It works, but I don't have a |
I have no idea, why it doesn't work in my case. I hava a rather minimal system, perhaps something needed isn not installed. |
|
I've done it using the symlink to ~/.local/bin debug libs |
|
@kenderipa please try this other script I wrote for you yt-dlgits also a preview of a new improvement to my archimage project (the "liblibs" function is faster) |
Same as my version: works as long as it's not symlinked to ~/.local/bin. |
|
I close this issue for inactivity |
|
@2011 Seems the issue was just fixed: AppImage/type2-runtime#82 Can you confirm that it works? @ivan-hc manually run the CI so that a new release with the updated runtime is made. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have about thirty other AppImages that all run without any issues, but (first time I tried this AppImage):
Any ideas about what might cause this?
The text was updated successfully, but these errors were encountered: