mtasa-blue
mtasa-blue copied to clipboard
MTA Serial Validation no longer working on Linux (again).
Describe the bug
I've been playing MTA on Linux for a while now, I know how to set up the server, validate my serial, etc.. and this bug was once fixed but it's now happening again. Yes, i've already tried alternative methods like not using Lutris etc.. It simply doesn't work, unfortunately.
Steps to reproduce
Follow the official tutorial on how to set up and run a MTA Server: https://wiki.multitheftauto.com/wiki/Installing_and_Running_MTASA_Server_on_GNU_Linux
The server will startup without issues: Querying MTA master server... success!
Start MTA and notice the serial still can't be validated.
7411: 2025-03-25 15:50:02 [9.23095.0.000 6.1 a] [00260-00328] - CClientGame::SetFileCacheRoot - Is shared 'C:\Program Files\MTA San Andreas 1.6\mods\deathmatch' 567: 2025-03-25 15:50:04 [9.23095.0.000 6.1 a] [00260-00328] - CAnimManager::ms_aAnimAssocGroups Address - CAnimManager::ms_aAnimAssocGroups = 0x3519a6ac 3200: 2025-03-25 15:50:05 [9.23095.0.000 6.1 a] [00260-00328] - Trouble serial-validation 7101: 2025-03-25 15:50:05 [9.23095.0.000 6.1 a] [00260-00328] - Core - Quit 7104: 2025-03-25 15:50:12 [9.23095.0.000 6.1 a] [00260] - Loader - Finishing 8070: 2025-03-25 15:50:12 [9.23095.0.000 6.1 a] [00260] - CheckService 5 result: 1 1044: 2025-03-25 15:50:15 [9.23095.0.000 6.1 a] [00260] - * End (0x0)* pid:260
Version
Client 1.6.0 on Arch Linux 6.13.6 and Ubuntu LTS 24.04 installed using Lutris version Win-GE 8.26 32-Bit and also 64-Bit .. and many other versions like Wine 10 without Lutris and Proton Experimental and Hotfix.
Additional context
The default resources aren't need for verfication, but i tried it anyway and this also doesn't fix the problem.
There is issue with latest version of MTA SA Client build on Wine, but I do not think it's related to this. Anyway, since it happens with Linux native server, there must be some weird issue, maybe on side of cpu serial generation or then on MTA servers side.
BTW, which server version did you tried? Did you tried latest nightly Linux server?
(I will try to run Linux server on my PC today)
Yep, i've tried everything. Nightly/Official, Windows-Server version running on Linux using Wine etc..
~~Okay, so i've been further experimenting with Wine versions and found out that "Lutris-7.2.2" (Which is no longer included in the latest release of Lutris), is the only Wine version that still works with MTA. I didn't even need to rerun the server because the serial was already long vailidated, but for some reason recent Wine versions simply just don't work well with it.~~
EDIT: Okay, nevermind. It now also shows the validation problem on 7.2.2. I managed to launch and play MTA once after install
From MacOS i managed to run with wine altho the game is extremely laggy meanwhile with parallels on non-AC protected servers (so Windows VM) is running perfectly at 60fps
Any news on this? Been 2 months, still looks broken.
Any news on this? Been 2 months, still looks broken.
Nope, unfortunately not. It's even worse if you try it on Debian 12 using Wine 10 (latest release). If you join any server, you get banned for "serial spoofing".. After searching for this issue and only finding generic replies from mods saying "I don't believe you, you're a cheater", i don't even bother to claim a "unban" request.
Any news on this? Been 2 months, still looks broken.
Nope, unfortunately not. It's even worse if you try it on Debian 12 using Wine 10 (latest release). If you join any server, you get banned for "serial spoofing".. After searching for this issue and only finding generic replies from mods saying "I don't believe you, you're a cheater", i don't even bother to claim a "unban" request.
Sad. I'm on Arch, using Lutris with wine-ge-8.26, tried to run the server multiple times as root (as the tutorial says) and as non-root also, but nothing. :/ At least I didn't get banned though, I guess that's a plus.
@Rilot06 I am on Arch, running it with latest Wine-staging 10.x, and everything still works like a charm. You have exactly the same issue as OP?
@Rilot06 I am on Arch, running it with latest Wine-staging 10.x, and everything still works like a charm. You have exactly the same issue as OP?
Yep. Just installed it today, serial validation error.
Hmm.... I am thinking how we can poke relevant developers which can help. I will try to ask devs on Discord.
Hmm.... I am thinking how we can poke relevant developers which can help. I will try to ask devs on Discord.
I really don't think the problem is on my end. I have managed to play MTA on linux before, serial validation worked great then, ran the server and poof. Tried with 32 and 64 bit wine prefixes too, different wine and proton versions, etc, nothing seems to be working. When did you install it? Maybe it worked back then and it's cached now somehow and it's only broken for new installs, that's the only thing I can think of. Hopefully will get fixed soon.
@Rilot06 it was more than year ago... so possibly.
Managed to run the game with bottles and soda runner, no serial validation error, but now I got banned for "SERIAL CHANGE / SPOOFER" too 🥲
hmm...
I guess best to ask devs on Discord
I guess best to ask devs on Discord
I'm banned on discord, also that message is from 2024, when they had an error that caused these bans. I guess the underlying error is still there with bottles and soda, but now the client doesn't see the problem with the serial, only the server when I try to connect to any.
hmm...
I guess best to ask devs on Discord
This has nothing to do with this issue. The automatic ban is happening now if you try to join servers on Linux. Also the MTA team no longer do unban review/requests.
I know it's from 2024, just that maybe there is some issue again?? Dunno. Also, I am just playing MTA on Linux, everything is still working well... Also, as far as I remember, I was doing second validation when I changed CPU this January, and it worked just fine.
I know it's from 2024, just that maybe there is some issue again?? Dunno.
Sure, it's an issue on Linux, but I’ve read how MTA handles bans nowadays. The options are: if it’s a system-related ban, you need to do a complete reinstall, this usually fixes the spoofing issue, as long as you don’t get banned again (which still seems to happen). If you were banned for actual cheating, there’s nothing you can do.
Also, I am just playing MTA on Linux, everything is still working well... Also, as far as I remember, I was doing second validation when I changed CPU this January, and it worked just fine.
Yes, this only affects fresh MTA installs on Linux. If you already have a validated serial, everything is fine. But it also means you're now stuck with this Linux installation, as soon you have to reinstall, well it's over. This is also my current problem, i was happily playing MTA on my Arch 2021 install, but then i got tired of KDE constantly changing things, so I switched to Debian, and now I can no longer validate it. :D
hi same error here, still from 2022
https://github.com/multitheftauto/mtasa-blue/issues/2705
@Fernando-A-Rocha used the bottles/soda guide on a new machine with linux mint and got serial validated after running mta server outside the wine sandbox as root user. so it should work.
@Fernando-A-Rocha used the bottles/soda guide on a new machine with linux mint and got serial validated after running mta server outside the wine sandbox as root user. so it should work.
The serial validation error disappeared after using bottles and soda (9.0.1 I think) as the runner, but the "SERIAL CHANGE / SPOOFER" ban doesn't.
@Fernando-A-Rocha used the bottles/soda guide on a new machine with linux mint and got serial validated after running mta server outside the wine sandbox as root user. so it should work.
The serial validation error disappeared after using bottles and soda (9.0.1 I think) as the runner, but the "SERIAL CHANGE / SPOOFER" ban doesn't.
the spoofer ban message appears after changing wine environment and should resolve after restarting mta though.
the spoofer ban message appears after changing wine environment and should resolve after restarting mta though.
I can try to make a fully fresh wineprefix, but doubt it will do anything, since it was created by bottles in the first place. It doesn't disappear, no matter how many times I restart MTA or try to run the server again.
@Fernando-A-Rocha used the bottles/soda guide on a new machine with linux mint and got serial validated after running mta server outside the wine sandbox as root user. so it should work.
The serial validation error disappeared after using bottles and soda (9.0.1 I think) as the runner, but the "SERIAL CHANGE / SPOOFER" ban doesn't.
the spoofer ban message appears after changing wine environment and should resolve after restarting mta though.
I did have to run the Linux MTA server as root 1st.
I also got the SERIAL CHANGE / SPOOFER message after starting MTA in bottles for the first time. Then, I rested the game and didn't get that message again.
I did have to run the Linux MTA server as root 1st.
I also got the SERIAL CHANGE / SPOOFER message after starting MTA in bottles for the first time. Then, I rested the game and didn't get that message again.
I made a new prefix, restarted the game several times, but the ban is persistent..
Recently, I had to go through this again, which gave me the opportunity to play around with the serial validation mechanism a bit. And I can confirm that this is due to a "misconfiguration" within MTAHQ. Specifically, whoever wrote the pairing code (perhaps over a decade ago) didn't anticipate certain newer hardware configurations (an "edge case", if you will). In particular, if your system doesn't have any (S)ATA / SCSI based storage devices (for example, if you only have NVMe SSDs), MTAHQ will refuse to do the pairing process (sadly, I don't think I'm allowed to say more + I believe the connection between storage devices and MTA serials is basically an open secret at this point). If you can't see an entry starting with either ata or scsi in /dev/disk/by-id/, the validation process is basically guaranteed to fail.
My hard drive has died since I last played MTA (which was about a year ago), and since then I've been using only a single NVMe SSD. I've managed to pass the validation process and even get my old serial back, but technically speaking it involved "spoofing" the HWIDs used in the validation process (telling MTAHQ that I still had my broken HDD). Hence, I can't share the steps here.
Recently, I had to go through this again, which gave me the opportunity to play around with the serial validation mechanism a bit. And I can confirm that this is due to a "misconfiguration" within MTAHQ. Specifically, whoever wrote the pairing code (perhaps over a decade ago) didn't anticipate certain newer hardware configurations (an "edge case", if you will). In particular, if your system doesn't have any (S)ATA / SCSI based storage devices (for example, if you only have NVMe SSDs), MTAHQ will refuse to do the pairing process (sadly, I don't think I'm allowed to say more + I believe the connection between storage devices and MTA serials is basically an open secret at this point). If you can't see an entry starting with either
ataorscsiin/dev/disk/by-id/, the validation process is basically guaranteed to fail.My hard drive has died since I last played MTA (which was about a year ago), and since then I've been using only a single NVMe SSD. I've managed to pass the validation process and even get my old serial back, but technically speaking it involved "spoofing" the HWIDs used in the validation process (telling MTAHQ that I still had my broken HDD). Hence, I can't share the steps here.
Thanks to letting us know So i can try to connect hdd and probably will pass validation????
Recently, I had to go through this again, which gave me the opportunity to play around with the serial validation mechanism a bit. And I can confirm that this is due to a "misconfiguration" within MTAHQ. Specifically, whoever wrote the pairing code (perhaps over a decade ago) didn't anticipate certain newer hardware configurations (an "edge case", if you will). In particular, if your system doesn't have any (S)ATA / SCSI based storage devices (for example, if you only have NVMe SSDs), MTAHQ will refuse to do the pairing process (sadly, I don't think I'm allowed to say more + I believe the connection between storage devices and MTA serials is basically an open secret at this point). If you can't see an entry starting with either
ataorscsiin/dev/disk/by-id/, the validation process is basically guaranteed to fail. My hard drive has died since I last played MTA (which was about a year ago), and since then I've been using only a single NVMe SSD. I've managed to pass the validation process and even get my old serial back, but technically speaking it involved "spoofing" the HWIDs used in the validation process (telling MTAHQ that I still had my broken HDD). Hence, I can't share the steps here.Thanks to letting us know So i can try to connect hdd and probably will pass validation????
It will probably pass the initial pairing / validation phase, i.e. MTAHQ will give you the serial it thinks you should have based on the connected HDD. However, that doesn't automatically mean it will pass further validity checks. (e.g. if you keep swapping HDDs and redoing the pairing, MTAHQ might rightfully detect that you are trying to spoof your serial). So it might be worth a try, but do it only at your own risk. The best would be to wait for the devs to fix this in the backend.
Using bottles and soda fixed it for me, and the spoofer ban - even though it didn't disappear automatically - got removed a few days ago when the other false spoofer bans were removed too. And I only have a single nvme drive too.
The best would be to wait for the devs to fix this in the backend.
I wouldn't get my hopes up, they don't seem to care much about linux
I think it's not that they don't care about Linux. Some people in the MTA staff really appreciate Linux. It's probably a lack of manpower and ability to improve the current AC system.