void-linux
Steam: Easy Anti-Cheat does not work under Void
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?
https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1368284488 https://github.com/void-linux/void-packages/pull/34902#issuecomment-1255715853 https://github.com/ValveSoftware/Proton/issues/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:
- Launch game through Steam
- Login if fresh install
- Be greeted with "Can't Travel" screen explaining Easy Anti-Cheat hasn't been initialized.
Apex Legends:
- Launch game through Steam
- Wait to get to the main menu
- Be greeted with Engine Error message box saying "Easy Anti-Cheat Hash Catalogue not found"
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 xbps-install -Sf glibc glibc-32bit to make sure you are using the version from the repos and not an old local build.
(You can use xpkg -L to list which packages are installed locally as opposed to from a repo)
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.
Already had the needed 32bit packages, none of the troubleshooting steps made any changes.
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.
This can be confirmed using:
readelf -e /usr/lib/libc.so.6
readelf -e /usr/lib32/libc.so.6
Both have .gnu.hash and .hash.
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 strace -f to see where it exits? (you would probably want to edit the launch script or add it as launch args)
I'm genuinely just tired of being thrown round and round into troubleshooting circles at this point. I don't care anymore.
I'm tired of how the greater FOSS, Linux and whatnot community as a whole treats people that it's infuriating at this point.
It just genuinely comes off as "just use X because we don't want to spend time and effort into fixing Y because Y is proprietary" and its this elitism that annoys me the most.
So whatever. If someone cares to fix this in the future, cool. But I'm not going to sit here just wasting time being thrown in an endless loop of "try this, try this, try this" or "just use this instead".
Sorry I wasted your time, as per usual that it seems to be with me trying to interact with anything on GitHub...
When running it with proton 6.3:
I found logs at $HOME/.local/share/Steam/steamapps/compatdata/1172470/pfx/dosdevices/c:/users/steamuser/AppData/Roaming/EasyAntiCheat
It shows the following error Connect result: Couldn't resolve host name (6) Response Code: 0 Destination IP: Unavailable
When using proton experimental:
The logs here indicate no error (although the "Easy Anti-Cheat Hash Catalogue not found" error still show up when trying to start the game).
There are also logs generated at ~/.cache/com.epicgames.easyanticheat/154 when using proton expiremental which also indicate no error.
I'll see if I can find anything from the strace output.
Edit: I am not getting the hash catalogue error when using strace -f (and EAC isn't working) so maybe it is detecting that?
Hello, have same troubles here, on Void too, can't play apex or vrchat, I can play Elden Ring but in offline only. For Apex replacing the EAC dll/so by the one present in the proton EAC runtime make the game goes past the "Easy Anti-Cheat Hash Catalogue not found", launching properly, accessing to the loby and all, but after a while it'll kick you out saying that EAC isn't running.
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)
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 :shrug:
what is very strange is that:
- I was using glibc 2.32 until now (which isnt a version of glibc known for troubles with EAC afaik)
- I just upgraded to 2.36, which is known to be problematic but that seems to be patched: https://github.com/void-linux/void-packages/tree/master/srcpkgs/glibc/patches
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:
- Why we carry a patch attempting to revert the linker change contrary to our usual deference to upstream. They have been aware of this problem for months and are apparently uninterested in the issue or reverting the change.
- Why this issue isn't closed as WONTFIX with a note that EAC needs to fix its shit. The patch doesn't fix Void-packaged software, it fixes proprietary software fetched optionally by one of our packages. Furthermore, as already noted, there are alternatives like flatpak while people bother the EAC people to fix what broke.
Why we carry a patch attempting to revert the linker change contrary to our usual deference to upstream. They have been aware of this problem for months and are apparently uninterested in the issue or reverting the change.
I assume you are referring to: https://sourceware.org/pipermail/libc-alpha/2022-August/141304.html
At present I would not make any changes to glibc. I would close bug 29456 as RESOLVED/WONTFIX. I'm open to hearing from the EPIC EAC developers if they have a case to make about DT_HASH.
Carlos later said: https://sourceware.org/pipermail/libc-alpha/2022-September/142353.html
The fix is available in version 1.15.2 of the EOS SDK and in the new corresponding version of the anti-cheat module. This was released in August.
Fixing this issue though requires several steps that need to be taken by the developers of the game itself. ... Looking across the distributions some of them are carrying a revert that adds back DT_HASH. Therefore I think it would help the distributions and add back DT_HASH support for a longer period of time before final removal.
I don't think this will solve all the problems, but I will work to test out the revert on my Fedora system.
Carlos added a temporary revert for DT_HASH in Fedora: https://src.fedoraproject.org/rpms/glibc/c/a9713abfbd4db4350fbc201e4d5cd6ddc36cfd27?branch=f37
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.
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).
small update on my end, especially about https://github.com/void-linux/void-packages/issues/41388#issuecomment-1369014128 steamvr was probably not a void issue, just steamvr breaking up on some specific configuration im guessing. I was able to run just fine last public release, use it with alvr, get in vr, even launch vrchat without any troubles. Tho so vrchat dont run properly because EAC is still broken unfortunately :v (also no steamflatpak its actually complicated as of now for VR, especially on nvidia)
bumping @oreo639
Were you or another member of the Void team able to find any leads on this? I've found the "Hash catalogue not found" error to be present in Dead by Daylight as well. Fall Guys works without any issues though.
soo i have multiple EAC games, most (if not all; didn't check them all lately) of which don't run (for years now, so pretty sure not DT_HASH related) despite everyone telling me they should, the fact that steamflatpak seems to help some people points at some other library being borked but i'm not sure how to investigate further, please someone tell me if i can help figure this out finally? am happy to do a bunch of tests and provide logs and whathaveya, just no idea where to start (given anticheat stuff is a black box by design) and wish this worked for once :(
While search for information on this issue, i stumble upon this discussion in the Gentoo forum which is marked as solved. https://forums.gentoo.org/viewtopic-p-8703494.html?sid=92410f4f29b13814bbf566faa6d38886#8703494
I've seen that this is a bit older and i don't have enough experience to see if this might help or is relevant at all anymore. I tried to add this patch and build locally but this either didn't work or i just did it wrong.
@Requion pretty sure that's about the .hash/.gnu.hash sections @oreo639 already ruled out as a potential cause.
Btw, just I removed the patch since I couldn't figure out how to make EAC work regardless of what flags I used and I am not aware of anything fixed by the DT_HASH patch (since most EAC games don't work with Void's glibc regardless. Feel free to let me know if there are breakages after upgrading glibc, e.g. worked before updating but not afterwords).
If you still want to test with DT_HASH enabled you can enable it by copying these two lines before the make call in do_buld() in the glibc template (keep in mind that EAC checks both the 64-bit and 32-bit glibcs):
https://src.fedoraproject.org/rpms/glibc/blob/ca9e6ac79501d9ee8eeaf795c5764d8733534910/f/glibc.spec#_1219
Were you or another member of the Void team able to find any leads on this?
Just to clarify, I am just a contributor and not a part of the void-team organization. Also, I couldn't figure out what the issue was, only that it is related to glibc and not some other library (as demonstrated by Johnnynator).
I have tried intermittently to fix this myself by getting the configure arguments as close to those on Arch and Fedora as possible (as well as numerous other changes) and this hasn't worked.
As Johnnynator said previously, EAC works as expected if you use the build from Arch Linux. There is a problem with Void's build of glibc that is not present on other distributions.
Given that no progress has been made in the year since this issue has been opened, and that those affected stand basically 0 chance of resolving this on their own, is it possible to reach out to knowledgeable glibc maintainers from other distributions to shed some light on this problem?
It's good that users can circumvent this problem using flatpak or another distribution's glibc, but this is far from ideal.
EDIT: in case this goes anywhere, the one interesting thing I found that is not already mentioned is that arch's libc.so.6 has a .gnu_debuglink section while void's does not. void also has a .plt.got section while arch has a .plt.sec section.
Well, updating glibc to the recently merged 2.38_2 version that has the fix for EAC to not crash brings it back to life, and it does start now, only issue is that it fails with a network error now x)
Which is weird, cuz looking at EAC logs it finishes the download, but the callback throws an error?
[2024.01.01-13.37.29] Download Progress: 90
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] [Connection] Connect result: No error (0) Response Code: 200 Destination IP: 18.244.146.77
[2024.01.01-13.37.29] Download Progress: 100
[2024.01.01-13.37.29] [EAC Callback] Code: 509. Message: 'Unexpected error. (#1)'.
Not sure if its related to the new glibc update, it did disable cryptography functionality from glibc and instead moved it to libxcrypt , you can find more in the glibc package MR https://github.com/void-linux/void-packages/pull/45501
I wonder if preloading steam with libxcrypt will help it :thinking:
