Steam fails to launch following July 21st client update on GNU Guix

[RJSent]

Your system information

• Steam client version (build number or date): July 21st 2026
• Distribution (e.g. Ubuntu): GNU Guix
• Opted into Steam client beta?: No
• Have you checked for system updates?: Yes
• Steam Logs: steam-logs.tar.gz
• GPU: AMD, 7900 XTX

Please describe your issue in as much detail as possible:

Following an update from the June 30th release to July 21st, I observe Steam fail to start on my GNU Guix system. This issue takes one of two forms depending on if the pipewire and pipewire-pulse services are running:

1. If they are, Steam segfaults shortly after launch similar to threaded-ml segmentation fault in libaudio.so on startup #9289. No UI appears. I confirmed the problem is in libaudio.so by running Steam in GDB. https://gist.github.com/RJSent/5e885391a6280c8e141d704d0b68db68
2. If they're stopped via herd stop pipewire, Steam progresses to displaying a "Waiting for network" window, at which point nothing further visibly happens. No activity is observed in the console.

When Steam segfaults in case 1 I see this printed ~5 times in .local/state/shepherd/shepherd.log:

2026-07-21 22:55:32 pipewire-pulse[2098] [E][22:55:32.243063] mod.protocol-pulse | [  pulse-server.c: 3654 fill_card_info()] 0x5562f020b480: card 51 port 0 profiles inconsistent (0 < 3)

I did try both steam -reset and GUIX_SANDBOX_HOME=/tmp/sandbox steam, no change in behavior.

After downgrading to the June 30th release following these instructions, Steam launches again as expected.

The issue occurs in both Sway and StumpWM.

The issue occurred independent of system updates (system wasn't updated for the past week or so) and persisted after an update.

The flathub version also works.

Steps for reproducing this issue:

1. Have a GNU Guix system running StumpWM, home-pipewire-service-type, and home-dbus-service-type.
2. Update Steam to the July 21st release.

I've linked my GNU Guix configuration if it's of any help. I can also provide a minimal VM setup if needed. https://git.sr.ht/~freakingpenguin/rsent

Edit: I spoke with another user in the #nonguix IRC channel who is also using home-pipewire-service-type and home-dbus-service-type and they aren't able to replicate it so there's probably more to this.

[Kethen]

I run steam inside a Cachyos Podman container and I'm observing case 2. (stuck on waiting for network) as well, had to downgrade to 20260630154056 for it to work again.

The container has no access to system dbus nor user dbus, notably things like NetworkManager is out of steam's reach. I wonder if that has to do with the indefinite waiting for network.

might be related:
#9587
#9966

[lostgoat]

@RJSent I'm not sure where it would be in your system, but can you check the equivalent of /tmp/dumps for minidumps and attach them to this issue? If you'd like to reduce the number of dumps to attach you can clear out the folder and then repro the crash.

Can you also attach the full stdout of running steam outside a debugger? Normally that is created as a console-linux.txt file, but on your setup that doesn't seem to be working.

[kolAflash]

I hope this may help other to solve the issue on their computer:
I run Steam in Firejail. And after installing the latest Steam update today (2026-07-25) I had to allow write access to /run/dbus on a computer NOT using NetworkManager. Meanwhile the latest Steam is working WITHOUT /run/dbus access on another computer using NetworkManager.
I don't know the last working Steam version. But I probably updated Steam last some-when in the first 2 July weeks on the affected computer.

both computers:
Steam Version: 1784778118
OS: Debian-13

[Thanood]

I can confirm and maybe narrow down this issue for the "stuck on Waiting for network, no crash" variant (i.e. without pipewire/pipewire-pulse running). I'm running StumpWM on GNU Guix as well.

Probable root cause: the Steam container's mount namespace does not include /run/dbus, so DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket (inherited from the host environment) points to a socket path that doesn't exist inside the container. I confirmed this by inspecting the running steamwebhelper process:

$ cat /proc/<pid>/environ | tr '\0' '\n' | grep -i dbus
DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket

$ ls -la /proc/<pid>/root/run
current-system
user

Note /run/dbus is missing from the container's /run. The steamwebhelper CEF log shows the resulting failure as:

[INFO:CONSOLE(2)] "SteamApp Init - Before Login - SystemNetworkStore - ERROR TypeError: SteamClient.System.Network.RegisterForDeviceChanges is not a function"

SystemNetworkStore tries to register for network-change notifications via the system D-Bus (presumably to talk to NetworkManager), can't reach it, and Steam hangs indefinitely on the network-check splash.

Workaround: explicitly share /run/dbus into the nonguix container:

GUIX_SANDBOX_EXTRA_SHARES=/run/dbus steam

This resolves the hang and lets Steam log in normally for me. My system does not have pipewire/pipewire-pulse installed at all, so I can't speak to the segfault variant reported above, but the "waiting for network" hang specifically looks like a missing D-Bus system bus mount rather than anything audio-related.

[RJSent]

I can confirm the GUIX_SANDBOX_EXTRA_SHARES fix resolved the "waiting for network" issue I saw. It did not resolve the Pipewire crash.

@lostgoat re. the Pipewire crash, here's a tarball containing the contents of /tmp/dump, console + gdb output, and a cleaned out Steam/logs folder where I ran Steam once in gdb, then once directly in the console. I also added the home dbus and pipewire-pulse service logs.

steam_pipewire.tar.gz

Edit: Previously restarting pipewire and pipewire-pulseaudio did not resolve the issue, but it did in my most recent attempt. The first part of this issue may be a duplicate of #9289.

[Kimiblock]

Running Steam inside a Portable sandbox and experiencing the same issue.

I would rather not allow system bus access since that may cause unauthorised permission elevation due to poorly written services. Portable at this stage does not have filtering rules for system bus unlike the user bus either.

[Kimiblock]

Here's a hacky workaround without exposing system bus: just set the session bus address as system bus address

Kraftland/portable-arch@c668a62

[podiki]

Most of these reports (all but the podman report, which surprises me with no dbus at all) seem to point to a change that Steam won't start with just a system dbus anymore. For example, I don't reproduce on nonguix as I do have user dbus which does get shared to the container Steam runs in. This assumes users without a user dbus session previously didn't either (sounds like the case).

I will note that the reports look to be in non-DE setups, meaning the user probably needs to be the one to start a user dbus session. However, I think it is probably more "correct," for lack of a better term, that one should have a user dbus session and that is what Steam should use. See https://dbus.freedesktop.org/doc/dbus-daemon.1.html for instance.

It would help to have confirmation from Steam what is expected, though this might be a case where those on setups besides e.g. Gnome or KDE are expected to make sure they have things like a user dbus session started.

(Edit: Ah, a system dbus session could also be for adding/removing devices, so perhaps Steam should or does require both for full operation? At least right now, just the user session is required to start, while previously it was just any dbus it seems.)

[Kimiblock]

It requires the system bus since that Jul 21st client update. Though a skeleton bus (in my case, it's the sandboxed user bus masqueraded as system bus) is good enough to trick Steam.

I have heard in the past that Steam interfaces with NetworkManager to get connectivity and not granting the TALK permission results in a few seconds timeout delay when logging in, and it also seems to use UPower and Udisks judging from Flatpak's manifest though not granting access doesn't brick the whole client.

[armandolara]

Possibly the same underlying bug. On Fedora Asahi Remix 44 (aarch64, Apple M1 Pro, Steam running under FEX-Emu + muvm microVM), a completely clean install (fresh ~/.local/share/Steam, no prior config) reproduces this exact symptom on both stable (1785799196, built Aug 3 2026) and publicbeta (1785347151, built Jul 29 2026).

cef_log.txt shows:

SteamApp Init - Before Login - SystemNetworkStore - ERROR
TypeError: SteamClient.System.Network.RegisterForDeviceChanges is not a function
source: https://steamloopback.host/library.js

This isn't a real network problem — connection_log.txt shows every connectivity test passing (IPv4 OK, IPv6 HTTP SUCCESS, IPv6 UDP SUCCESS), and steamui_login.txt shows the backend reports SetLoginState: WaitingForCredentials - OK. The UI just never advances past "Waiting for network."

I checked whether the function exists in the shipped binaries:

$ strings ~/.local/share/Steam/ubuntu12_64/steamclient.so | grep -c RegisterForDeviceChanges
0
$ strings ~/.local/share/Steam/ubuntu12_64/steamwebhelper | grep -c RegisterForDeviceChanges
0

steamui/chunk~2dcc5aaf7.js calls this function, but it doesn't exist in either steamclient.so or steamwebhelper. I've opened a separate issue with full details: [link once posted]

Reproduces in both desktop UI and Big Picture mode (-gamepadui).

[nnnn20430]

Have you tried enabling SteamRT3 client? That seems to have fixed Steam recognizing NetworkManager for me on Guix, but I had no problem launching it in either case though.