Source SDK Base 2006 MP dedicated server (AppID 205, formerly "-game episode1") no Linux files?

[Mecha-Weasel]

I didn't see this tracked somewhere already, so I thought I would point it out (reminder), that apparently the AppID 205 "Source SDK Base 2006 MP dedicated server" that in theory replaces the old "-game episode1" installs (formerly by HLDSUpdateTool) doesn't include Linux binaries - only Windows.

The previous HLDSUpdateTool "-game episode1" installs previously provided Linux binaries also. Needless to say, this leaves Linux servers for some mods dead in the water.

The same appears to be true for the old HLDSUpdateTool "-game orangebox" installs?

Any time-table on release of updated Linux ports? or are we stuck with hoping old mod authors are still around to re-develop their stuff for 2013 SDK?

[ghost]

I'm pretty sure only games running the newest engine build are getting ported. I doubt they would take the time to make ports of the obsolete engine versions.

[yaakov-h]

It's not a new port, IIRC the older SDKs already had Linux server support.

[Mecha-Weasel]

Exactly. They apparently just didn't move the content over from the old distribution system (that HLDSUpdateTool formerly used) to the "SteamPipe" distribution system (that SteamCMD now uses).

[Mecha-Weasel]

I think this has been resolved some time ago. So, I will go ahead and close this for now.

[Mecha-Weasel]

Update: Just tried installing AppID 205 (Source Dedicated Server) via SteamCMD on Linux again. No Linux-native binaries are included - only Windows binaries. Conversely, AppID 310 (Source 2007 Dedicated Server) does provide Linux binaries.

[Nafrayu]

I just had the same problem (on Ubuntu 12.04.3 LTS if that matters)

[squeek502]

This is still an issue.

[DexterHaslem]

I want to add trying to use @sSteamCmdForcePlatformType "linux" in steamcmd doesn't help

[illwieckz]

Hi, any news on this topic? the linux solib is still missing from appid 205… some games just can't be hosted on linux dedicated servers…

[illwieckz]

Just saying, perhaps it could help some Valve developers, a friend of mine had a very old copy of srcds 2006 (episode1) linux binary, it allowed me to put my hand on it to do some tests.

I don't have access to the last released binaries from Valve so I can't say if the problem I experienced are relevant, but certainly.

There is two major problems these binaries have, so perhaps Valve is just not distributed them because of these problems.

1. Like the srcds 2007 linux binary (still distributed by Valve), the srcds 2006 binary needs to be run with the environment variable MALLOC_CHECK_ set to 0. This is not a big problem since it did not prevent Valve to distribute the 2007 binaries that experiences the same problem. In fact, the srcds 2006 binary is more stable (runs fine every time it is launched when using this variable) than the srcds 2007 binary (crashes more than 50% of the time at startup, even with this variable).
2. The srcds 2006 linux binary does not run on Intel CPUs anymore. Yes, the scrds binary is doing some runtime optimization depending the CPU you have, and this binary just goes wrong on modern Intel CPUs. It seems to run fine on modern AMD CPUs. Since this runtime optimization depends on the direct CPUID instruction, it can't be fooled on a software side with magic tricks like LD_PRELOAD or whatever you can imagine. The only way I find to run srcds 2006 on Linux is to run it on an emulator/virtualizer/hypervisor and writing my own _vendorid register value to disable the runtime optimizations. I noticed that spoofing an GenuineIntel cpu with a AuthenticAMD _vendorid leads to a another kind of crash, so the best way is to spoof the _vendorid with an undocumented value (like ValveFakeCPU if you want).

For example if you are running a Xen hypervisor, you can write that on your Xen virtual machine configuration:

cpuid = [ '0:eax=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,ebx=01110110011011000110000101010110,ecx=01010101010100000100001101100101,edx=01101011011000010100011001100101',
          '1:eax=00000000000000000000000000000000,ebx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,edx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'36507222018:eax=01110110011011000110000101010110,ebx=01100001010001100010000001100101,ecx=01000011001000000110010101101011,edx=00110011001000000101010101010000',
'36507222019:eax=00000000001100000011000000110000,ebx=00000000000000000000000000000000,ecx=00000000000000000000000000000000,edx=00000000000000000000000000000000',
'36507222020:eax=00000000000000000000000000000000,ebx=00000000000000000000000000000000,ecx=00000000000000000000000000000000,edx=00000000000000000000000000000000']

It will fool your _vendorid with the ValveFakeCPU value and the _modelname with the Valve Fake CPU 3000 value. You can use this online tool to generate registers of your own.

For Valve developers : I already tried to fool the GetCPUInformation function with one of my own returning non-intel value but it does not fixes the problem, so I can ensure the runtime optimization does not rely on this functions.

For Valve developers : you can try the binaries on multiple architecture using the qemu-i386-static binaries and the -cpu args. You will notice that many emulated Intel CPU above the Pentium3 are not able to run srcds 2006 but many AMD CPUs are able to run it.

For Valve recruiters : I’m available for hire.

For users : no I will not give you these binaries, do not ask me for them, ask Valve for them.

[illwieckz]

For your information this is the solib I wrote to bypass the builtin GetCPUInformation function using the LD_PRELOAD mechanism, it returns a 1GHz Pentium3-like CPU profile with a custom _vendorid of my own:

typedef unsigned char bool;
typedef unsigned char uint8;
typedef long long int64;
typedef char tchar;

struct CPUInformation {
        int m_Size;

        bool m_bRDTSC : 1,
             m_bCMOV  : 1,
             m_bFCMOV : 1,
             m_bSSE   : 1,
             m_bSSE2  : 1,
             m_b3DNow : 1,
             m_bMMX   : 1,
             m_bHT    : 1;

        uint8 m_nLogicalProcessors,
              m_nPhysicalProcessors;

        int64 m_Speed;

        tchar* m_szProcessorID;
};

struct CPUInformation CPUI;

struct CPUInformation *GetCPUInformation();

struct CPUInformation *GetCPUInformation() {
        CPUI.m_Size = 20;
        CPUI.m_bRDTSC = 1;
        CPUI.m_bCMOV = 1;
        CPUI.m_bFCMOV = 1;
        CPUI.m_bSSE = 1;
        CPUI.m_bSSE2 = 1;
        CPUI.m_b3DNow = 0;
        CPUI.m_bMMX = 1;
        CPUI.m_bHT = 0;
        CPUI.m_nLogicalProcessors = 0;
        CPUI.m_nPhysicalProcessors = 1;
        CPUI.m_Speed = 1000000000;
        CPUI.m_szProcessorID = "ValveFakeCPU";
        return &CPUI;
}

Since using this modified function does not fix the runtime optimization bug, I can say this function is not involved in this bug. The bug is elsewhere in another function, this function is probably not the only one that uses the cpuid opcode.

[Nafrayu]

For users : no I will not give you these binaries, do not ask me for them, ask Valve for them.

why are you such an asshole about this?

[illwieckz]

For users : no I will not give you these binaries, do not ask me for them, ask Valve for them.

why are you such an asshole about this?

Because you use strong words! :grinning:

The real reason is I don't know if I have the permission to do it, and this issue is something Valve must fix, I'm not paid by Valve to fix their own issues. :smirk:

[illwieckz]

For people who have hands on old binaries, there is a workaround to run them on newer CPU. This workaround does not require an hypervisor (like the cpuid faking example explained above), it also means you don't have to cripple other processes because of hiding your cpu's abilities to all process, just for the faulty old srcds one.

You know you need this workaround if you get things like that in output:

execing valve.rc
Unknown command "exr"
Unknown command "/"
Unknown command "mmandemts"
Unknown command "p_"
Unknown command "mp_"
Unknown command "_"
Unknown command "v_la"
Unknown command "1"
Unknown command "s"
Unknown command "sv_la"
Unknown command "svsv_l"
Unknown command "s"
Unknown command "l"
Unknown command "la1"
Unknown command "an"

The workaround is simple: emulate another cpu using qemu. If you run Ubuntu, Debian or SteamOS, the package to install is qemu-user-static:

sudo apt-get install qemu-user-static

Then you run the server this way:

qemu-i386-static -cpu pentium3 ./srcds_i686 [insert here your options]

For example:

qemu-i386-static -cpu pentium3 ./srcds_i686 -port 27015 +sv_pure 1 +map castle

If your binary is named srcds_i486, srcds_i686, srcds_amd, it will works, prefer the most advanced one though, the i686 one or the amd one. What is important is to emulate a pentium3, I tried to emulate some other processors but the pentium3 gave me good results. With many other processors I got various different crashes. Also, you don't need the MALLOC_CHECK_=0 hack while emulating an old cpu using qemu this way

By the way, since you're running the scrds binary the emulation way, it can increase a lot the cpu usage. This trick can probably be used to run that srcds binary on a non-x86 architecture, like on an arm processor (you probably have to get all the needed libraries though).

[DexterHaslem]

wow, nice find, thanks for sharing after all this time.

on a side note I tried the last bit about running cross-arch and the dependency libraries were quite intense, not for the faint of heart