I have the same issues when enabling the RT3 client on Arch Linux

[2026-06-05 12:35:51] CheckSteamRTRequirements: '/home/alex/.local/share/Steam/steamrt64/pv-runtime/steam-runtime-steamrt/pressure-vessel/bin/steam-runtime-check-requirements' failed with exit code: 127

This is not the cause, it was happening even in working installations for a while (and should be fixed in more recent betas, anyway).

[2026-06-05 12:35:51] ReexecToLauncher: don't have a valid steamrt64/steam executable
[2026-06-05 12:35:51] ReexecToLauncher: proceeding in current environment

This happens even on working installations, so, not this either.

/usr/bin/lsof: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory

This is strange and unexpected. If it's running lsof inside the Steam Client's steamrt3c container, then it should have libselinux.so.1 available (it's part of the container), and should work. Or, if it's running lsof on your "real" system (outside the container), that shouldn't need libselinux.so.1.

Please try running this diagnostic tool:

~/.steam/root/steamrt64/pv-runtime/steam-runtime-steamrt/run -- steam-runtime-system-info > steamrt3c-srsi.log

and attach steamrt3c-srsi.log.

Also worth trying:

~/.steam/root/steamrt64/pv-runtime/steam-runtime-steamrt/pressure-vessel/bin/pv-verify

@niltonperimneto:

I have the same issues when enabling the RT3 client on Arch Linux

With the same symptoms, including the key error messages mentioning lsof and libselinux.so.1? The steamrt3c client works well for me on Arch, and I think a lot of Valve developers are using Arch, so there must be something specific about your system that triggers this.

Please try the same diagnostic commands I mentioned above, maybe one of those will provide some clues.

@smcv Thank you for the answer and help. Here are the outputs of the mentioned commands

pv-verify completes successfully:

~/.steam/root/steamrt64/pv-runtime/steam-runtime-steamrt/run -- steam-runtime-system-info > steamrt3c-srsi.log
steamrt3c-srsi.log

BTW: I noticed that disabling AppArmor using sudo aa-teardown, fixes it too. Apparently, the profile lsof is relevant here, so using sudo aa-disable --profile lsof seems to be enough.

everything exactly the same. It only goes away is if I use the flatpak version.

My first suspicion was my AppArmor configuration, however even after changing the profile or removing it for Steam I still encountered the same error. So it was a dead end for me.

Since it was apparently something about not finding libselinux I distrohopped to Fedora, so I'm currently unable to diagnose it further for now.

BTW: I noticed that disabling AppArmor using sudo aa-teardown, fixes it too. Apparently, the profile lsof is relevant here, so using sudo aa-disable --profile lsof seems to be enough.

Hmm, please attach lsof's profile?

It might be that openSUSE (and maybe Arch too?) installs an AppArmor profile that assumes lsof is the one from the host system, but because of how AppArmor profiles "attach" to filenames of executables, maybe the lsof inside Steam's container gets put under that same AppArmor profile too - and because the container is Debian-based rather than openSUSE-based, the paths to various things are different, which could easily trip up AppArmor's path-based assumptions about what should/shouldn't be allowed.

My first suspicion was my AppArmor configuration

If you were using AppArmor on Arch, then that's an unusual configuration (if I understand correctly, AppArmor is used by default on Debian, Ubuntu and openSUSE, but not Arch) which would explain why you saw this but other Arch users didn't.

@smcv The lsof profile is identical to upstream

Running apparmor in complain mode, reported the following paths:

1. /run/host/usr/lib64/gconv/gconv-modules.cache
2. /run/host/usr/lib/locale/*/LC_CTYPE
3. /run/host/usr/lib64/libpthread.so.0
4. /run/host/usr/lib64/libdl.so.2
5. /run/host/usr/lib64/libc.so.6
6. /var/pressure-vessel/ldso/ld.so.cache

I created a PR/MR in the AppArmor repository to include those paths or do you know a better solution?

The lsof profile is identical to upstream

Interestingly, that profile seems to have been written by Canonical staff, but it isn't enabled by default in Ubuntu. In Ubuntu, it's in the apparmor-profiles package (not installed by default), in the /usr/share/apparmor/extra-profiles/ directory, which has a README that says "The profiles in this directory are not turned on by default because they are not as mature as the profiles in /etc/apparmor.d/."

Perhaps openSUSE and Arch should be following Ubuntu's example, and not enabling this profile by default?

I think part of the problem here is that the profile has the attach_disconnected flag, which means that when AppArmor sees a binary in a container's namespace and its path is of the form …/usr/bin/lsof, it will detect that as "this might be lsof" and try to attach the profile to it, even though it's the container's lsof and not the OS's lsof so it can legitimately have different requirements. This is relatively unusual and can have unexpected results, as it did here.

I created a PR/MR in the AppArmor repository to include those paths or do you know a better solution?

I'm not sure how appropriate it is for a profile that was intended to apply to the OS's lsof to include details of a container's lsof. I think ideally, everything run by Steam would run in the same security context as Steam (no extra privileges, no extra restrictions either): if Steam has a profile and runs lsof, then lsof should inherit Steam's profile, and if Steam is unconfined and runs lsof, then lsof should also be unconfined.

You said that disabling the profile results in Steam working correctly. I think the result of disabling the profile is that whenever a program (Steam, or anything else) runs lsof, no profile transition will take place, and lsof will run with the same security context as the parent program (Steam or whatever).

If it isn't possible to arrange for Steam's lsof child to run in the same security context as Steam itself, then the next best thing would be to widen the paths in your proposed profile changes so that they include fewer implementation details - for example it's better to avoid hard-coding lib64 specifically, and instead allow for openSUSE lib64, Arch lib, Debian lib/[any architecture name here] and so on.

I've left some comments on your MR which hopefully provide some useful context for AppArmor upstream, let's see what they say about it.

The temporary workaround that I would suggest in the short term is disabling the lsof profile.

We might also be able to work around this by changing how lsof is packaged in the container; that'll need some experiments.

So that we can triage this: in openSUSE, is the lsof profile installed and enabled by default?

a broken upstream AppArmor profile

I'm not so sure that I'd categorize it as broken at this stage. Unintended consequences, definitely; broken? harder to say.

@smcv

So that we can triage this: in openSUSE, is the lsof profile installed and enabled by default?

If AppArmor is selected, the package apparmor-profiles ("Base profiles") is automatically installed and enabled. It contains the lsof and steam profile. However, since Leap 16 (Oct 2025), SELinux replaces AppArmor as the new default system for new installations, but existing setups are not migrated.

EDITED to include lsof note

Installing Leap 16 and enabling AppArmor as per https://en.opensuse.org/SDB:AppArmor does install apparmor-profiles, but doesn't seem to pull in a lsof profile. Perhaps the lsof profile is new in AppArmor 5?

@smcv I'm sorry. Yes, you are correct. It is only present in AppArmor 5, that is included in the rolling release variant openSUSE Tumbleweed.

EDIT: btw ArchLinux still runs AppArmor 4, but it appears AppArmor 5 is in testing.
EDIT2: Ubuntu only has it disabled to fix a kernel panic that occurred in the past.

I can reproduce the problem after upgrading to Tumbleweed.

We might also be able to work around this by changing how lsof is packaged in the container; that'll need some experiments.

I've found a workaround, but it's fairly horrible, so I'd like to hear from the AppArmor maintainers before applying anything.