Issue is still reproducible: steam-logs.tar.gz
I'm not sure anymore if this issue has anything to do with Debian 13 or the installation method (Flatpak). Between April 29 and May 08, Steam launched once after all, but I assumed that was a fluke. The same happened yesterday, and I began to suspect something fishy is going on.
In both cases, Steam launched and worked fine until the handheld (GPD Win Mini 2024) suspended. After wakeup, Steam reported that it couldn't detect an Internet connection. Obviously, at this point, I had to exit Steam and try launching it again, and unsurprisingly, it failed to launch, as usual. I think this detail "After wakeup, Steam reported that it couldn't detect an Internet connection" is important.
Today, I tried experimenting with Steam launch options, but none of them helped to work around this issue. I also tried to force Steam to re-download and reinstall itself (by harmlessly moving the .tar.gz file out of the Steam runtime folder). The updater attempted to extract the installation package but failed each time in the middle of the process (as if there's some timeout killing the entire launch process).
However, switching from my work WiFi to a smartphone hotspot surprisingly did help, but not for long:
Well, this was interesting. I disabled the smartphone hotspot so that on the next boot, the handheld connected to work WiFi again, and voilà:
4. Steam launched after reboot. I rebooted again.
5. Steam didn't launch with work WiFi.
The next idea was to try home WiFi instead of work WiFi:
6. Steam launched after reboot.
At this point, I'm just too afraid to reboot again, because if it stops working again, I will have run out of available access points.
@kisak-valve, any idea what might be happening here with Steam's server backend or the client's silent failure (no errors or crashes in logs) when it's launched with different IPv4/IPv6 addresses? How we can debug this?
To me it looks like some sort of anti-attack measure on the server side, or possibly code within the Steam client going rogue - especially when I look at the terminal output showing the extraction process being killed without error messages or crashes, seemingly due to a timeout - in the same way launch process gets killed in the logs published above. But of course I have no idea about Steam backend or client internals so I do hope you could shed some light on why there could be such drastic change of behavior after simply switching between WiFi access points, and why there is no error message in the logs?
Issue is still reproducible on the last build.
I also noticed "crash" happening in exactly 10 seconds after launch, almost as if it's not crash but some sort of watchdog within launcher?
I still have to rollback whole ~/.var/app/com.valvesoftware.Steam to fix launch issues.
Nothing extracted yet.
Your system information
Please describe your issue in as much detail as possible:
It's seems like latest Steam update no longer works if it's installed via Flatpak on Debian 13.
Issue is not reproducible if I rollback ~/.var/app/com.valvesoftware.Steam to earlier version I happen to have in btrfs snapshot, but as soon as Steam updates itself - it no longer works (logs attached above).
Issue is not reproducible when I try to launch Steam Flatpak on the other laptop with Debian 12 - April 28 build of Steam works there.
Steps for reproducing this issue: