search

ValveSoftware / SteamVR-for-Linux

Issue tracker for the Linux port of SteamVR
916 stars 45 forks source link

SteamVR beta is not launching #618

Closed dylanmtaylor closed 9 months ago

dylanmtaylor commented 11 months ago

Your system information

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist

When attempting to launch SteamVR (beta), I see this in the logs.

vrsetup.sh[4027713]: exec /home/dylan/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh /home/dylan/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
/home/dylan/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 30: cd: /home/dylan/.steam/debian-installation/steamapps/common/SteamVR/../runtime: No such file or directory
/home/dylan/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 31: cd: /home/dylan/.steam/debian-installation/steamapps/common/SteamVR/../sdk: No such file or directory
vrenv.sh[4027713]: exec /home/dylan/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrsetup.sh[4027713]: /home/dylan/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher binary has cap_sys_nice privileges

Nothing happens visually when I click the button to open SteamVR.

Steps for reproducing this issue:

I'm not sure how I got it to this state. I can't get VR working on Linux.

mSparks43 commented 11 months ago

SteamVR/bin/vrstartup.sh to launch steamVR vrsetup.sh just (afaik) installs stuff as root for VR applications to find it.

dylanmtaylor commented 11 months ago

I am launching it through the steam client, and these are the error messages that appear in my console.

ThaSwapMeetPimp commented 11 months ago

Am having same issue on Ubuntu-Studio 22.04, though all I can find in the logs is that its not even generating any entries, though I could be looking in the wrong ones.

JupiterSky11 commented 11 months ago

Also having this issue on Ubuntu 22.04. vrsetup.sh just hangs, doesn't respond to signals either.

ClearlyClaire commented 11 months ago

The same occurs to me. The script executes once and executes exec steam-runtime-launch-client --alongside-steam "$0" "$@"; then the script is executed again in its new environment, running to completion, but steam-runtime-launch-client hangs with 100% CPU usage.

LiamDawe commented 11 months ago

Also seeing this exact same problem on Kubunt 23.04, it just doesn't launch.

https://gist.github.com/LiamDawe/2ae46d1b4862a142a9e9fb926f8db381

JupiterSky11 commented 11 months ago

I "fixed" it by modifying the bash file and moving the last couple lines of vrstartup.sh to the end of vrsetup.sh, however there were other issues with vrenv.sh and upon the program starting it "couldn't connect to the window manager" with error code 497. Trying new beta (2.0.3) to see if the new fixes work.

JupiterSky11 commented 11 months ago

Still broken. Anyone have this in their logs? I see that LiamDawe has the same error.

/home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 30: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../runtime: No such file or directory
/home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 31: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../sdk: No such file or directory

I tried to find where these are supposed to point, but no dice. There aren't any files or folders named "sdk" anywhere in the steam directory, and runtime exists in a few cases but not verbosely.

jarettmillard commented 11 months ago

I was not affected by this issue in earlier 2.x betas, but I am now with the latest 2.0.3 beta. Running Pop OS 22.04.

LiamDawe commented 11 months ago

Still not working on Kubuntu with the latest update as well: https://gist.github.com/LiamDawe/83fabf58aa729d6d94d9506a530ec91f

extraymond commented 11 months ago

Still broken. Anyone have this in their logs? I see that LiamDawe has the same error.

/home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 30: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../runtime: No such file or directory
/home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 31: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../sdk: No such file or directory

I tried to find where these are supposed to point, but no dice. There aren't any files or folders named "sdk" anywhere in the steam directory, and runtime exists in a few cases but not verbosely.

+1 Ubuntu 22.04 with steam client beta and steamvr beta, having the same issue. It launches with stable steam client accompanied with steamvr beta though, albeit only able to see the old ui.

digitalcircuit commented 11 months ago

I reported the same issue on the SteamVR "Bug Reports" forum and didn't think to check the SteamVR for Linux issue tracker. The details and log files I shared there look the same as what's here, but I figured I should link it here so Valve/etc know to close that report when this one is closed.

ThaSwapMeetPimp commented 11 months ago

Still broken. Anyone have this in their logs? I see that LiamDawe has the same error.

/home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 30: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../runtime: No such file or directory
/home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 31: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../sdk: No such file or directory

I tried to find where these are supposed to point, but no dice. There aren't any files or folders named "sdk" anywhere in the steam directory, and runtime exists in a few cases but not verbosely.

Have you tried creating the folders that are missing? vrenv.sh may be trying to create the locations and your system might not be allowing it to because its trying to create it using a single command that types out the whole location tree for what its trying to create. My system does that, at some point when using commands like mkdir I started having to mkdir each missing location in the location tree (so to make /media/username/location, if username and location didnt exist, I cant just type out 'mkdir /media/username/location' anymore, now I have to type out 'mkdir /media/username' then 'mkdir /media/username/location'). The only reason I havent tried it myself is the /../ in the location tree, is that /../ indicating other folders in the tree or a folder that is labeled ..

mSparks43 commented 11 months ago

/home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 30: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../runtime: No such file or directory /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 31: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../sdk: No such file or directory

These are missing on a normal working install of 1.27.5

ThaSwapMeetPimp commented 11 months ago

/home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 30: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../runtime: No such file or directory /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh: line 31: cd: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/../sdk: No such file or directory

These are missing on a normal working install of 1.27.5

Whats your definition of a normal working install? There are things that dont work reliably or at all (at least for me) on Linux that do on Windows (Desktop and Desktop windows in VR Space, for example), maybe the new beta relies on those to work, and those missing directories are part of why they dont work. Maybe its hanging on a part that checks for those.

Im just throwing things at the wall here though, I dont really know

mSparks43 commented 11 months ago

Whats your definition of a normal working install?

609

There are things that dont work reliably or at all (at least for me) on Linux that do on Windows (Desktop and Desktop windows in VR Space, for example), maybe the new beta relies on those to work, and those missing directories are part of why they dont work. Maybe its hanging on a part that checks for those.

Im just throwing things at the wall here though, I dont really know

Beta 2 doesn't launch for me either, I've moved 1.27.5 to an offline version and sticking with that for now, all I need it for is to connect to the headset, it does that. I'm bored of being terrified every update will nuke my "working" install even if there are still plenty of issues to fix in the UI. I'm trying to develop for VR and have already lost months if not years to forced versions that won't start or CTD. I have zero faith this wont be made "final" in its current state. Last time they removed the compositor window which was a godsend for developing without a headset connected

ThaSwapMeetPimp commented 11 months ago

Still not launching with 2.0.4, and trying on Steam Client Stable Channel I get error 497 Failed to connect to Window Manager.

Edit: Same with 2.0.5.

ThaSwapMeetPimp commented 10 months ago

Edit: Edited because I did not realize that labels are added at Issue creation. Am creating a separate, more descriptive issue and title that will carry the bug label, see if that gets some movement.

Edit 2: Rant removed as I have calmed down about it.

mSparks43 commented 10 months ago

Edit: Edited because I did not realize that labels are added at Issue creation. Am creating a separate, more descriptive issue and title that will carry the bug label, see if that gets some movement.

Edit 2: Rant removed as I have calmed down about it.

Perfectly valid rant (for future reference github stores your edit history, so be careful what you post) They definitely intentionally broke it, that goes with the territory and how progress happens. What I don't understand is why they keep releasing things that are so broken no one can use them and worse replacing otherwise working versions with ones that don't and are so far from being ready. That slows everything to a crael because no one can get anything done.

Frustrating is putting it mildly.

digitalcircuit commented 10 months ago

@mSparks43 I'm quite frustrated by this breakage as well, but considering this SteamVR beta is longer term, and Linux has 0.93% market share that would reasonably run VR (i.e. discounting the Steam Deck: ((100−43.04)÷100)×1.63), even if we generously assume there are five times as many VR users on Linux as there as on Windows, that means that only 0.07% of Valve's customer base could be impacted by SteamVR beta being broken on Linux. And we still have the stable version of SteamVR to revert to during the beta.

(((100−43.04)÷100)×1.63)×((1.6÷100)×5)
= 0.07427584

43.04% = Linux users running SteamOS "Holo" from https://store.steampowered.com/hwsurvey/?platform=linux 1.63% = Steam users running Linux, including the rather popular Steam Deck (which isn't really suited for VR) from https://store.steampowered.com/hwsurvey/ 1.6% = number of Steam users across all platforms with VR from https://store.steampowered.com/hwsurvey/

I'm daily-driving VR on Linux and I want better support from Valve for this, but it feels.. uncharitable to say they intentionally broke Linux support in the first month of the beta for a massive overhauling of a niche product (SteamVR) for a niche audience (Linux users on VR). Even with generous assumptions, we could be a rounding error.

For now, back on topic, I'll keep to testing the SteamVR beta with every update released, and when something changes (working or breaks differently) I'll update here with a comment or a thumbs-up if someone else already reported it.

mSparks43 commented 10 months ago

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/618#issuecomment-1773432489

This is all caused by their linux dev platform being so unstable its been virtually impossible to develop for, not a reason for it. No one was using occulus when SteamVR started, now it is the largest VR market by far (in a headset that runs Linux no less)

TTimo commented 10 months ago

Hello,

The errors from vrenv.sh are a red herring and unrelated to the issue here.

I don't think it's the case here that anyone is using snap, but it's worth mentioning (again - don't!).

As I'm writing this I realize there may be a problem and we are not using the zenity bundled in the Steam runtime like we should. This could explain the hang (will fix).

dylanmtaylor commented 10 months ago

I am not using snap. I will check for zenity and see if that fixes it.

dylanmtaylor commented 10 months ago

When attempting to install zenity, I get

zenity is already the newest version (3.44.2-1).

vrstartup.sh[25527]: === Sat Oct 21 21:00:34 EDT 2023 === vrstartup.sh[25527]: Steam Linux Runtime: sniper_platform_0.20231005.62324 vrstartup.sh[25527]: exec /home/dylan/.local/share/Steam/steamapps/common/SteamVR/bin/vrenv.sh /home/dylan/.local/share/Steam/steamapps/common/SteamVR/bin/vrstartup.sh vrenv.sh[25527]: exec /home/dylan/.local/share/Steam/steamapps/common/SteamVR/bin/vrstartup.sh vrstartup.sh[25527]: Steam Linux Runtime: sniper_platform_0.20231005.62324 vrstartup.sh[25527]: call /home/dylan/.local/share/Steam/steamapps/common/SteamVR/bin/vrsetup.sh vrsetup.sh[25560]: Detected Steam Linux Runtime pressure-vessel launch in sniper_platform_0.20231005.62324 vrsetup.sh[25560]: Relaunching via steam launcher service to host level for vrcompositor setcap configuration. vrsetup.sh[25572]: exec /home/dylan/.local/share/Steam/steamapps/common/SteamVR/bin/vrenv.sh /home/dylan/.local/share/Steam/steamapps/common/SteamVR/bin/vrsetup.sh vrenv.sh[25572]: exec /home/dylan/.local/share/Steam/steamapps/common/SteamVR/bin/vrsetup.sh

^ it hangs here.

JupiterSky11 commented 10 months ago

I also have both Zenity and the non-snap version. All I can tell on my side without external information is that stuff isn't found by the environment setup script, so I assume that's causing issues. If not, then it could just be steam's binary files not functioning properly. Perhaps there are some zenity configs that need to be adjusted, but I have no idea what zenity is or what it does. +1 to it being bundled with Steam though, a self contained system is always more reliable.

vrstartup.sh[175966]: === Sat Oct 21 21:08:52 EDT 2023 ===
vrstartup.sh[175966]: Steam Linux Runtime: sniper_platform_0.20231016.63422
vrstartup.sh[175966]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrstartup.sh
vrenv.sh[175966]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrstartup.sh
vrstartup.sh[175966]: Steam Linux Runtime: sniper_platform_0.20231016.63422
vrstartup.sh[175966]: call /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrsetup.sh[175999]: Detected Steam Linux Runtime pressure-vessel launch in sniper_platform_0.20231016.63422
vrsetup.sh[175999]: Relaunching via steam launcher service to host level for vrcompositor setcap configuration.
vrsetup.sh[176011]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrenv.sh[176011]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh

This is on the latest version, as of the log date.

TTimo commented 10 months ago

Please un-comment the set -x line at the top of vrsetup.sh and try again:

# verbose
set -x

The Steam client should produce an output that looks like this:

steamvr-vrsetup-verbose

(zenity is a small app for doing prompts and error dialogs)

TTimo commented 10 months ago

Better yet, try replacing vrsetup.sh with this version:

https://www.dropbox.com/scl/fi/43xug7bo3nn1j1qy71wew/vrsetup.sh?rlkey=7mqscs6a3h94qbrqf5cacl2tk&dl=0

That may fix the zenity problem (assuming that's what it is) and get you to the pkexec privileges prompt:

steamvr-vrsetup-scout-ldlp

JupiterSky11 commented 10 months ago

Here's the output for that:

vrstartup.sh[175966]: === Sat Oct 21 21:08:52 EDT 2023 ===
vrstartup.sh[175966]: Steam Linux Runtime: sniper_platform_0.20231016.63422
vrstartup.sh[175966]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrstartup.sh
vrenv.sh[175966]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrstartup.sh
vrstartup.sh[175966]: Steam Linux Runtime: sniper_platform_0.20231016.63422
vrstartup.sh[175966]: call /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrsetup.sh[175999]: Detected Steam Linux Runtime pressure-vessel launch in sniper_platform_0.20231016.63422
vrsetup.sh[175999]: Relaunching via steam launcher service to host level for vrcompositor setcap configuration.
vrsetup.sh[176011]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrenv.sh[176011]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrstartup.sh[188851]: === Sat Oct 21 22:32:13 EDT 2023 ===
vrstartup.sh[188851]: Steam Linux Runtime: sniper_platform_0.20231016.63422
vrstartup.sh[188851]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrstartup.sh
vrenv.sh[188851]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrstartup.sh
vrstartup.sh[188851]: Steam Linux Runtime: sniper_platform_0.20231016.63422
vrstartup.sh[188851]: call /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrsetup.sh[188884]: Detected Steam Linux Runtime pressure-vessel launch in sniper_platform_0.20231016.63422
vrsetup.sh[188884]: Relaunching via steam launcher service to host level for vrcompositor setcap configuration.
vrsetup.sh[188896]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrenv.sh /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrenv.sh[188896]: exec /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrsetup.sh[188896]: Relaunching under scout LDLP runtime.
vrsetup.sh[188896]: exec /home/jupitersky/.steam/bin/steam-runtime/run.sh /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
vrsetup.sh[188896]: Detected scout LDLP runtime.
vrsetup.sh[188896]: /home/jupitersky/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher binary has cap_sys_nice privileges

I'm gonna try to completely re-install with this script, hold on.

TTimo commented 10 months ago

Alright - so not a problem with zenity or the pkexec process, the script reports you already have adequate permissions.

I suspect steam-runtime-launch-client does not return when it should. Once you get to the point above where things are stuck, try to issue killall steam-runtime-launch-client ?

digitalcircuit commented 10 months ago

@TTimo Partial good news - for my system¹, your update to the vrsetup.sh script made SteamVR beta able to launch! :tada:

Unfortunately, I now get the "Failed to connect to window manager" (497) error, which appears to be impacting a number of other folks, too.

I've subscribed to the above bug report, and assume I should wait for steps there (to keep this focused on failure to launch). However, if you'd like me to do any more testing, let me know. And thank you for your time!

EDIT: Well, I rebooted and still got that error message. Then I closed the leftover processes with pkill -9 -f vr, downgraded to SteamVR stable, launched it just fine, then re-upgraded to SteamVR beta and re-applied the patched vrsetup.sh, and now I get a different error - "Shared IPC Compositor Init Failed (303)". And after rebooting it's still that. So I'll subscribe to that bug report too.

Regardless, the patched vrsetup.sh is a clear step forward.

¹ Kubuntu 22.04 LTS, Steam via .deb package

ThaSwapMeetPimp commented 10 months ago

For my system also, the update to vrsetup.sh scrip made beta able to launch, and like digitalcircuit, getting 497 error.

Edit: After a reboot, now getting error 303. Steam Home is opening and I can play games. No desktop view but that's always hit or miss anyways. Still old UI.

ClearlyClaire commented 10 months ago

Alright - so not a problem with zenity or the pkexec process, the script reports you already have adequate permissions.

I suspect steam-runtime-launch-client does not return when it should. Once you get to the point above where things are stuck, try to issue killall steam-runtime-launch-client ?

Yes, steam-runtime-launch-client doesn't seem to cleanly exit like it should. It seems to just hang, sometimes without significant CPU usage, sometimes with 100% CPU usage. The edited script returns without hanging, and then SteamVR kind of works, but SteamVR Home doesn't load, the steam-runtime-launch-client for steamtours is at 100% and other related steam-runtime-launch-client processes get stuck, with SteamVR does not exiting correctly and requiring steam-runtime-launch-client processes to be manually killed.

I also get “SteamVR failed to initialize for unknown reasons. (Error: Shared IPC Compositor Init Failed (303) (303))” which may or may not be related, but this does not prevent the dashboard from working.

TTimo commented 10 months ago

Hello,

The launch script fixes will ship in a beta update (likely today).

I would like to keep this issue focused on any launch script and early startup problems that may remain. Everything else I see mentioned since my last update is already reported in other issues.

steam-runtime-launch-client is expected to wait on the process that was launched via the Steam service exiting before also exiting. There is only going to be a problem if said process has exited, and steam-runtime-launch-client does not.

@JupiterSky11 can you provide an update on this? It seemed like that could be the case for you (@ClearlyClaire also, but that process is expected to stay running while SteamVR Home is up for instance).

JupiterSky11 commented 10 months ago

@TTimo sorry for the delay, college has been rough.

I did a complete reinstall with the updated script and it worked as far as I can tell. It opens with a 303 error, the headset boots up, the normal interface appears alongside the steamvr settings window, and as per usual there's a black window that is impossible to close or kill. I will edit this in a bit to report on functions beyond it turning on and not instantly crashing.

EDIT: It seems to work besides the 303 error. Except the microphone isn't being started. Not sure if the interface is the new one, as nothing looks different than before, but at the very least it runs!

ClearlyClaire commented 10 months ago

steam-runtime-launch-client is expected to wait on the process that was launched via the Steam service exiting before also exiting. There is only going to be a problem if said process has exited, and steam-runtime-launch-client does not.

@JupiterSky11 can you provide an update on this? It seemed like that could be the case for you (@ClearlyClaire also, but that process is expected to stay running while SteamVR Home is up for instance).

Yeah, this is consistent with steam-runtime-launch-client not exiting when it should. The unmodified vrsetup.sh script execs into steam-runtime-launch-client, the inner script runs to completion, but steam-runtime-launch-client does not exit. If I kill it, it progresses to launching SteamVR, which kinda works as described above. But quitting it leaves dangling steam-runtime-launch-client processes (and SteamVR is still marked as “running” inside Steam).

If I simplify vrsetup.sh down to the following, it exhibits the same issue:

#!/bin/bash

# verbose
set -x

set -o pipefail
shopt -s failglob
set -u

if [ -z "${PRESSURE_VESSEL_RUNTIME-}" ]; then
    exit 0
else
    if [ -z ${SRT_LAUNCHER_SERVICE_ALONGSIDE_STEAM-} ]; then
        exit 1
    else
        exec steam-runtime-launch-client --alongside-steam "$0" "$@"
        # unreachable
    fi
    exit 0
fi

The script should return immediately, but it doesn't: image

TTimo commented 10 months ago

@ClearlyClaire I see vrsetup.sh is still running, as a child of steam-runtime-launcher-service. That's the problem - once it exits, steam-runtime-launch-client will likely exit cleanly (that's the whole point of the mechanism, it throws the execution at steam-runtime-launcher-service and waits).

What's the status of that vrsetup.sh process? If it's the modified version you've shown above it doesn't really have any option to get stuck. So maybe it's in a zombie state at that point and waiting to be reaped?

Can you upload a report out of Help -> Steam Runtime Diagnostics in the Steam client? If you don't feel comfortable linking it publicly you can email it to me at ttimo@valvesoftware.com

ThaSwapMeetPimp commented 10 months ago

The launch script fixes will ship in a beta update (likely today).

Still not launching with 2.0.7 under Client Beta, if that was the update that was supposed to have the launch script fixes. Replacing vrsetup.sh still works.

Edit: 2.0.7 Launches without replacing vrsetup.sh under Client Stable with error 497.

extraymond commented 10 months ago

Can confirm with vrsetup.sh fix 2.0.7 works, steamvr beta now boots up instead of showing nothing silently. Still getting the 303 error and with the old ui though.

Some quirks observed:

  1. in steam, even after closing steamvr it shows it's running and pressing stop does nothing
  2. when launching steamvr beta, it prompts with latest steam beta required, although my steam client is already at the latest beta

ubuntu 22.04, kde, x11, steam-beta(deb)

digitalcircuit commented 10 months ago

I apologize, I goofed with my prior success report by overlooking file system permissions…

The updated vrsetup.sh from Dropbox didn't actually fix my issue, removing execute permissions did, i.e. making the script unlaunchable:

$ ls -l "$HOME/.local/share/Steam/steamapps/common/SteamVR/bin/"
[…]
-rwxrwxr-x 1 user user    2807 Oct 24 02:46 vrsetup.sh
-rw-rw-r-- 1 user user    2803 Oct 22 00:55 vrsetup.sh.from_dropbox
[…]

There's no difference with the new script versus Dropbox script if I chmod 755 it. (Aside, the Verify integrity of tool files button does not restore execute permissions if the file is otherwise identical. It will if the file content is different.)

I've tried @ClearlyClaire 's modified version of vrsetup.sh, making sure to grant it execute permissions, and that has the same problem - vrsetup.sh becomes a zombie:

$  ps aux | grep -e 'vrsetup.sh' | grep -v grep
user        22233  0.0  0.0      0     0 ?        Zs   02:59   0:00 [vrsetup.sh] <defunct>

If desired, I can email a copy of my Steam Runtime Diagnostics.

ClearlyClaire commented 10 months ago

@ClearlyClaire I see vrsetup.sh is still running, as a child of steam-runtime-launcher-service. That's the problem - once it exits, steam-runtime-launch-client will likely exit cleanly (that's the whole point of the mechanism, it throws the execution at steam-runtime-launcher-service and waits).

What's the status of that vrsetup.sh process? If it's the modified version you've shown above it doesn't really have any option to get stuck. So maybe it's in a zombie state at that point and waiting to be reaped?

It's the modified vrsetup.sh with not much in it. It's a zombie process:

claire@swordfish:~$ ps aux | grep vrsetup
claire     23292  0.0  0.0 159200  5888 ?        Sl   13:13   0:00 steam-runtime-launch-client --alongside-steam /home/claire/.steam/debian-installation/steamapps/common/SteamVR/bin/vrsetup.sh
claire     23301  0.0  0.0      0     0 ?        Zs   13:13   0:00 [vrsetup.sh] <defunct>
claire     25502  0.0  0.0   6368  2048 pts/4    S+   13:16   0:00 grep vrsetup

Can you upload a report out of Help -> Steam Runtime Diagnostics in the Steam client? If you don't feel comfortable linking it publicly you can email it to me at ttimo@valvesoftware.com

Sent!

TTimo commented 10 months ago

Thanks, we identified the problem and are working on a fix.

smcv commented 10 months ago

This should be working in the latest Steam client beta, version 1698185488 (2023-10-24). I don't have VR hardware myself, but I was able to reproduce a similar problem on Ubuntu 22.04 without VR, and I've confirmed that it's fixed now.

The key diagnostic for this is that steam-runtime-launch-client never exits and there is a zombie process [vrsetup.sh] <defunct>, as shown in @ClearlyClaire's most recent comment. This was mainly (only?) a problem on Debian/Ubuntu and their derivatives, where /bin/sh is normally dash. Systems where /bin/sh is bash are believed to have been unaffected.

LiamDawe commented 10 months ago

Can confirm SteamVR on Kubuntu 23.10 will now actually load up, although it does initially give this error https://github.com/ValveSoftware/SteamVR-for-Linux/issues/623 and now I'm getting the old VR UI so this issue is also back https://github.com/ValveSoftware/SteamVR-for-Linux/issues/614

ClearlyClaire commented 10 months ago

I can confirm that after updating and relaunching both the Steam client beta and SteamVR beta, vrsetup.sh and other scripts exit as intended, and Steam VR starts.

smcv commented 10 months ago

Can confirm SteamVR on Kubuntu 23.10 will now actually load up, although it does initially give this error #623 and now I'm getting the old VR UI so this issue is also back #614

I think it's best to consider those to be tracked in #614 and #623, and outside the scope of this particular issue - mixing up more than one thing on the same issue report makes it take longer to understand and resolve.

ThaSwapMeetPimp commented 10 months ago

Can confirm that 2.0.8 launches now, will go to other thread for the other continuing issues.

Corben78 commented 10 months ago

Still not working for me on Ubuntu 20.04 LTS. Same behaviour as mentioned in https://github.com/ValveSoftware/SteamVR-for-Linux/issues/618#issuecomment-1777037928 Tried to link /bin/sh to /bin/bash which didn't make a difference.

edit: today the Steam client downloaded some libs. It does start now. had "failed to connect to window manager (497)" error then, but it helped to reboot without the HMD connected. Connecting the HMD after Steam client start did work. Steam VR beta launches. Can't play any Proton game though (Beat Saber, Synth Riders), but native Linux games seem to work (Groove gunner). This issue was happening to me with 1.27.5 already though.

TarsiSurdi commented 10 months ago

I'm facing the issue where these files (vrstartup.sh & vrenv.sh) don't even exist under /bin. I have verified the game's files multiple times, switch from beta to stable, to stable from beta, uninstalled it... - everything! But still both of these script's simply aren't there after an install and clicking "Launch" on the client does absolutely nothing :(

smcv commented 10 months ago

@TarsiSurdi: If some files are completely missing from SteamVR/bin for you, that doesn't match the original report in this issue or any of the recent comments, so I think that would be better reported as a separate issue.

TarsiSurdi commented 10 months ago

@TarsiSurdi: If some files are completely missing from SteamVR/bin for you, that doesn't match the original report in this issue or any of the recent comments, so I think that would be better reported as a separate issue.

I'm not creating another issue since I believe this to be related to the Steam Client Beta itself, but I've been able to solve it yesterday. Turns out Steam was downloading the Windows version of SteamVR even when no compatibility tool was selected for the app at all.

After realizing this had been happening I went to its compatibility settings, turned it on by selecting random Proton versions and then turned it off again. After doing that, Steam downloaded the correct Linux specific binaries.

Also, by following advice in this thread I have downgraded to version 1.27 and am now able to launch Steam VR, connect to my headset through ALVR and get into SteamVR home - things I' not able to do with the current "stable" version; launching any applications doesn't seem to work as intended though.

When opening games the dashboard keeps "loading..." then indefinitely, is able to launch them on my computer but no image gets streamed to the HMD. I've tested the following games with regular Proton Experimental and ProtonGE8-17 and all have presented the same behavior:

However, I think this might be a problem with my setup since I'm running on GNOME Wayland with NVIDIA 535 drivers. I'll be trying out the latest beta NVIDIA drivers (545) today since it references fixes for VR gaming in its changelog and could possibly be the issue in this situation.

EDIT: when testing SteamVR 2.xx earlier I couldn't get it if I weren't using the following launch parameters: 

QT_QPA_PLATFORM=xcb SDL_VIDEODRIVER=x11 VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json %command%

After downgrading the app behaves the same whether I use them or not...