EAC EOS nonfunctional

[Irets]

Hey, Titles that use the EOS implementation of EasyAntiCheat do not launch with games-util/steam-launcher. They all fail on the EAC splashcreen with "Failed to load the anti-cheat module".

This is a Gentoo specific issue as users of other distributions have no issues. There have been multiple reports of other Gentoo users using this overlay having the same issue over at https://github.com/ValveSoftware/Proton/issues/1651#issuecomment-1064644988.

Here's my Gentoo forums post about this which goes in more in-depth, so I'll leave this Github issue OP a bit stub. https://forums.gentoo.org/viewtopic-t-1147585-highlight-.html

EAC EOS works when using Steam through Flatpak. Games that utilize easyanticheat_x64.so rather than EOS work fine with games-util/steam-launcher.

How could this issue be troubleshooted further?

[chewi]

I'd love to look into this, but I don't have Insurgency: Sandstorm or Elden Ring. They're not exactly cheap and I have no interest in either game, sorry. Unfortunately, it's not obvious what the problem is.

If it's deleting valid files that you've placed manually, you could try guarding against that with chattr +i <files>. Even root won't be able to delete them until you do chattr -i <files>. This isn't a solution, but it would be interesting to see whether it works after that.

Proton runs in a sandboxed container these days, so Gentoo has relatively little influence over its environment. Perhaps it's a kernel issue, though that seems unlikely, especially if the Flatpak version works.

[Irets]

Running chattr +i on the two manually placed files will prevent them from being deleted on game launch, but the same "Failed to load the anti-cheat module" issue still persists.

After applying chattr -i to them, they'll get deleted on next game launch. If you'd like to try it out on your own system, I know that Battlebit Remastered is a free-to-play game which uses the EOS implementation and does not consume much disk space on install. It will be really apparent if it works or not, as you should not be able to launch the game all the way if EOS is broken.

I've heard from Battbebit players that they've had success with Proton Experimental and Proton 6.3-8, but I've had none on Gentoo with any EOS game for that matter.

I doubt the issue lies with the kernel configuration, as I tried sys-kernel/gentoo-kernel-bin and sys-kernel/gentoo-sources with my own configuration. EAC EOS working with Flatpak enforces that.

Here's the output of emerge --info, as I noticed it to be missing from the forum post, although I doubt how much of use will it be when troubleshooting an issue like this. https://gist.github.com/Irets/d2f60c0e0c78e416752cb58a555e654a

[chewi]

I've reproduced it with Battlebit and Proton 6.3-8 and tried various things, all to no avail. I gather the container does rely on the host libraries to some extent, including glibc. That makes finding the culprit very difficult.

[Irets]

That makes finding the culprit very difficult.

How would that be done?

It's unfortunate that all EOS titles are broken at the moment on Gentoo, if not using Flatpak.

[chewi]

I'm not sure exactly. At a high level, it's either starting from Gentoo and making it more like a working distro until it works or starting from a working distro and making it more like Gentoo until it breaks. The former generally isn't possible because Gentoo tends to have a newer glibc than other distros (that might even be the problem) and glibc isn't forwards compatible.

I just extracted a Fedora 34 LXQt live image, entered it using bwrap on my Gentoo system with my Steam files bind mounted, and ran BattleBitEAC.exe directly with Proton's Wine. This actually worked and the game started, although it complained that Steam wasn't running. I then tried bind mounting just enough of Gentoo's glibc files so that it would still start, but it hung before starting the download. bwrap is only isolating the mount namespace so I guess that means that the Flatpak version works because of the Ubuntu environment rather than anything Flatpak itself is doing.

[chewi]

I persevered a little more. Rather than bind mount bits of glibc, I copied all of Gentoo's (32-bit) /lib into Fedora's /lib, and tried again. This time, I saw the anti-cheat error. I then reinstalled glibc.i686 in Fedora then the error went away. The game didn't start because things were still a little broken, but I think this is enough to tell us that the problem is something to do with glibc. It could be that it's too new. Mine is 2.34. Fedora's is 2.33. Maybe you could try Ubuntu 21.04 as that has 2.34. There are also some Gentoo-specific patches and features, although I think I ruled most of that out in my earlier testing.

[tarkkanakki]

For what it's worth, my version of glibc is 2.35, and EAC EOS is working on Arch Linux.

[Polluktus]

Then we can safely assume that the problem lies somewhere in glibc-2.33-patches-6.tar.xz. Maybe then we should open an issue at gentoo bugzilla.

[chewi]

I'm not sure. I did try running this with a "vanilla" glibc (there's a USE flag for it) but it didn't help. Maybe my test was bogus though. I need more time to give it another try.

[chewi]

I tried a different approach, combining overlayfs and bwrap. First I tried building Gentoo's glibc with different options, similar to before. Specifically, I did:

USE="-clone3 -ssp audit nscd suid systemtap vanilla" C(XX)FLAGS="-march=nocona -O2 -pipe -mstackrealign"

Unfortunately, this didn't help. I then grabbed the glibc binaries from Ubuntu 21.10, as this has glibc 2.34 like my system does. I had to rearrange the files a bit as they structure their libraries differently. With just the 32-bit libs, the error changed to Unexpected Error. With both the 32-bit and 64-bit libs, it actually worked. I tried again within Steam and the game started just fine. In short, it's definitely glibc. I just can't figure out why.

[Irets]

I don't want to mess up my glibc so i'm not going to try this, but could one of the patches applied by portage on glibc have something to do with it? I tried to poke around on the Ubuntu package repo but couldn't find the glibc source.

I found it for Arch Linux though, at https://github.com/archlinux/svntogit-packages/tree/packages/glibc/trunk. If I understoon the PKGBUILD correctly, they only apply

disable-clone3.diff 0001-localedef-Update-LC_MONETARY-handling-Bug-28845.patch
0001-localedata-Do-not-generate-output-if-warnings-were-p.patch

[chewi]

Like I said, I tried the vanilla USE flag, and that doesn't apply any patches. Maybe it's the hash style, as I've seen that cause similar problems before. I thought that was covered by the patches, but maybe not.

[chewi]

Got it! It is indeed the hash style. Just by chance, @thesamesam fixed this in 9999 with gentoo/gentoo@e5afbd004d49ecaa3a05b192a8bb0c21ea9d2f0e just the other day for a different issue. Sam, do you think we could backport this change?

[daugustin]

Can confirm that the linked commit fixes Insurgency.

For those who want an easy install, I copied it to my overlay and removed the single line with the hashstyle (eselect repository enable hossie).

Great finding @chewi !

[notfound4]

Hi. I've tried your ebuild for glibc and i still get the same error. Do i have to use specific use flags like vanilla ? Do i need to recompile @system or @world ?

[daugustin]

You still need to use Proton experimental. I also cleaned the prefix, maybe the EOS setup part already failed. USE flags: multiarch (multilib) ssp (static-libs) systemd I did not recompile anything, should not be necessary.

[chewi]

Actually, Proton 7.0 worked for me and 6.3 worked when I tried against Fedora libraries.

I did sometimes get "Unexpected Error" even after applying the fix, but it worked the next time.

[notfound4]

Thanks for the help. I didn't notice but the error changed to 'Failed to initialize dependencies' which was caused by SDL_VIDEODRIVER environment variable... Sorry

[chewi]

No problem.

I should also remember we're not just talking about Battlebit here. I doubt any of you are interested in that, especially as the playtest is not currently running.

[thesamesam]

Got it! It is indeed the hash style. Just by chance, @thesamesam fixed this in 9999 with gentoo/gentoo@e5afbd0 just the other day for a different issue. Sam, do you think we could backport this change?

Done in 2.34-r12 and 2.35-r4 - thank you all!

[matoro]

Thank you!!! I have been needing to keep a separate Steam install in Flatpak just to play Elden Ring for the past two months. Hugely appreciate this!!!!

[Irets]

Thank you for looking into this, Chewi & everyone else.

For those who do not want to use ::localrepo or switch to a testing version of glibc, you can use this simple patch that I created for glibc-2.34-r10 in the meantime, as that version doesn't have the fix.

--- a/configure
+++ b/configure
@@ -14,6 +14,10 @@
 ## M4sh Initialization. ##
 ## -------------------- ##

+#Fix hash setting for EAC EOS Steam games
+unset libc_cv_hashstyle
+
+
 # Be more Bourne compatible
 DUALCASE=1; export DUALCASE # for MKS sh
 if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then :