[SOLVED] Unable to Launch AppImages on Fedora 35

plutopear · 12-08-2021, 07:39 PM

This issue happens on every AppImage I have on my system. I do not have any handlers (AppImageLauncher, etc) installed, although I used to (I uninstalled AppImageLauncher while troubleshooting this issue).

When launching from Nautilus, nothing at all happens. However, when I launch from a terminal, I get this message:

Code:

libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[36406:1208/193424.879531:FATAL:gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.
Trace/breakpoint trap (core dumped)

System Info: (please let me know if you need something more)
OS: Fedora 35
Kernel: 5.15
Display Server: X and Wayland (issue happens on both)
GPU: Nvidia Geforce 1060
Nvidia Driver: 495.44

business_kid · 12-11-2021, 01:13 PM

Try

Code:

ldd /path/to/Some_Appimage |grep libva

and

Code:

ldd /path/to/Some_Appimage |grep found

Post any output. The correct output from the second one is NO output.

plutopear · 12-20-2021, 02:35 PM

Sorry for the late response, I tried this for 3 different AppImages, all are returning the same message:

Code:

$ ldd ~/AppImages/Obsidian-0.12.19.AppImage | grep libva
	not a dynamic executable
$ ldd ~/AppImages/Obsidian-0.12.19.AppImage | grep found
	not a dynamic executable
$ ldd ~/AppImages/deemix-gui.AppImage | grep libva
	not a dynamic executable
$ ldd ~/AppImages/deemix-gui.AppImage | grep found
	not a dynamic executable
$ ldd ~/AppImages/balenaEtcher-1.7.0-x64_1e3bcbc6fc572b5d84f0472335c2f1da.AppImage | grep libva
	not a dynamic executable
$ ldd ~/AppImages/balenaEtcher-1.7.0-x64_1e3bcbc6fc572b5d84f0472335c2f1da.AppImage | grep found
	not a dynamic executable

Sudoing returns the same message. Any ideas?

shruggy · 12-21-2021, 02:53 AM

To look inside AppImages, you have to mount them first. Although I doubt this would help.

Code:

$ echo $TMPDIR
/dev/shm
$ ./balenaEtcher-1.7.1-x64.AppImage --appimage-mount
/dev/shm/.mount_balena9nzshU

Then in another terminal window

Code:

$ cd /dev/shm/.mount_balena9nzshU
$ find -executable -type f -exec ldd {} +|grep libva
$ find -executable -type f -exec ldd {} +|grep found
	libindicator.so.7 => not found
	libdbusmenu-gtk.so.4 => not found

On a CentOS 8 system, I get the same error message, but the AppImage above works.

Code:

$ ./balenaEtcher-1.7.1-x64.AppImage
[Axios v1.7.1] Transitional option 'clarifyTimeoutError' has been deprecated since v1.0.0 and will be removed in the near future
[Axios v1.7.1] Transitional option 'forcedJSONParsing' has been deprecated since v1.0.0 and will be removed in the near future
[Axios v1.7.1] Transitional option 'silentJSONParsing' has been deprecated since v1.0.0 and will be removed in the near future
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
ready-to-show: 1.243s
Checking for update
Update for version 1.7.1 is not available (latest version: 1.7.1, downgrade is disallowed).

Code:

$ rpm -q --provides libva
libva = 1:2.9.1-1.el8
libva(x86-64) = 1:2.9.1-1.el8
libva-drm.so.2()(64bit)
libva-glx.so.2()(64bit)
libva-wayland.so.2()(64bit)
libva-x11.so.2()(64bit)
libva.so.2()(64bit)
libva.so.2(VA_API_0.32.0)(64bit)
libva.so.2(VA_API_0.33.0)(64bit)

So, the libva error messages seem to be harmless. The actual culprit is this

Quote:

Originally Posted by plutopear

Code:

[36406:1208/193424.879531:FATAL:gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.
Trace/breakpoint trap (core dumped)

balenaEtcher is an Electron-based AppImage. This is a known bug fixed in Electron 13.5. Try balenaEtcher 1.7.1. Perhaps, it's already fixed there.

If not, you may try to run it with --no-sandbox

Code:

./balenaEtcher-1.7.1-x64.AppImage --no-sandbox

plutopear · 12-27-2021, 12:36 PM

--no-sandbox did it. I'm able to launch all my AppImages using this, so kudos to you!
What does this actually do? What is this "sandbox" that prevents all these apps from running?

Would there be any way to launch these from my file manager with that flag instead of running from the terminal every time?

P.S. When I run those find commands, I just get a screen full of

Code:

	not a dynamic executable
	not a dynamic executable
	not a dynamic executable
	not a dynamic executable
	not a dynamic executable
	not a dynamic executable
	not a dynamic executable
	not a dynamic executable

So that isn't too helpful

shruggy · 12-27-2021, 02:49 PM

Quote:

Originally Posted by plutopear

What is this "sandbox" that prevents all these apps from running?

It's a security feature. --no-sandbox isn't meant to be a permanent solution: it's just a hack to get around a bug in Electron linked to above. When Electron-based AppImages catch up and publish versions based on Electron >=13.5, you'd better run them sandboxed as they were intended to be run.

Quote:

Originally Posted by plutopear

Would there be any way to launch these from my file manager with that flag instead of running from the terminal every time?

Well, you can write .desktop files for them that would start them with any options you like. Or wrapper shell scripts. Besides, there are appimaged daemon and AppImageLauncher. I believe neither is packaged for Fedora, but you can build them yourself or download binaries for the latter.

rclark · 12-28-2021, 11:01 AM

I use KDE, but I run appImages from the desktop no problem (Etcher and FreeCad as examples). To create a desktop icon, I just right click on the desktop, (Create New->Link to Application), and point it the app image. I believe you should also make it executable. Ie. from the commandline: chmod +x <the app image file> . This may also also allow you to run from the file manager (not a Gnome user).