Steam: Easy Anti-Cheat does not work under Void #41388
Comments
Cynosphere
added
bug
|
For comment 2, if you go further, you will see that the issue was that while I was testing with a patched glibc I wasn't using a patched glibc-32bit (hence why it wasn't working). I tested with Multiversus right now and that works for me. You can try (You can use |
|
No change, I don't think I ever had a local build of glibc as this install has only existed since October and I've had no reason to touch glibc. |
|
When did you first run into this issue and was it working for you before the glibc 2.36 update? |
|
November 19th is when I first tried to run a game using EAC, which if I'm correct was before 2.36 and it was not working then either. |
|
Did you try following |
|
Already had the needed 32bit packages, none of the troubleshooting steps made any changes. |
|
Can you join #voidlinux on irc/matrix? |
|
Joined on IRC |
|
I can confirm that Apex Legends doesn't work. I can also confirm that DT_HASH is present in glibc so it shouldn't be related to that. As a workaround flatpak should work. |
|
I do hope someone does attempt to find the actual cause of the issue instead of leaving it to die on the hill of "just use flatpak". |
|
You can try using |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
When running it with proton 6.3: When using proton experimental: I'll see if I can find anything from the strace output. Edit: I am not getting the hash catalogue error when using |
|
Hello, have same troubles here, on Void too, can't play apex or vrchat, I can play Elden Ring but in offline only. I also want to report that EAC isn't the only thing acting strange on Void, steamvr is too (and quick note, yes it do work in flatpak. Thanks for reminding me, i totally forgot steam flatpak existed. But while it's a great workaround, it still suck that it just dont work by default) |
|
reopening because this is not fixed |
|
Actually the issue seems to be the compination of eac and our glibc, did setup a quick chroot and changing the glibc to the one from arch satisfies eac, using the void one doesn't 🤷 |
|
what is very strange is that:
and that so in both case its broken |
|
I've read through some of the links on this page and, transitively, an essay at https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash that leaves me wondering:
|
I assume you are referring to:
Carlos later said:
Carlos added a temporary revert for DT_HASH in Fedora: |
|
I'm referring to the fact that the upstream issue at https://sourceware.org/bugzilla/show_bug.cgi?id=29456 remains open and unassigned five months after it was reported. Whether other distributions carry a patch to revert the change is irrelevant here. Void favors upstream decisions and eschews patches unless they are backports of upstream changes or fix issues introduced specifically by our packaging. This is neither. Upstream made a change to drop support for DT_HASH and continues to stand by it. We should be uninterested in fixing this problem until either upstream reverts the patch (in which case we can backport it if we don't want to wait for the next release) or EAC is fixed to support the glibc change (in which case the problem goes away entirely). This is not our problem to fix. |
This issue isn't caused because support for DT_HASH was dropped though; as other comments indicate, Easy Anti Cheat has been broken on Void since at least glibc 2.32. After all, the current glibc package does contain this patch and yet EAC is still broken. IOW, discussion about this patch is off-topic and would be better suited in a separate issue IMO. I'm posting this mainly because as a user your comment (being the last one in the chain) made me think that the issue is related to the glibc 2.36 update, when it isn't actually. This discouraged me from attempting to troubleshoot it on my own, which seems counter-productive to me (although admittedly I didn't get very far when I did try troubleshooting on my own). This is significant, as currently Void is the only distribution I am aware of in which EAC is broken despite the aforementioned patch being applied. In any case, I would very much like to see this issue fixed, and I would be glad to help with any testing (I own Elden Ring and Fall Guys on Steam, both of which use EAC unfortunately). BTW, I don't use the Steam Flatpak since I also use Steam as a launcher for emulated games - setting this up is very complicated with the Flatpak version (Flatpak in general is way too complicated IMO, so I'd prefer to avoid it if possible). |
This comment was marked as spam.
This comment was marked as spam.
|
The example above is incomplete, sorry should have clarified that better... You should get the full command from steam the same as Tyfuzzle did above (steam used to print the command it used to launch the game but doesn't now) The goal is to call the same command as steam would by default with the Linux runtime removed For example on my system the full command for vrchat is |
|
Ohhhh, yeah that would explain it, what does the last |
im not sure what the # do but the %command% tell steam its a command that need to be run before launching the game and not arguments to pass to the game executable |
|
It's what makes the original command from steam a shell comment as a way to deactivate it It's explained on the archwiki |
|
YOOOOOOOOOOOOOOOOOOOOOOOOO It finally worked! Im gonna poke around with it a bit more, and if all is well i'll have a decent script that can launch stuff and not make EAC crash! And i guess we can narrow this issue down to the linux sniper runtime that steam ships, the |
|
Correction, Insurgency still does not work, however VRChat does? But only when launched using Script that i used to test looks like this #!/bin/bash
STEAM_PATH="$HOME/.local/share/Steam/ubuntu12_32"
PROTON_PATH="$HOME/.local/share/Steam/steamapps/common/Proton - Experimental"
APP_BIN=$2
APP_ID=$1
echo Launching \'$APP_BIN\' AppId=$APP_ID without _v2-entry-point...
echo
$STEAM_PATH/reaper SteamLaunch AppId=$APP_ID -- $STEAM_PATH/steam-launch-wrapper -- "$PROTON_PATH"/proton waitforexitandrun $APP_BINVRChat works fine if i launch it like this However Insurgency does not work fine if i launch it in a similar fashion |
be sure to launch the executable steam launch, there's high chance its actualy a "start protected.exe" or something like that (its the case on multiple eac game afaik) |
|
Well for Insurgency there are only two exe's, and the other one just doesn't work :/ |
|
Huh, well for Insurgency, the command that Steam uses is this And that exe does not seem to want to launch without |
|
And for those wondering to see the launch command of any game put this into the launch options |
I guess that makes sense since we're launching the game outside the expected runtime, so there's only a chance that a game will run outside of it. After I get home, I'll try to sus out why the entry point is making eac panic, closest I got is that the |
|
Leaving out the runtime works for Halo Infinite as well! |
|
The fix was working for me last week on Halo MCC. Went back to it today and now I'm getting some EAC violation about an unknown file version. I think it might be more to do with Halo MCC than Void. I've seen threads about the same error from Windows users. |
|
@fishslips sure, look at all the info gathered so far, gather any info you have ideas about, and try to figure out what the problem is, just like everyone else. |
|
Okay, so I did a proton log for the flatpak version of steam running The Finals which uses EAC as well as our xbps package for steam. In both instances, anticheatlauncher.log in the prefix folder for the finals basically says Easy Anti-Cheat successfully loaded in-game, successfully initialized. There was no difference in the log for EAC when running in flatpak or xbps package. Both proton logs are fairly similar except for a few differences here and there (had to cut off most of the beginning of the files because it was over 100k lines), and mostly notably the end . The flatpak version continues as normal and it looks like Discovery.exe gets launched (pretty sure that's the exe for The Finals). Whereas the package version does not, renames some threads , says pids don't match, and it just abruptly stops. So I think EAC starting/running, it's something that happens during the hand off when the app itself tries to launch. Idk how helpful this is, again I'm new to Linux and trying to learn as much as I can so I can contribute. Lmk if this is useless information or not. |
|
TL;DR: For now After a day of mindless tracing, i was able to finally come to the cause of the issue. In short i used
I will try to sum it up in short and hopefully in a way that make sense. (let me know if something's unclear) The crashIt turned out that the root of the issue was right when starting the game executable, specifically with eac bundled with the apps executable. When you start VRChat non-runtime or on Arch Linux, the trace of the all VRChat.exe
This is the very start of VRChat.exe's execution, it loads it's dependencies and a file But when VRChat is started on Void (in-runtime): There are two differences, VRChat.exe fails to find locales (fd that equals -1 means file not found) instead of loading the As far as i can tell failing to find the locales causes eac to silently die on the app side. (when launching at least) This then probably tricks the app into thinking eac was never launched judging by the wording of the error in VRChats logs which sounds more "anti-cheat not found" than "anti-cheat triggered" The reason why VRChat.exe does not load Thankfully after defining I'm not sure which part of the stack (Void, Steam Runtime or eac) is to blame here or why, it might be steam if the So yeah, i don't know if i fell better or worse by knowing that a character conversion lib was to blame this whole time! The timeout (extra info)This is extra information not needed for the main explainer.VRChat itself is made by three executable files: When VRChat launches, first launch.exe is started and the eac service/driver loads, this is the file that shows you the eac loading screen. start_protected.exe and VRChat.exe are then started by launch.exe after eac fully loads. (VRChat.exe is the actual unity executable and start_protected.exe is also a part of eac, probably) When the start_protected.exe is started, it waits for a creation of a file at successful start from non-runtime trace and from an Arch Linux trace watching the eac file: (trimmed down) But on Void this file is never created and start_protected.exe "times out", which probably leaves eac in a confused state: This might also be cause of the final eac failure instead of eac dying when starting VRChat.exe but in any way is the root cause is eac dying when stating VRChat.exe. |
|
Amazing work |
Works for Halo Infinite as well, great work! |
|
Thank you for looking in to this. Our default gconv path is Apparently this is because the |
|
Wouldn't a simple symlink also solve this? nvm me, i didn't think about this |
|
|
The pressure-vessel container exposes the host filesystem through |
|
Great job @caszuu ! Adding |
|
Also prob worth tagging @kisak-valve, looks like there will have to be a patch for the env setup script, its either picking up gconv path wrong or the symlink is not working |
Don't tag them here, instead an issue should be made on the steam linux runtime gitlab/github (which I can do later). |
hmm i still wonder if But at the same time VRC never even checked for the existence of gconv modules without |
It is not supposed to be symlinked and the folders not being symlinked is intentional. The issue is that the 64-bit gconv modules are being mounted to
VRC isn't checking for gconv modules, glibc is through the |
Please do |
|
This only seems to somewhat fix it for me, when trying to play elden ring for example, I now get past the "inapropriate activity", but when trying to log in I get "Connection to epic online services failed: 01-00000", but that might just be a wholy independent issue. edit: |
and others
Is this a new report?
Yes
System Info
Void 6.0.15_1 x86_64 AuthenticAMD notuptodate FFFFFFFF
Package(s) Affected
steam-1.0.0.75_2 (theoretical)
Does a report exist for this bug with the project's home (upstream) and/or another distro?
ValveSoftware/Proton#1199 (comment)
#34902 (comment)
ValveSoftware/Proton#6051
Expected behaviour
Games using Easy Anti-Cheat run fine.
Actual behaviour
Games using Easy Anti-Cheat seem to not initialize Easy Anti-Cheat properly.
Steps to reproduce
VRChat:
Apex Legends:
The text was updated successfully, but these errors were encountered: