Running Steam on PREEMPT_RT (Realtime) Kernels for VR/Robotics

[berkecyln]

Hello,

I'm hitting a wall trying to get Steam and SteamVR running on a machine that controls a Franka Emika robot. Because of the robot's strict latency requirements, we are forced to use a Realtime kernel (PREEMPT_RT), specifically 6.8.1-1015-realtime on Ubuntu 24.04.

I've managed to solve the usual Ubuntu 24.04 headaches (fixed the AppArmor user namespace blocking, installed the 32-bit deps, and got the Nvidia 580 drivers working by bypassing the RT check).

The Problem: Steam refuses to launch because pressure-vessel (the container system) seems incompatible with how Realtime kernels handle cgroups.

I’m getting the standard pressure-vessel architecture error: pressure-vessel-wrap: E: None of the supported CPU architectures are common to the graphics provider and the container

From what I understand, PREEMPT_RT kernels disable CONFIG_RT_GROUP_SCHED, which breaks the containerization Steam relies on.

What I have tried: I tried installing Steam in isolation using every available method: Deb, Snap, Apt, and Flatpak. Every single method failed with the same underlying container/namespace error.

Why we need this: We require VR and the Robot running on the same machine for our teleoperation workflow. Dual booting is a major hassle for our daily operations. We looked into other VR runtimes, but most use similar container logic or simply don't perform as well as SteamVR.

Since I haven't found any existing open issues covering this specific combination (RT Kernel + SteamVR), I am reaching out here. The cgroup issue source

Is there a specific flag or method to run Steam "bare metal" and completely bypass the pressure-vessel/container layer? Or is there a known workaround to get the container runtime to play nice with a realtime kernel?

Thanks for any help or advice

[TTimo]

Hello,

Please make sure you use the official .deb installer provided by Valve at https://repo.steampowered.com/steam/ - flatpak has issues with SteamVR, and snap has issues with everything, we don't support those.

Does Steam start when booting on a standard kernel? Does your PREEMPT_RT kernel disable 32 bit support maybe? That would explain the None of the supported CPU architectures are common to the graphics provider and the container

Please provide the following logs:

• The output of ~/.steam/steam/ubuntu12_32/steam-runtime/run.sh -- steam-runtime-system-info
• The content of ~/.steam/steam/logs/

[berkecyln]

Hello @TTimo ,

Thanks for the response.

To confirm, I am currently using the official .deb installer. I only attempted Snap/Flatpak previously to see if they handled the containerization differently, but I have since reverted to a clean install using only the official .deb.

Regarding your question about the standard kernel: I have not tested on the generic kernel yet. Since this machine controls a robot, the Nvidia drivers are manually patched for the PREEMPT_RT kernel (requiring IGNORE_PREEMPT_RT_PRESENCE=1 for CUDA support). Booting into a generic kernel would likely break the driver installation and require a time-consuming reinstall/re-patching process so it will be my last resort sadly.

I am hoping the logs will pinpoint the architecture or container issue without needing that step, but if you say it is necessary i can try but anycase we want to run steam on this PREEMPT_RT kernel.

Attached are the requested logs:

• steam_logs.tar.gz
• steam_system_info.txt

Thanks for the help

[smcv]

From what I understand, PREEMPT_RT kernels disable CONFIG_RT_GROUP_SCHED, which breaks the containerization Steam relies on.

I am not aware of any reason for Steam's containerization to interact with scheduling.

pressure-vessel-wrap: E: None of the supported CPU architectures are common to the graphics provider and the container

This error means that we weren't able to run x86_64 or i386 GNU/Linux (glibc) binaries successfully, which shouldn't have anything to do with the presence or absence of real time scheduling, or cgroup-related features.

[smcv]

LD_LIBRARY_PATH=...:/home/ceylanb/miniconda3/envs/franky/lib:...

What locally-installed libraries do you have in there? A wild guess is that this could potentially interfere with Steam: perhaps try launching Steam as env -u LD_LIBRARY_PATH steam, or temporarily moving this out of the way.

If that doesn't help, please try with STEAM_LINUX_RUNTIME_VERBOSE=1 in the environment, which will put a lot more information in ~/.steam/steam/logs/webhelper-linux.txt, including exactly what we tried and failed to run, and any error messages that might have appeared. (I suspect it'll be /path/to/x86_64-linux-gnu-capsule-capture-libs --print-ld.so and the same for i386-linux-gnu-capsule-capture-libs.)

[smcv]

Does your PREEMPT_RT kernel disable 32 bit support maybe? That would explain the None of the supported CPU architectures are common to the graphics provider and the container

I don't think it can be that: a 64-bit-only kernel would break Steam, but the container runtime framework should still be able to start the container as 64-bit-only. Also, the logs show the first stage of the Steam client bootstrap (which is 32-bit) running successfully.

[smcv]

pressure-vessel (the container system) seems incompatible with how Realtime kernels handle cgroups

Do you have evidence for this statement, like perhaps an error message that I haven't seen, or is it just a guess? If your kernel's cgroup handling is incompatible with Docker, then that would break Docker, but not necessarily pressure-vessel - even though they are both container-related technologies, their requirements are not identical.

pressure-vessel is more similar to Flatpak than it is to Docker. The fact that you were able to install and launch the Flatpak version of Steam, and it got far enough into its startup to be able to log this error message, suggests that your kernel does meet the requirements that pressure-vessel has in common with Flatpak.

[smcv]

managed to solve the usual Ubuntu 24.04 headaches (fixed the AppArmor user namespace blocking)

If you're running on Ubuntu with AppArmor enabled (as it is by default), then it's always worth checking the systemd Journal, which should be where AppArmor puts denial messages for anything that it doesn't allow. It's possible that AppArmor, or some other system component, is preventing pressure-vessel from doing its job?

apparmor="DENIED" is the key thing to look for.

If there are any other concerning-looking messages in the Journal around the time that you tried starting Steam, those might also be relevant.

[berkecyln]

Hello @smcv,

Thanks for digging into this. You were right about the LD_LIBRARY_PATH. I tested it and here's what I found.

So I ran Steam with a completely clean environment like you suggested:

env -u LD_LIBRARY_PATH steam -noverifyfiles

(I am running with noverifyfiles because if I not do that steam stuck at extracting and verifying)

And it turns out the actual error is not the architecture detection thing I mentioned before. Steam gets stuck in an infinite loop with this:

pressure-vessel-wrap[139907]: E: Could not create copy "./bin/[" from 
"/home/ceylanb/.local/share/Steam/steamrt64/steam-runtime-steamrt/steamrt3c_platform_3c.0.20250929.168601/files/./5c/348873-1.bin" 
into "/home/ceylanb/.local/share/Steam/steamrt64/steam-runtime-steamrt/var/tmp-QFM0G3/usr": 
fstatat(./5c/348873-1.bin): No such file or directory

It just keeps retrying with different tmp directories (tmp-LADIH3, tmp-IWQEH3, etc.) forever until I kill it.

About conda library you were right to ask about this. Even though I had deactivated conda, the LD_LIBRARY_PATH was still pointing to the franky environment:

CONDA_DEFAULT_ENV: [empty]
LD_LIBRARY_PATH: /home/ceylanb/miniconda3/envs/franky/lib:

But after testing with env -u LD_LIBRARY_PATH, I get the exact same error. So it's not the conda libraries causing the problem.

This error - fstatat(./5c/348873-1.bin): No such file or directory - looks a lot like overlay filesystem corruption. The file path exists but fstatat() can't access it. From what I've read, PREEMPT_RT kernels have known issues with overlay filesystems, and pressure-vessel uses overlays for the container runtime.

What makes me think it's RT-related:

• User namespaces work fine (tested with unshare --user)
• The container framework starts up successfully
• It fails specifically when trying to copy files within the overlay mount
• This happens regardless of environment (with/without conda, different installation methods)

I did some other tests

AppArmor is still disabled, confirmed with:

$ cat /proc/sys/kernel/apparmor_restrict_unprivileged_userns
0

I don't have sudo right now to check systemd journal for other denials.

User namespaces are working:

$ unshare --user --map-root-user echo "User namespace works!"
User namespace works!

The webhelper-linux.txt file is 1.5MB and I've attached it in the tar. It shows the same fstatat error repeating over and over.

System details

• Kernel: 6.8.1-1015-realtime (PREEMPT_RT)
• Ubuntu: 24.04.3 LTS
• GPU: NVIDIA RTX 3090
• Driver: 580.95.05 (had to install with IGNORE_PREEMPT_RT_PRESENCE=1 to get GPU working, otherwise Nvidia installer refuses to work on RT kernels)
• Steam: Official .deb from repo.steampowered.com
• Command: env -u LD_LIBRARY_PATH steam -noverifyfiles

Sorry for long post and huge files testing everything take quite some time.

I've attached steam_logs.zip with:

• apparmor_status.txt
• environment_report.txt
• namespace_test.txt
• webhelper-linux.txt (the full verbose log)
• full log tar if needed

Let me know if you need anything else or have ideas on how to work around this

[smcv]

From what I've read, PREEMPT_RT kernels have known issues with overlay filesystems

This is plausible, but I don't know it to be true or false.

and pressure-vessel uses overlays for the container runtime

It does not. It might in future, and users with unusual storage configurations have certainly asked for this; but pressure-vessel currently uses ordinary filesystem directories, with a tree of hard links (the equivalent of cp -al) for its transient directory.

[smcv]

This error - fstatat(./5c/348873-1.bin): No such file or directory - looks a lot like overlay filesystem corruption

The container runtime framework has a built-in integrity check. Running the command /home/ceylanb/.local/share/Steam/steamrt64/steam-runtime-steamrt/pressure-vessel/bin/pv-verify will check the runtime against the manifest files ./mtree.txt.gz and steamrt3c_platform_*/usr-mtree.txt.gz (they're in gzipped BSD mtree(8) format, if you're curious).

There might be some outdated versions of the runtime in steamrt3c_platform_*/ directories: ideally Steam should clean those up automatically, but if that didn't happen for whatever reason, they're basically harmless. But if there are any files missing from the current version of the runtime, that should get flagged as an error.

(The Steam client should have a way to self-check its own files and trigger a re-download/re-unpack if necessary, but I don't know offhand what that is. @TTimo?)

within the overlay mount

Is this an overlay mount that you or your OS vendor have set up, or an overlay mount that you are hypothesizing that Steam has? It shouldn't, unless you have set one up yourself.

[smcv]

I am running with noverifyfiles because if I not do that steam stuck at extracting and verifying

You're explicitly disabling the mechanism that would normally check whether an important part of Steam has been deleted, and now you're reporting that a required file has been deleted.

I also can't help noticing this:

[2025-12-15 12:52:22] pressure-vessel-wrap[110971]: D: Unable to delete /home/ceylanb/.local/share/Steam/steamrt64/steam-runtime-steamrt/var/tmp-I1DGH3: unlinkat(tmp-I1DGH3): Directory not empty

Is Steam installed on a filesystem with non-POSIX semantics, like perhaps NFS, SMB/CIFS or NTFS?

Steam for Linux is designed to be installed on an ordinary, local, on-disk Linux filesystem such as ext4, btrfs or xfs.

[berkecyln]

Hello thanks for returning with detailed explanations @smcv

I didn't know steam is not compatible with nfs. The lab computer have lots of users and so we use a network server and its nfs4. I will delete steam from this filesystem and try to setup in local storage which is ext4. Also the pv-verify command found hundreds of missing files including the 5c/348873-1.bin file that was causing the error. So using noverifyfiles was not right thanks for pointing out I was using that since somehow team was looping around extracting and verifying without showing any progress in terminal always setting percentage to be -1 . I suppose this extracing verifiying loop shouldnt happen when I setup in local ?

I will need to ask permisson to apply these so I cant approve if its worked or not. But thanks for the help spending time I will update when I try the local setup