Since Apr 17, 2025, Krita Next nightly appimages cannot start anymore. Older ones still works. Environment: Operating System: Manjaro Linux KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.9.0 Kernel Version: 6.14.0-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics Memory: 46.9 GiB of RAM Graphics Processor: AMD Radeon 780M Manufacturer: GPD Product Name: G1619-04 System Version: Ver.1.0 Run them in console returns the following message: ./krita-5.3.0-prealpha-036380b067-x86_64.AppImage fuse: memory allocation failed squashfuse 0.5.2 (c) 2012 Dave Vasilevsky Usage: squashfuse [options] ARCHIVE MOUNTPOINT (null) options: -o offset=N offset N bytes into ARCHIVE to mount -o subdir=PATH mount subdirectory PATH of ARCHIVE -o notify_pipe=PATH named pipe that will receive 's' (success) or 'f' (failure) when the mountpoint is ready -o timeout=N idle N seconds for automatic unmount -o uid=N set file owner to uid N -o gid=N set file group to gid N FUSE options: -h --help print help -V --version print version -d -o debug enable debug output (implies -f) -f foreground operation -s disable multi-threaded operation -o clone_fd use separate fuse device fd for each thread (may improve performance) -o max_idle_threads the maximum number of idle worker threads allowed (default: -1) -o max_threads the maximum number of worker threads allowed (default: 10) fuse: memory allocation failed squashfuse 0.5.2 (c) 2012 Dave Vasilevsky Usage: squashfuse [options] ARCHIVE MOUNTPOINT (null) options: -o offset=N offset N bytes into ARCHIVE to mount -o subdir=PATH mount subdirectory PATH of ARCHIVE -o notify_pipe=PATH named pipe that will receive 's' (success) or 'f' (failure) when the mountpoint is ready -o timeout=N idle N seconds for automatic unmount -o uid=N set file owner to uid N -o gid=N set file group to gid N FUSE options: -h --help print help -V --version print version -d -o debug enable debug output (implies -f) -f foreground operation -s disable multi-threaded operation -o clone_fd use separate fuse device fd for each thread (may improve performance) -o max_idle_threads the maximum number of idle worker threads allowed (default: -1) -o max_threads the maximum number of worker threads allowed (default: 10) squashfuse 0.5.2 (c) 2012 Dave Vasilevsky Usage: squashfuse [options] ARCHIVE MOUNTPOINT (null) options: -o offset=N offset N bytes into ARCHIVE to mount -o subdir=PATH mount subdirectory PATH of ARCHIVE -o notify_pipe=PATH named pipe that will receive 's' (success) or 'f' (failure) when the mountpoint is ready -o timeout=N idle N seconds for automatic unmount -o uid=N set file owner to uid N -o gid=N set file group to gid N FUSE options: -h --help print help -V --version print version -d -o debug enable debug output (implies -f) -f foreground operation -s disable multi-threaded operation -o clone_fd use separate fuse device fd for each thread (may improve performance) -o max_idle_threads the maximum number of idle worker threads allowed (default: -1) -o max_threads the maximum number of worker threads allowed (default: 10) Can't open squashfs image: Bad address 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 execv error: No such file or directory
Hi, Tyson! Could you check if you have AppImageLauncher installed? This link says it could cause an issue like that: https://forum.cursor.com/t/0-47-9-failed-to-launch-fuse-memory-allocation-failed/68394/17
Yes, I'm using AppimageLauncher on Manjaro. So it seems to be a unrelated issue to Krita? Weird that the old appimage still works though.
Hi, Tyson! Could you please tell what version of AppImageLauncher you use? And could you try to update to the latest available Alpha version of AppImageLauncher? PS: We have updated Krita to the new version of AppImage runtime, that is the reason why older versions work fine. Though I believe that we should resolve this problem before doing the release.
I'm using a customized version of appimagelauncher from AUR: http://aur.archlinux.org/packages/appimagelauncher The version number is 2.2.0-9, the codebase was from 2020. Years ago I sent an updated Chinese translation to the project, and attempt to discuss how they might have handled locale incorrectly, never saw a reply. I think the project is probably dead.
Hi, Tyson! > I think the project is probably dead As far as I can tell, the project in not dead, it is just the author is not careful enough with versioning of the package. Here is his note: https://github.com/AppImage/type2-runtime/issues/121#issuecomment-2864143920 Could you help me with one question? Do you have any workaround running the new AppImage package on your system? E.g. by clicking on it directly, bypassing the launcher?
Yes, I can just run the AppImage directly, if I uninstalled AppImageLauncher. I decided to stop using the launcher due to its added complexity. I can't build the newer version because I can't direct access to Github from China, and I don't want to figure out how to make curl use a proxy during an AUR package build.
Well, given that AppImage developers have no will to fix this issue, I guess we can call it unsupported and declare that the user should update AppImageLauncher instead :(