steam-runtime
steam-runtime copied to clipboard
ValveSoftware
Failed to Initialize Vulkan on Clear Linux
Your system information
- System information from steam (
Steam->Help->System Information) in a gist:
- Have you checked for system updates?: [Yes]
- Are you using the latest stable video driver available for your system? [Yes]
- Have you verified the game files?: [Yes]
Please describe your issue in as much detail as possible:
Describe what you expected should happen and what did happen. Please link any large pastes as a Github Gist. Expected should happen: Launch and play Dota 2
What happened:
I obtained steam from Steam under Linux and ran sudo make install. Client runs perfectly fine however Dota 2 brings up the error Unable to start game: Failed to initialize Vulkan (terminal log attached)
i@clr~ $ lspci -k | grep -iEA3 "VGA"
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] (rev c8)
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Radeon R9 FURY X / NANO
Kernel driver in use: amdgpu
Kernel modules: amdgpu
I am able to run games (StarCraft 2) on Lutris, however I am unable to run games on steam. attached output from vulkaninfo
Related finds https://github.com/ValveSoftware/steam-runtime/issues/345 However, I am unsure of how I am to implement this fix as soldier has now moved to sniper
Steps for reproducing this issue:
- Open Steam
- Press Play on Dota 2
- Fail to run
Hello @K1ngfish3r, Dota 2 is run inside the Steam Linux Runtime 3.0 (Sniper) container environment. Looking at your runtime diagnostics, the Vulkan render paths are generally healthy on the system (https://gist.github.com/K1ngfish3r/62ea913932bf0501bf3fe8efc331a57b#file-steamruntimediagnostics-txt-L2458-L2471), but once you get inside the container environment, Vulkan is broken for some reason (https://gist.github.com/K1ngfish3r/62ea913932bf0501bf3fe8efc331a57b#file-steamruntimediagnostics-txt-L5087-L5100).
We'll need to ponder why that container/driver issue is happening before evaluating any additional issue with Dota 2, so I've transferred this issue report to the steam-runtime issue tracker for a runtime maintainer to ponder.
Please give https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information a read and share the requested information.
As Requested
Logs of Steam Linux Runtime using STEAM_LINUX_RUNTIME_LOG=1 steam
gist
I have managed to enable this, however I am unsure of what else I'm supposed to do here.
UPDATE: slr-latest.log this log was obtained using STEAM_LINUX_RUNTIME_VERBOSE=1 STEAM_LINUX_RUNTIME_LOG=1 steam
23:49:20.868828: pressure-vessel-wrap[30995]: W: Using libGLX_mesa.so.0 from provider system for some but not all architectures! Will take /usr/share/drirc.d from provider.
Not necessarily related to the problem with Vulkan you are reporting, but you should install both 32- and 64-bit versions of Mesa on the host system.
I don't know how you would achieve that on Clear Linux: the steps to do so would be distro-specific. In Debian/Ubuntu, you would install both libglx-mesa0:amd64 and libglx-mesa0:i386, or in Arch, you would install various lib32- packages.
This looks like the problem:
"vkCreateInstance (&inst_info, NULL, vk_instance) failed: ERROR_INCOMPATIBLE_DRIVER (-9)"
Possibly related, possibly not:
"/usr/libexec/steam-runtime-tools-0/x86_64-linux-gnu-check-vdpau: symbol lookup error: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libvdpau.so.1: undefined symbol: XMissingExtension"
"/usr/libexec/steam-runtime-tools-0/x86_64-linux-gnu-check-va-api: symbol lookup error: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libva-x11.so.2: undefined symbol: xcb_dri3_id"
Something is going wrong with the process of finding your graphics drivers' library dependencies. The messages I quoted indicate that this is affecting VA-API and VDPAU. I can't tell whether it's also affecting OpenGL and Vulkan, but it's very likely that the answer is yes.
Please send the output of
/sbin/ldconfig -XNv
and
/sbin/ldconfig -p
as Gists or attachments, so we can see which libraries we ought to have been finding, and get an idea of why we couldn't.
Also, it would be useful to know more about how Clear Linux is structured. We have had trouble in the past with Clear Linux doing unusual things. #345 was fixed about 3 years ago, so that particular issue shouldn't be the problem, but it's an example of needing to know specifics of how Clear Linux works.
I see that your library search path is something like this:
/usr/lib
/usr/local/lib
/usr/lib64
/usr/lib
/usr/lib64
/usr/lib64/glibc-hwcaps/x86-64-v3
/usr/lib64/glibc-hwcaps/x86-64-v4
/usr/lib32
Are any of those directories actually symbolic links? If yes, where do they point to?
Replying to https://github.com/ValveSoftware/steam-runtime/issues/642#issuecomment-1892323580
Clear Linux is trying to cut down on the 32 bit libs they provide https://github.com/clearlinux/distribution/issues/2925#issuecomment-1645683344 and I am unable to obtain the 32 bit version of libGLX_mesa.so.0.
i@clr~ $ sudo swupd search-file libGLX_mesa.so.0
Downloading all Clear Linux manifests
[100%]
Searching for 'libGLX_mesa.so.0'
Bundle lib-opengl [installed] (2717 MB on system)
/usr/lib64/libGLX_mesa.so.0.0.0
/usr/lib64/libGLX_mesa.so.0
Replying to https://github.com/ValveSoftware/steam-runtime/issues/642#issuecomment-1892346649
Replying to https://github.com/ValveSoftware/steam-runtime/issues/642#issuecomment-1892352726
None of them are symbolic links, however, /usr/local/lib doesnt exist.
i@clr~ $ ls -lah /usr/
total 492K
drwxr-xr-x 14 root root 4.0K Jan 12 17:39 .
drwxr-xr-x 19 root root 4.0K Jan 12 15:50 ..
drwxr-xr-x 2 root root 120K Jan 15 23:00 bin
drwxr-xr-x 324 root root 36K Jan 12 17:39 include
drwxr-xr-x 54 root root 4.0K Jan 12 19:42 lib
drwxr-xr-x 23 root root 24K Jan 12 19:47 lib32
drwxr-xr-x 162 root root 236K Jan 15 23:00 lib64
drwxr-xr-x 47 root root 20K Jan 12 17:39 libexec
drwxr-xr-x 3 root root 4.0K Jan 12 15:45 local
drwxr-xr-x 6 root root 4.0K Jan 12 17:39 man
drwxr-xr-x 4 root root 4.0K Jan 12 17:39 mingw
lrwxrwxrwx 1 root root 3 Feb 2 2019 sbin -> bin
drwxr-xr-x 293 root root 12K Jan 12 19:47 share
drwxr-xr-x 3 root root 4.0K Jan 12 15:45 src
drwxr-xr-x 3 root root 4.0K Jan 12 15:45 usr
i@clr~ $ ls -lah /usr/lib64/ | grep glibc-hwcaps
drwxr-xr-x 4 root root 4.0K Jan 12 15:45 glibc-hwcaps
i@clr~ $ ls -lah /usr/lib64/glibc-hwcaps/
total 252K
drwxr-xr-x 4 root root 4.0K Jan 12 15:45 .
drwxr-xr-x 162 root root 236K Jan 15 23:00 ..
drwxr-xr-x 2 root root 4.0K Jan 12 17:39 x86-64-v3
drwxr-xr-x 2 root root 4.0K Jan 12 17:39 x86-64-v4
Clear Linux is trying to cut down on the 32 bit libs they provide clearlinux/distribution#2925 (comment) and I am unable to obtain the 32 bit version of
libGLX_mesa.so.0.
Sorry, I think that is likely to make Clear Linux incompatible with Steam, either now or in the future. https://github.com/ValveSoftware/steam-for-linux/ documents it as requiring: "64-bit (x86-64, AMD64) and 32-bit (i386, IA32) graphics drivers and glibc", and Mesa is part of the 32-bit graphics driver stack.
/usr/libexec/steam-runtime-tools-0/x86_64-linux-gnu-check-vdpau: symbol lookup error: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libvdpau.so.1: undefined symbol: XMissingExtension
This seems strange to me. XMissingExtension should be in libXext.so.6, and according to Debian's records, has been present there for at least 14 years. I would expect the same to be true in all distributions.
Is your libvdpau.so.1 perhaps missing a dependency on libXext.so.6? You could find out with:
readelf -d /usr/lib64/libvdpau.so.1 | grep NEEDED
or
objdump -T -x /usr/lib64/libvdpau.so.1 | grep NEEDED
This is not directly related to your problem with Vulkan, but it might give us useful clues.
/usr/libexec/steam-runtime-tools-0/x86_64-linux-gnu-check-va-api: symbol lookup error: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libva-x11.so.2: undefined symbol: xcb_dri3_id
Similarly, this should have been available in libxcb-dri3.so.0 for at least 10 years. Does your libva-x11.so.2 have a correct dependency on that library? You could find out with:
readelf -d /usr/lib64/libva-x11.so.2 | grep NEEDED
(or objdump -T -x)
"libcrypt.so.1" : {
"soname" : null,
"path" : "/usr/lib64/libcrypt.so.1",
"issues" : [
"missing-symbols",
"misversioned-symbols",
"missing-versions"
],
"missing-symbols" : [
"crypt_checksalt@XCRYPT_4.3",
"crypt_gensalt@XCRYPT_2.0",
"crypt_gensalt_r@XCRYPT_2.0",
"crypt_gensalt_ra@XCRYPT_2.0",
"crypt_gensalt_rn@XCRYPT_2.0",
"crypt_preferred_method@XCRYPT_4.4",
"crypt_ra@XCRYPT_2.0",
"crypt_rn@XCRYPT_2.0",
"xcrypt@XCRYPT_2.0",
"xcrypt_gensalt@XCRYPT_2.0",
"xcrypt_gensalt_r@XCRYPT_2.0",
"xcrypt_r@XCRYPT_2.0"
],
"misversioned-symbols" : [
"crypt@XCRYPT_2.0",
"crypt_r@XCRYPT_2.0"
]
},
I don't know whether this is relevant to the issue report or not, but this indicates that Clear Linux is providing a version of libxcrypt that claims to be backward-compatible with the version historically provided by glibc, but actually is not.
If Clear Linux wants to provide a legacy-free libxcrypt, then it should build it as libcrypt.so.2, like libcrypt2 in Debian and libxcrypt in Arch.
Or if Clear Linux wants to provide a backward-compatible libxcrypt, then it should build it as libcrypt.so.1 with --enable-obsolete-api=glibc, like libcrypt1 in Debian and libxcrypt-compat in Arch.
The version provided here is not binary-compatible with either of those.
setlocale "en_US.UTF-8": No such file or directory
pressure-vessel-locale-gen: Missing locale en_US.UTF-8 (found in $LANG)
pressure-vessel-locale-gen: Generating locale en_US.UTF-8...
pressure-vessel-locale-gen: Generated locale en_US.UTF-8 successfully
pressure-vessel-adverb[16982]: W: Container startup will be faster if missing locales are created at OS level
Not relevant to the Vulkan initialization failure, but please consider generating an en_US.UTF-8 or en_US.utf8 locale system-wide. Some games require this, so pressure-vessel generates one for you if it isn't present, but that's a surprisingly slow thing to do - if you do this in advance, each attempt to launch a pressure-vessel game will be quicker.
Replying to https://github.com/ValveSoftware/steam-runtime/issues/642#issuecomment-1893587974
I have contacted the clear linux devs and they have told me they are not sure why 32 bit mesa isnt generating the 32 bit version of libGLX_mesa.so.0 since they do ask the build system to make it. They will be looking into it.
Replying to https://github.com/ValveSoftware/steam-runtime/issues/642#issuecomment-1893723654 and https://github.com/ValveSoftware/steam-runtime/issues/642#issuecomment-1893727534
Replying to https://github.com/ValveSoftware/steam-runtime/issues/642#issuecomment-1893752283
I have forwarded this message to the devs, will update with their response
Replying to https://github.com/ValveSoftware/steam-runtime/issues/642#issuecomment-1893760092
it had to be set manually, it is set now
I don't know whether this is relevant to the issue report or not, but this indicates that Clear Linux is providing a version of
libxcryptthat claims to be backward-compatible with the version historically provided by glibc, but actually is not.
our libcrypt.so.1 actually comes from glibc (glibc 2.38 still provides libcrypt if you ask it nicely) but I will investigate if there's options we need to pass
our libcrypt.so.1 actually comes from glibc (glibc 2.38 still provides libcrypt if you ask it nicely) but I will investigate if there's options we need to pass
Hmm, I might have been misreading the diagnostic output: it might be saying that it expected to find libxcrypt, but didn't.
The older LD_LIBRARY_PATH-based Steam Runtime (which is the first section of JSON in https://gist.github.com/K1ngfish3r/62ea913932bf0501bf3fe8efc331a57b, starting with "LD_* scout runtime" information:) contains a copy of libxcrypt, and tries to set up the LD_LIBRARY_PATH so that libraries from the host system will be used in preference to the ones bundled with the runtime, unless the library bundled with the runtime is strictly newer/"better" (wider ABI coverage), in which case it will use that.
If your libcrypt.so.1 is from glibc, then the runtime ought to be detecting that and using the bundled libxcrypt instead, because libxcrypt is "better" (has a larger ABI, such that programs linked against glibc's libcrypt will still work with libxcrypt, but programs linked against libxcrypt will not necessarily work with glibc's libcrypt).
But perhaps the fact that Clear Linux is using such a new version of glibc, but has not switched to libxcrypt, is confusing our detection of which one is newer? Most other distributions switched to libxcrypt before they updated to recent glibc versions.
/usr/libexec/steam-runtime-tools-0/x86_64-linux-gnu-check-vdpau: symbol lookup error: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libvdpau.so.1: undefined symbol: XMissingExtensionThis seems strange to me.
XMissingExtensionshould be inlibXext.so.6, and according to Debian's records, has been present there for at least 14 years. I would expect the same to be true in all distributions.
From the follow-up:
i@clr~ $ objdump -T -x /usr/lib64/libvdpau.so.1 | grep NEEDED
NEEDED libX11.so.6
NEEDED libc.so.6
it seems that libvdpau.so.1 is missing its dependency on libXext.so.6.
I don't use Clear Linux myself, but I would have expected that its libvdpau.so.1 has an undefined reference to XMissingExtension. If I look at the output of objdump -T -x /usr/lib/x86_64-linux-gnu/libvdpau.so.1 on Debian, I see, among other symbol references:
0000000000000000 DF *UND* 0000000000000000 Base XMissingExtension
This means libvdpau.so.1 cannot be loaded successfully unless you have a library providing that symbol; but I also have
Dynamic Section:
NEEDED libX11.so.6
NEEDED libXext.so.6
NEEDED libc.so.6
which means that when a program loads libvdpau.so.1, it will make sure to load the dependency libXext.so.6 first, which defines XMissingExtension, and so everything works.
The pressure-vessel (Steam Linux Runtime) container runtime framework relies on being able to traverse these dependency chains and find all the dependencies of a library, so that it can bring them into the container. It seems that isn't happening.
Is Clear Linux doing something odd with ELF dependency handling (some sort of optimization perhaps?), that would result in libXext.so.6 somehow being loaded by libvdpau.so.1, even though there is no DT_NEEDED header pointing to it?
Similarly, the list of dependencies of libva-x11.so.2:
NEEDED libva.so.2
NEEDED libdrm.so.2
NEEDED libX11.so.6
NEEDED libc.so.6
is much shorter than I would have expected - I would have expected it to look more like this, which is what I get on Debian:
NEEDED libva.so.2
NEEDED libdrm.so.2
NEEDED libX11.so.6
NEEDED libXext.so.6
NEEDED libXfixes.so.3
NEEDED libX11-xcb.so.1
NEEDED libxcb.so.1
NEEDED libxcb-dri3.so.0
NEEDED libc.so.6
It's harder to tell what is going on with Vulkan drivers, because Vulkan-Loader doesn't helpfully show us the dlopen error message - but if there is something similar going on there, with required dependencies not being listed as ELF DT_NEEDED headers (but somehow getting loaded anyway on the host system), then that would be consistent with the behaviour reported here.
uhm, i've managed to launch and play the game
i swapped out the libX11.so.6.4.0 inside both
/home/i/.steam/steam/steamapps/common/SteamLinuxRuntime_sniper/sniper_platform_0.20231211.70175/files/lib/i386-linux-gnu and
/home/i/.steam/steam/steamapps/common/SteamLinuxRuntime_sniper/sniper_platform_0.20231211.70175/files/lib/x86_64-linux-gnu
with the libX11.so.6.3.0 provided by clear linux and I haven't received a single error? it just worked and i managed to play a game of dota.
i feel like this is a very hacky solution though, no other fixes nor special options were used
Yes, that's a hack: editing the contents of SteamLinuxRuntime_sniper is unsupportable.
That probably does narrow down where the problem must be, though...
Anything which I can provide to help? This hack is most certainly going to break in the next update.
Is Clear Linux's libX11 the one that has packaging here? https://github.com/clearlinux-pkgs/libX11/blob/main/libX11.spec
It looks as though that library is not actually libX11: instead, it's an amalgamation of libX11 and a lot of related libraries, all stuck together into one big library. This would explain my confusion regarding libXext.so.6 and libxcb-dri3.so.0, because Clear Linux's libX11 contains all of the functionality of libXext and libxcb-dri3 (and many more besides).
Unfortunately, the packaging makes it claim to be an outdated version:
gcc $CFLAGS $LDFLAGS -m64 -o 64/libX11.so.6.3.0 ...
The version of libX11 in SteamLinuxRuntime_sniper is libX11.so.6.4.0, so system tools like ldconfig will think sniper's libX11 is strictly newer than Clear Linux's, and so will the pressure-vessel machinery that sets up this container. We must use whichever library is newer or "better" (more ABI), which we think is sniper's, but actually sniper's library is older and smaller than Clear Linux's, leading to failure.
I think it might also be possible for this to lead to ABI conflicts inside the container environment: when a library inside the container (for example SDL) loads our version of one of the libraries that are amalgamated into Clear Linux's libX11.so.6 (for example libXext.so.6), it's undefined whether symbols will resolve to the implementation from Clear Linux's libX11.so.6 or the implementation from sniper's libXext.so.6. Even if we had the ability to choose, we can't tell which of those implementations is newer/"better": Clear Linux happens to be a rolling release, so it's extremely likely that it's newer than sniper, but if a long-term-stable distribution tried to do the same trick, we would have a problem.
I think Clear Linux should not have done this. I understand that bundling together multiple tiny libraries into one large library can improve runtime linking performance, but changes to the ABI of a widespread library should happen upstream or not at all, so the place to do this would have been in the Xorg community. But it has happened, so the damage has been done: Clear Linux can no longer undo this without breaking backwards-compatibility.
I'll have to think more about whether pressure-vessel can work around this without making matters worse. Making it compare libX11 versions by their list of public symbols rather than by their filename might help - but the reason we haven't done that in the past is that for historical reasons, it's very unclear which of the symbols exported by libX11 are public, and which are private symbols that must be ignored for comparison purposes.
On the Clear Linux side, the first thing to do would be to make sure that the version number in the filename libX11.so.6.* matches the version number that would have been produced by libX11's upstream build system, preferably with some automation to make sure the build fails if this ceases to be true. @fenrus75, would you be able to arrange that?
n the Clear Linux side, the first thing to do would be to make sure that the version number in the filename
libX11.so.6.*matches the version number that would have been produced by libX11's upstream build system, preferably with some automation to make sure the build fails if this ceases to be true. @fenrus75, would you be able to arrange that?
was just fixing that -- so yes we will do this -- the update should be out in a day or two with this in it
perhaps the fact that Clear Linux is using such a new version of glibc, but has not switched to libxcrypt, is confusing our detection of which one is newer? Most other distributions switched to libxcrypt before they updated to recent glibc versions.
I think perhaps the problem we're having with libcrypt (which is very much secondary here, the libX11 issue is the important one!) is that your glibc is new enough to have this change, and you're using glibc's libcrypt.
With older glibc, we would recognise libcrypt-2.31.so (or whatever) as being sufficiently old that we can override it with libxcrypt.
With libxcrypt on the host system, we can directly compare our libcrypt.so.1.1.0 with the host system's libcrypt.so.1.x.y, and pick whichever one is newer.
But with new glibc providing a regular file libcrypt.so.1 that is not a symlink to anything, there's no easy way for the LD_LIBRARY_PATH runtime to tell whether that's very "old" (where the version provided by glibc counts as "old" since it hasn't added new ABI for many years), or very new, or somewhere in between.
The good news is that this only affects a relatively small number of games, and for those games, forcing use of the "Steam Linux Runtime 1.0 (scout)" compatibility tool should bypass the problem.
libX11 has been updated and I can confirm that it is working properly after removing the modified files from the SLR
Please could you get new Help -> Steam Runtime Diagnostics with an unmodified SLR 3.0 - sniper, to confirm that the underlying problems are fixed?
You can verify integrity (but on the SLR 3.0 - sniper tool, rather than a game) to force Steam to re-download anything that has been modified.
Please could you get new Help -> Steam Runtime Diagnostics with an unmodified SLR 3.0 - sniper, to confirm that the underlying problems are fixed?
You can verify integrity (but on the SLR 3.0 - sniper tool, rather than a game) to force Steam to re-download anything that has been modified.
As requested find attached gist
On the Clear Linux side, the first thing to do would be to make sure that the version number in the filename
libX11.so.6.*matches the version number that would have been produced by libX11's upstream build system, preferably with some automation to make sure the build fails if this ceases to be true.
This seems to have been successful, and that's the most serious problem here (in particular it's what was breaking Vulkan), so I think this issue can be closed.
with new glibc providing a regular file
libcrypt.so.1that is not a symlink to anything, there's no easy way for theLD_LIBRARY_PATHruntime to tell whether that's very "old" (where the version provided by glibc counts as "old" since it hasn't added new ABI for many years), or very new, or somewhere in between.The good news is that this only affects a relatively small number of games, and for those games, forcing use of the "Steam Linux Runtime 1.0 (scout)" compatibility tool should bypass the problem.
This part was still a problem as of 2024-01-19.
One mitigation is that as I said, forcing use of the "Steam Linux Runtime 1.0 (scout)" compatibility tool should bypass the problem.
Another mitigation is that this situation will only last until Clear Linux upgrades to glibc 2.39, which no longer ships a libcrypt implementation, meaning that the only reasonable implementation of libcrypt.so.1 will be libxcrypt compiled with --enable-obsolete-api=glibc, meaning that it will either a drop-in replacement for the one in scout (fine) or completely missing (should also be fine).
with new glibc providing a regular file libcrypt.so.1 that is not a symlink to anything, there's no easy way for the LD_LIBRARY_PATH runtime to tell whether that's very "old" (where the version provided by glibc counts as "old" since it hasn't added new ABI for many years), or very new, or somewhere in between.
The good news is that this only affects a relatively small number of games, and for those games, forcing use of the "Steam Linux Runtime 1.0 (scout)" compatibility tool should bypass the problem.
I tried testing the following games
- DIRT Rally
- Tomb Raider
Both games failed to work with SLR 3.0 or SLR 1.0 Should I close this issue and make a new one or should I add the results here?
Both Dirt Rally and Tomb Raider are known to be affected by #613, which is a game bug rather than an SLR bug. Unfortunately, these older games are no longer being updated by their developer or publisher. (I regularly use Tomb Raider as a test title while developing the runtime, so I contacted Crystal Dynamics regarding it; I got an automated response, but I have not heard anything since.)
If combining SLR 1.0 with the workaround at the top of https://github.com/ValveSoftware/steam-runtime/issues/613#issuecomment-1686721802 is successful, then that's the best we can expect from these particular games. If that workaround is not successful, then please open a separate issue.
Closing as fixed per https://github.com/ValveSoftware/steam-runtime/issues/642#issuecomment-1965204729.