Runtime Build ID 9027669 fails to launch games (Borderlands 3, Wonderlands) #516
Comments
|
Hello @apocalyptech - have you tried with Proton Experimental and latest Proton 7? It could be specific to GE. |
|
I have not, since the ingame videos apparently don't work on non-GE Proton builds. I suppose I could give it a try, though I'm generally loathe to rock the boat with swapping out Proton versions. I don't have any faith that doing so won't wipe out savegames or settings, etc, so I tend to keep the old versions around for quite awhile (hence why my BL3's still using an old 5.21). |
|
I cannot reproduce with Tiny Tina on Manjaro with Proton Experimental (it's a new install, I didn't have the game). I note that videos are playing too. I don't have a Proton GE to check against atm. |
|
Are there any symbolic links in the path to and the equivalents for |
The build IDs you quoted here are releases of I think you are saying that varying the version of "Steam Linux Runtime - soldier" causes this issue to appear or disappear, and varying the version of "Steam Linux Runtime" doesn't have any effect. Is that correct? Like this:
Or if that's not correct, please confirm what you are varying to make this issue appear or disappear. |
|
Oh, are these both Windows games running under Proton? If so, then yes, varying "Steam Linux Runtime - soldier" would have an effect, and varying "Steam Linux Runtime" would not (and you probably don't even have "Steam Linux Runtime" installed). Another data point that would be useful would be to install a small, known-to-work Windows game for which you don't care about saved games etc. into the same prefix, swap that game between official Proton and unofficial Proton-GE, and report what happens (in particular whether it gets the same failure mode as one or both of these Borderlands-derived games). The Expendabros is a relatively small free-to-play Windows game which I often use for testing. |
|
A more detailed log for each of the Proton GE versions would also be useful: in addition to what you did to capture https://gist.github.com/apocalyptech/30a62ace83342519a92aa91da6f20dd5, please set If this is a problem with not all symlink targets being imported into the container, then the results I would expect to see with a known-good game like Expendabros would be something like this:
|
|
@smcv yeah they are both Proton titles / soldier SLR. I tested both Tiny Tina and Borderlands 3 on Manjaro and they work fine against official Proton. This may be a regression specific to GE's setup. |
|
Hello - thanks for the responses. Answers inlined below!
There's a pretty incredible utility called
Yep, that is correct - reverting to the
Ah indeed, right you are -- dunno why I didn't think of that before. I just picked Witcheye since I'd recently played it, and while that game does sort-of launch, it too has seemingly-identical problems. From its console: ... and various game components clearly didn't load, such as some opening text, textures on the "skip cutscene" buttons, and then the main menu never loads; it just gets stuck on a loading screen. All rather indicative of the EXE running but maybe being unable to load files. That's on both Proton 7.0 (from Steam) and Proton Experimental. As with BL3 and TTWL, reverting to the old Soldier does the trick, though.
Here's that log of me running Witcheye with, I believe, Proton Experimental: https://gist.github.com/15ef21b289f63682a56cdd081bdc63c5 |
|
|
|
The situation is now:
As far as I can tell so far, the problem scenario that triggers the regression involves having a path that we want to share with the container environment, for which either the path itself is a symbolic link, or one of the directories "above" it is a symbolic link. The container runtime has code to handle this situation, but it regressed in the last few weeks, most likely as a result of changes made for interoperability with FEX-Emu. |
|
The symptoms you observed with Wonderlands + GE-Proton7-20 are consistent with #518. I've been able to reproduce the same situation as #518 and I'm testing some possible solutions, which I hope will also work here. The symptoms you observed with Witcheye + Proton Experimental also seem very similar to #518, so, again, I'm hoping the solution will be the same. The symptoms you observed with Borderlands 3 + Proton-5.21-GE-1 are not the same, which means there might be something different going on. Because you're varying more than one thing at a time (game and also Proton version), and didn't attach a log for this scenario, it's hard to tell which factor is most important to trigger this. Please could you get a log with It would also be useful to see a similar log from Borderlands 3 with the It would also be interesting to see a similar log for Borderlands 3 but with the compat tool switched to Proton Experimental, but since you've said you're concerned about compatibility between versions, only do this if you've backed up the saved games and compatdata first - and this is a lower priority than the other things I asked for in this comment. |
|
I think I have a solution for #517, #518, and the Wonderlands/GE-Proton7-20 and Witcheye/Proton Experimental parts of this issue, which will go through more testing and review next week. The same change might also solve your Borderlands 3/Proton-5.21-GE-1 scenario, but I don't yet understand what is different in that scenario, so the only way to find out is to try it... If you are comfortable with testing unreleased software, you can try it out as follows:
It would be useful if you could share a debug log recorded with this test version, especially if it doesn't work. The same procedure you used to get your Witcheye log is suitable. |
Howdy, sure thing, here's Witcheye + Interestingly, Witcheye fails in the same way that it did on Proton 7 + Proton Experimental: it launches but various assets of the game don't load in, and it gets stuck on a loading screen before the main menu.
Here 'tis: BL3 + I actually don't see that "Failed to execute child process" on the console when grabbing the logs this way, but that is present down at the bottom of the log.
Sure thing! It looks like that build actually probably does the trick, both for the weirder 5.21-GE that I was using, and for Proton Experimental: Witcheye + I'll stick with that for the time being and let you know if I run into any further issues. |
Great, that's what I was hoping. The fix for this should be in the next beta. If you stay on the
Witcheye and Wonderlands seem to be the same root cause as #518: the regression involving symlinks results in the Steamworks API failing to load. Different games have different symptoms when the Steamworks API is missing or broken: some fail completely (e.g. if they do a license check against Steam, like #518), some run with reduced functionality, and some are unaffected because they don't use the Steamworks API for anything important (or at all).
That's normal: enabling the logging mechanism captures everything that would previously have gone to the terminal where you ran Steam, from the container setup code or any component below it (including Proton and the game), so that we get all the necessary information in one place and in the correct order. |
Looking at your BL3 logs, there is indeed something different going on here, which is not the same as the other games (or the other users with different versions of this regression). Witcheye and Wonderlands are working the way they are meant to. We can see Steam telling the container runtime which compatibility tool you have asked it to use: pressure-vessel is meant to make sure these end up visible in the container, even if they are outside your home directory, outside your default Steam game library and so on, so that Proton can work. The regression that you reported was partially breaking this, but in general it works. But for BL3, some of these are set to empty values: I think this is why you saw a different, worse failure mode for this regression with BL3 (Proton not found) than for the other two games you tried (Proton works correctly, but Steamworks API not found). pressure-vessel takes all the compatibility tools that it is told about and makes them available in the container; but that didn't work for BL3, because when running BL3, it was not told that they exist, so it didn't know that it needs to look for them. When pressure-vessel is working correctly (after fixing the regression), it happens to work in your specific case, because your Proton 5.21 compat tool happens to be installed in Is this something you have configured yourself, for example by putting Or is Borderlands 3 special in some way, like perhaps being a non-Steam game that you have copied into a Steam directory, or some other special property that isn't true for Wonderlands and Witcheye? |
This has gone out in SteamLinuxRuntime_soldier build ID 9200891. Specifically, what you want to see in This version should be a full solution for the failure to start Wonderlands and Witcheye. I am still waiting for more information about what is different about Borderlands 3 in your setup: that part is not 100% solved, but the updated runtime will work around it in practice. |
Yeah, sorry about that! Haven't had an opportunity to look into this any more -- it might be until the weekend before I'm able to give it another go. I'll let you know what I find, though! |
No problem. I'm confident that the main practical problem here is solved, but I'd prefer to get a better idea of what's happening with BL3 in your logs before closing the issue, in case it's something important that will break for other people. |
This version has now been promoted to the default branch, and no longer requires using a beta. Let's leave this issue open until we have a better understanding of what's going on with the empty |
|
Hello! Apologies for the radio silence on my end; Real Life's been busy. Anyway, I thought I'd had a few things on my plate to try, but I see really all you wanted was some info on the game's install, etc. There wouldn't've been anything funky about the game install itself -- that was just done via Steam as usual. There's no launch options set for the game, either:
Now that I've looked a bit more closely at those
Both games are still working fine, on the latest SLR-soldier. Let me know if there's something else I can dig into here! Edit: could that GE build be doing game-specific fixes itself? Maybe that's the culprit here... In the end, I was thinking about getting this prefix upgraded to something more current anyway (be it a Steam-provided Proton or a more current GE). I could go ahead and pull the trigger on that, if you'd like that datapoint. I'll leave it for the time being, in case there's something specific you'd like me to poke at with the current config. |
This seems quite mysterious. @TTimo, do you know of anything inside Steam itself that could make it set
I don't see how it could have this effect even if it wanted to. The way this works is that Steam runs SLR_soldier, and tells SLR_soldier to run Proton (Proton-GE in your case) inside the container. At the time we run the SLR_soldier entry point, Proton has not yet had an opportunity to mess with the environment. You can see this at the top of your log: the SLR_soldier entry point was run as which means "start the container, and then inside the container, run (In any case there is no reason why Proton-GE would want to clear out the values of those variables: interfering with the communication channel between Steam and SLR_soldier is only going to break games, and won't fix them.) |
|
Those environment variables will be empty if Proton-GE does not enable session mode in it's |
|
You may be able to workaround the issue in Proton-GE by settings |
Hm, looks like that is set in that file, btw. And I was using the same GE install for Witcheye, which does have those vars:
Looks like that didn't change anything, btw, apart from that env var showing up in the log output. Here's a timestamp-and-PID-stripped version of the log (for easier diffing with the previous ones, if you like) - https://gist.github.com/4a253854a27bdd5393f5e4f8b6a1a8fb (And just to clarify: the game's working just fine for me -- the absence of those vars doesn't seem to be causing any apparent issues ATM.) |
I think we want the Steam client to set |
How exactly did you set this environment variable? I ask because setting it in Launch Options probably will not work. Because it alters the behaviour of the Steam client, it needs to be in the Steam client's execution environment, more like this:
It's working fine for you because you happen to have your Proton-GE build installed inside the Steam installation root (the directory that My concern is that if someone was in almost your situation, but using an official build of Proton, and they had configured a custom Steam library like |
It's still a mystery to me why BL3 and Witcheye are behaving differently here, with what ought to be the same settings. |
Indeed -- I'd launched like so: Not exactly the same as using |
Thanks. It looked like an easy possibility for those to not get set when I had a look in the Steam client code, so I wanted to make sure. |
Yes they are, and the way you tried is fine. |
|
Hm, complicating matters slightly here is that an update was just pushed to Borderlands 3 today, and now the game appears to not launch for me. Whether that's got something to do with the weirdness we've been looking into or something screwy with the update (or perhaps some new, hitherto unnoticed issue with my setup) I couldn't say. I'd been keeping the game installed with that old GE-5.21 install in case there was anything else you wanted me to check out, but I could always go ahead and move that over to using something more modern, to see if that'd clear this new problem up for me. (Wonderlands and Witcheye continue to launch just fine for me.) The behavior at launch now, btw, is that I get a little Windows dialog saying "Steam must be running in order to launch this game. Please restart the game after starting the Steam client." Then once I hit "OK" on that, I get a brief splash screen for the game and it exits. So the game can't find Steam, apparently. Here's a fresh SLR log, once again stripped of timestamps + pids, for easier diffing (I should maybe add in something to normalize the tempdir names so that those don't show up in diffs, too...): https://gist.github.com/b338c6f28ba04ec3ef815805a3410bc2 Not much stands out to me in there -- it looks basically just like my previous BL3 launch logs. The one difference which I did see was this, near the very end: --- slr-bl3-app397540-t20220805T140010.log 2022-08-18 12:02:23.530545540 -0500
+++ slr-bl3-post_patch_no_launch-app397540-t20220818T120025.log 2022-08-18 12:02:23.600544859 -0500
-Loading Library: Z:/games/bl3_steam/games/steamapps/common/Borderlands 3/Engine/Binaries/ThirdParty/Steamworks/Steamv147/Win64/steam_api64.dll
+Loading Library: Z:/games/bl3_steam/games/steamapps/common/Borderlands 3/Engine/Binaries/ThirdParty/Steamworks/Steamv154/Win64/steam_api64.dll
+Loading Library: C:\windows\system32\winex11.drv... so they've bumped up their Anyway, I bring it up in case it turns out to be important anyway. Cheers! |
|
Okay, well, I ended up biting the bullet and upgrading BL3 to a newer Proton (just used the same one I'd been using for Wonderlands, for simplicity's sake), since I maintain various modding things for BL3 and wanted to be able to launch it. Bringing that up to GE Proton-7.20 did let the game launch properly again, but interestingly, it still does not have those two environment variables specified -- Here's my last failed launch from 5.21, stripped out for diffs: https://gist.github.com/19152a0fc9766b6fcf9205ed115c14d4 As before, nothing really pops out at me, apart from those vars being mysteriously blank for BL3. I'll give it a go on an actually official Proton within the next day or two here. |
|
Okay, and odder still, I did try this on Proton Experimental tonight as well, and even in that environment, it seems BL3's missing those env vars: https://gist.github.com/0b7e36fd7873bf86d348e77cf5b81f2e |
|
In case you are still running into this, the next steam beta update has a change that may fix the problem. Would be curious to know if that helped. |
|
Closing pending feedback. |
Your system information
SteamLinuxRuntime/VERSIONS.txt? n/aSteamLinuxRuntime_soldier/VERSIONS.txt?#Name Version Runtime Runtime_Version Comment
depot 0.20220629.59 # Overall version number
pressure-vessel 0.20220624.0
scripts v0.20220620.0-0-g22dad8e # Entry point scripts, etc.
soldier 0.20220628.0 soldier 0.20220628.0 # soldier_platform_0.20220628.0/
Please describe your issue in as much detail as possible:
Steam installed a new Steam Linux Runtime for me today (Build ID: 9027669), and I'm unable to launch either Borderlands 3 or Tiny Tina's Wonderlands (the only two games installed on this root). There's a different error with each (and they each use a different GE Proton), but with similar errors: essentially complaining about not finding files which are, nevertheless, on the system. For Wonderlands, I think the game itself launches, but it shows a dialog saying "Unable to initialize SteamAPI - Please make sure Steam is running and you are logged in to an account entitled to the game," and the following shows up on the console:
That file does, indeed, exist, though:
Borderlands 3, in contrast, doesn't launch at all, with the following showing up on the console:
As with
steamclient.soabove, that file does exist:This behavior happens with the
client_betabranch of Steam Linux Runtime as well (Build ID: 9157627), but I can revert to theprevious_releasebranch (Build ID: 8860828) and launch both games just fine without problems. (They were also working fine ~12 hours ago, before that Steam Linux Runtime upgrade happened.)Debug logs as per
reporting-steamlinuxruntime-bugs.md: https://gist.github.com/30a62ace83342519a92aa91da6f20dd5Steps for reproducing this issue:
The text was updated successfully, but these errors were encountered: