Steamuxulation redux

This is not really "fixable" (it's not a bug in the first place) unless you update all glibc libs in-place.
 
This is not really "fixable" (it's not a bug in the first place) unless you update all glibc libs in-place.
Right, bad wording, I realize it's not a bug. So is there a recommended way to update glibc, considering there is no linux-c8 port yet? I found a forum post where someone suggests copying it from centos8 and booting with newer linux newer kernel (that's available in fbsd13 current apparently). That sounds like it might break things...

Does/can libc6-shim help with this?

Any advice is appreciated. Thank you :)
 
Regarding the wine64 segfaults reported earlier in the thread, I'm seeing the same thing on -CURRENT with the binary wine-proton packages (both amd64 and i386) and with amd64 wine-proton compiled from ports.

gdb shows that we're crashing in __wine_process_init() in ntdll when attempting to access some TLS item. Only one thread exists at the time of the crash. %gs is not initialized with amd64_set_gsbase(), so we end up trying to dereference 0x30. ntdll's signal_init_thread() isn't getting called, which means that __wine_main() isn't getting called. Indeed, wine_init() is calling __wine_process_init() after loading the ntdll SO.

... and while writing that I see the problem. load_ntdll() is busted if procfs is not mounted. So, if you're seeing wine segfaults, make sure to run

# mount -t procfs none /proc

and update /etc/fstab.
 
So is there a recommended way to update glibc, considering there is no linux-c8 port yet? I found a forum post where someone suggests copying it from centos8 and booting with newer linux newer kernel (that's available in fbsd13 current apparently). That sounds like it might break things...
This is relatively safe, however you must replace all glibc libraries (ld-linux.so, libc.so, libm.so, libpthread.so and so on) simultaneously, they have internal dependencies.

Does/can libc6-shim help with this?
No.
 
Hello,

I've updated to FreeBSD 13. Steam and all the games that worked in 12, continue to work.

I tried a few new games that I got, both Unity, where the grey Unity logo comes up on launch, but then it exits out. The games are Crazy Cars (demo) and Monument (on sale until May 10th for 50 cents). I've attached logs for both.

Anything can be done to make these work or are they just not compatible with FreeBSD? Or something I'm missing on my system? Thank you for any advice.
 

Attachments

LD_PRELOAD=${LD_PRELOAD}:monofix.so %command%
Cool, thank you! Monument works :)

Crazy Cars gets a bit further; it passes the Unity splash screen but then freezes on the first image after that and the music starts playing. But at this point, no menu comes up and I need to kill the process to get out of it. Log looks interesting, but I'm not sure how to solve it. Let me know what you think.
 

Attachments

Crazy Cars gets a bit further; it passes the Unity splash screen but then freezes on the first image after that and the music starts playing. But at this point, no menu comes up and I need to kill the process to get out of it. Log looks interesting, but I'm not sure how to solve it. Let me know what you think.
"Curl error 7: Failed to connect to cdp.cloud.unity3d.com port 443: Connection refused" indicates it might benefit from pathfix.so as well. Also, the game is called Crazy Wheels.
 
OK, added the pathfix.so as well, still crashes the same way as before. Attaching new log just incase, but the error at the end looks the same:

Code:
Native stacktrace:

    /usr/home/scratchi/.steam/steam/steamapps/common/Crazy Wheels Demo/CrazyWheelsDemo/CrazyWheelsDemo_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so(+0xd805c) [0x80d6d805c]
    /usr/home/scratchi/.steam/steam/steamapps/common/Crazy Wheels Demo/CrazyWheelsDemo/CrazyWheelsDemo_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so(+0x5bdff) [0x80d65bdff]
    [0x7ffffffff514]

Debug info from gdb:

mono_gdb_render_native_backtraces not supported on this platform, unable to find gdb or lldb
Obtained 1 stack frames.
#0  0x007ffffffff514 in (Unknown)

Please let me know if you have any more suggestions. Thanks for all your help with this.
 

Attachments

Hello! I might need some help getting things to run. FreeBSD12.2, nvidia with driver 460, followed the steps on the github thing to get everything installed. I am trying to start Skyrim / Skyrim SE but the first results in error=234 (game directory not found) a couple of times and then finally quits with the words "missing .INI, reinstall Skyrim". The latter exhibits the same 234 errors but displays the launcher whatsoever. Using monofix.so the button "Play" becomes clickable (else a "no audio device" error prevents launching) but after a brief flash of black on the screen, the game disappears. Other games I have tried also don't work. I am now downloading Portal 2 which is the only small-ish game that I have from the Compatibility list. I have no idea which log files someone in here might need so please do request them! Thank you.

EDIT: Portal 2 definitely does some stuff (meaning it creates a window and does not immediately crash) however the window is just a transparent outline. This might be due to my window manager (suckless dwm). Force-selecting the installed proton as compat causes the same "flash" behaviour. Any idea how this can be troubleshooted?
 

Attachments

  • 2021-05-04-234749_1656x988_scrot.png
    2021-05-04-234749_1656x988_scrot.png
    196.4 KB · Views: 252
Rochard works. It's marked as broken on wiki and the note says it needs to be tested with monofix; but it works for me without monofix or any additional launch options.

No suggestions. I don't think I want to debug it.
That's fine, thanks for all the help provided to this point. Just an FYI, I'm also trying Bloody Rally Show Prologue and it fails the same way and also throws errors about libmonobdwgc-2.0.so. In this game, I even get the main menu; but then it crashes when I try to start a race. I'll poke around some more and post back if I get it working.

Thank you
 
I am trying to start Skyrim / Skyrim SE but the first results in error=234 (game directory not found) a couple of times and then finally quits with the words "missing .INI, reinstall Skyrim". The latter exhibits the same 234 errors but displays the launcher whatsoever.
That's a Windows game. How exactly are you starting it?

Using monofix.so the button "Play" becomes clickable (else a "no audio device" error prevents launching)
Nah, monofix.so definitely doesn't work with our Proton hack. It simply won't be loaded at all.

EDIT: Portal 2 definitely does some stuff (meaning it creates a window and does not immediately crash) however the window is just a transparent outline.
Linux or Windows Portal 2?
 
That's a Windows game. How exactly are you starting it?
Using freebsd-proton configured using the scripts from your git https://github.com/shkhln/linuxulator-steam-utils
Linux or Windows Portal 2?
I have tried both. Linux opens a window (as seen in the screen from my previous post) but then the game does not start. Windows (using the previously mentioned proton install) starts and immediately closes.

Should I not be using freebsd-proton but linux-proton? I was under the impression that the utils would install a working proton for running windows-pe. Please correct me if that is wrong.
 
Skyrim is not exactly known for being a bug free game. For what it's worth, Fallout New Vegas has the same launcher complaints, but starts anyway. See if there is anything useful at https://github.com/ValveSoftware/Proton/issues/460. Also please check the console output, "screen flashes" doesn't tell me much.

I have tried both. Linux opens a window (as seen in the screen from my previous post) but then the game does not start. Windows (using the previously mentioned proton install) starts and immediately closes.
If you pay attention to the console you should see that Windows version of Portal 2 exits on an assertion check in the glibc shim library we are using. This is being worked on.
 
Linux opens a window (as seen in the screen from my previous post) but then the game does not start.
I was testing Linux Portal 2 with Haswell's HD Graphics 4600 yesterday and there it hangs on startup 3 times in a row, each time requiring ctrl+c in the terminal to proceed. (Don't ask me what it is, I don't know. It's an incredibly odd issue.)
 
First you need install proton, open utils and do 3 steps: p1,p2,p3

High Octane Drift (Free game):

Pro Evolution Soccer 2020 (Free, Lite)

How to configure resolution (if you want play in fullscreen mode):
1. Download file settings.dat
https://drive.google.com/file/d/1pWQ9QYvuQU_mBpSeCdpgkDLvYYxmwkRy/view?usp=sharing
2. Copy this file: cp ~/Downloads/settings.dat ~/.steam/steam/steamapps/compatdata/996470/pfx/drive_c/users/steamuser/'My Documents'/KONAMI/'eFootball PES 2020 LITE'/settings.dat
Also yo can read: https://wiki.sgripon.net/doku.php/r...9_in_fullscreen_mode_on_steam_on_ubuntu_linux

Painkiller overdose (Free demo)

--- SteamBSD © is FREE operating system.
YouTube: https://www.youtube.com/channel/UC8wwRY8yGWiJ-bIQlK0wvUA
Site (download ISO/IMG): https://lpros.blogspot.com
Github (internet installer): https://github.com/steambsd/os
Email: steambsd@gmail.com
 
Last edited:
Hello,

Seems like Steam can't connect to the central, it hangs on login.
First run executed ok, then after the code verification, main window disappears, tray icon still there. On clicking of tray icon's options like store or library, error message that URI is not yet ready pops up in the terminal.

Ctrl-C and again, now the Connecting Steam account window just hangs there.

This is the output


.
.
.
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
src/clientdll/appdatacache.cpp (2679) : Assertion Failed: !bSharedKVSymbols
Warning: failed to set thread priority: set failed for -10: -1: setpriority() failed
Warning: failed to set thread priority: set failed for -10: -1: setpriority() failed



After a while this comes up


[2021-07-07 03:57:06] Background update loop checking for update. . .
[2021-07-07 03:57:06] Checking for available updates...
[2021-07-07 03:57:06] Downloading manifest: https://cdn.akamai.steamstatic.com/client/steam_client_ubuntu12
Installing breakpad exception handler for appid(steam)/version(1623193086)
[2021-07-07 03:57:07] Download skipped: /client/steam_client_ubuntu12 version 1623193086, installed version 1623193086, existing pending version 0
[2021-07-07 03:57:07] Nothing to do


So Steam is actually alive but the connection thread is hanging? I can try to truss it and see where it's blocking, but wondered if someone maybe has a solution at hand.

13.0-RELEASE-p1 FreeBSD 13.0-RELEASE-p1 #0: Wed May 26 22:15:09 UTC 2021
All lastest packages, nVidia GLX

And as I'm writing this, after a few minutes "Updating User Configuration" is on the window, stdout/err gets flooded by another batch of bSharedKVSymbols error and it's just hanging there.
 
I noticed that, too, I was not able to play anything, I'm on 12.2-RELEASE-p8. So when will this be fixed more or less and what do we have to do when the time comes? A pkg upgrade and that'll be it?
 
I'm on 13.0 and had the same problem a week or two ago. I use shkhln's github repo instead of port/pkg, a quick git pull, make, make install fixed the issue for me :)
 
It takes 4-5 days for the official ports to get built. Any time now.
In fact the 13 i386 quarterly repo was already synchronized 24+ hours ago, while amd64 still isn't despite the second build for the new quarterly branch being started already (which means those syncs are probably going to compete for the network bandwidth). This whole process is really quite broken in practice.
 
Back
Top