From ArchWiki

Runtime issues fixed?

From the January 19 Steam update notes:

Improved interactions between the Steam runtime and host distribution libraries, which should let Steam work out of the box with open-source graphics drivers on modern distributions. If using an older distribution or running into problems, use STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 to revert to previous behavior.

I'm curious if this means that the steam runtime workarounds are no longer necessary. Can users who previously required runtime workarounds try running Steam via /usr/lib/steam/steam to see if you no longer have issues?

Silverhammermba (talk) 05:59, 21 January 2017 (UTC)Reply[reply]

For me, games that require the native runtime (ie don't work even with the workarounds) are still the same. I don't currently have any that specifically needed the workarounds to check. Argymeg (talk) 17:37, 28 January 2017 (UTC)Reply[reply]
That's interesting. Which games require the native runtime? I think that is a separate issue though, I think the purpose of the Steam update was to make the LD_PRELOAD hack unnecessary. Silverhammermba (talk) 21:58, 28 January 2017 (UTC)Reply[reply]

"Needs to be online" error

Exact error message received:

$ ./ 
Redirecting stderr to '/home/myUserId/.steam/logs/stderr.txt'
ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".
[  0%] Checking for available update...
[----] Verifying installation...
[  0%] Downloading Update...
[  0%] Checking for available update...
[----] !!! Fatal Error: Steamcmd needs to be online to update.	 Please confirm your network connection and try again.
threadtools.cpp (3294) : Assertion Failed: Illegal termination of worker thread 'Thread(0x0x57e39320/0x0xf77cda'

If the Steam launcher refuses to start and you get an error saying: "Fatal Error: Steam needs to be online to update" while you are online, then there might be issues with name resolving.

Try to install lib32-libcurl-compat or nss-mdns or lib32-nss lib32-glu or lib32-dbus.

I installed the following items in order:

  1. lib32-libcurl-compat
  2. lib32-nss
  3. lib32-glu
  4. lib32-dbus

Installation of `lib32-dbus` has resolved the issue. I am not sure if 3 previous items has any impact.

This did the trick! Specifically, lib32-dbus.

Note: lib32-nss is a dependency of Steam. Pound Hash (talk)

Needs to be online error: Enabling nscd.service

It’s unclear why enabling nscd.service can work around this issue. I’ve tried enabling caching for each service nscd(8) supports one by one, and it is indeed the hosts service that makes Steam work again. If that’s the case, it should have worked by using systemd-resolved for resolution (which I also tried), which should have DNS caching enabled by default.

Maybe someone can find out why enabling and starting nscd.service works around this issue? There is more on User_talk:Lahwaacz#Re:_Steam_Needs_to_be_online_error on this topic. A good entry point that comes to mind is checking if resolved really *does* have DNS caching enabled by default, I just stumbled upon this bit in resolved.conf(5):

Note that caching is turned off implicitly if the configured DNS server is on a host-local IP address (such as or ::1), in order to avoid duplicate local caching.

I’m using NetworkManager and can’t really test it right now. It could also have something to do with multilib packages Steam depends on.

-- Irimi1 (talk) 19:40, 28 February 2021 (UTC)Reply[reply]

Steam needs Python 3 to function properly

If you want to run games through Proton, you need Python 3. Tonij (talk) 00:59, 21 January 2019 (UTC)Reply[reply]

Yes, see bug report: FS#61362. Lonaowna (talk) 11:51, 21 January 2019 (UTC)Reply[reply]

No Hardware decoding with intel-media-driver

Just found out that with intels media driver for newer CPUs (Broadwell+), steam does no hardware decoding for Remote Play (despite mpv working well and vainfo shows no problems). When using the older libva-intel-driver (or rather lib32-libva-intel-driver), hardware decoding works again. One can switch between the two with:

export LIBVA_DRIVER_NAME=iHD # not working
export LIBVA_DRIVER_NAME=i965 # working

Anyone knows why? (Perhaps missing 32bit for intel-media-driver?) Stebs (talk) 10:30, 24 April 2020 (UTC)Reply[reply]

XFS with Steam

There is a heading here suggesting 2k games don't work with XFS. I've verified the problem can also exist for games (Jan 2021) such as CS:GO, which fails when the partition size is larger than 2TB. I'm reading that it is associated with inode64 in the CS:GO case, but I think it is a good idea to take the 2k section and the knowledge that larger XFS partitions cause issues for other games and make it a more concrete section in Troubleshooting. Keystone (talk) 15:08, 4 February 2021 (UTC)Reply[reply]

Suggestion to include icd loader export env variable

I've never been able to get Steam to run correctly on Arch without first exporting the following to my env variables

VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/<name of x86 icd>.json:/usr/share/vulkan/icd.d/<name of x64 icd>.json

By default these files are called radeon_icd.i686.json and radeon_icd.x86_64.json however if you install the vulkan-icd-loader and lib32-vulkan-icd-loader packages (from extra and multilib) then this changes to amd_icd32.json and amd_icd64.json. Obviously this might be gpu vendor specific, I cannot say for either Intel or Nvidia GPUs.

I suggest the following addition


Games refuse to load/load to a black screen

First make sure both the vulkan-icd-loader and lib32-vulkan-icd-loader packages are installed.

Run the following ls /usr/share/vulkan/icd.d

# add the following to /etc/environment
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/<name of x86 icd>.json:/usr/share/vulkan/icd.d/<name of x64 icd>.json

Save and reload steam ++++

Since this is my first ever "edit" I thought I'd better suggest it here rather than make it live

Dungeonseeker (talk) 08:55, 29 October 2021 (UTC)Reply[reply]

The x86 icd doesn't seem to exist for Nvidia? It only appears as nvidia_icd.json, so I'm not sure if that can be safely ignored? :/
Neko-san (talk) 17:32, 27 April 2022 (UTC)Reply[reply]