Unable to run on Arm64

[Shamgar365]

Any advice on how to run on an arm64 machine? Getting these errors in the docker logs exec /usr/bin/bash: exec format error. I'm trying the docker-compose option, if that helps

[Micke90s]

Unfortunately this Dockerfile will not run on ARM64. The problem is, that the used steamcmd will not run native on on this system. There are a few projects which solved this by using fex to simulate the x86or x64 on ARM64. But this would require a complete rework of the Dockerfile.

See:

• https://github.com/TeriyakiGod/steamcmd-docker-arm64
• https://github.com/thijsvanloef/palworld-server-docker/issues/10 (same problem)
• https://github.com/yumusb/palworld-server-docker-arm

[Kuratius]

Not running native isnt the main issue. Box86/Box64 will execute an x86 binary just fine, this is what people used to run e.g. Titanfall 2 on phones.

[Micke90s]

@Shamgar365 @Kuratius I will look how the multi-architecture works for docker. I've just read a few things about that and t should be possible with an additional arm-Dockerfile

[Micke90s]

It will take some time. Just realized that my test system is arm32 and not arm64. 😅

[Micke90s]

I managed to get a arm64 test system. I will try to get it running.

[Micke90s]

Short update to the current progress Branch: https://github.com/Micke90s/core-keeper-dedicated/tree/arm64-box64

I managed to install box64 and the dependencies. The Dockerfile is buildable via
docker build --build-arg TARGETARCH=arm64 . --tag escaping/core-keeper-dedicated-arm64

Unfortunately, there is still a problem during the execution of CoreKeeperServer which causes an internal shutdown.

Begin MonoManager ReloadAssembly
- Loaded All Assemblies, in  2.992 seconds
- Finished resetting the current domain, in  0.065 seconds
PlatformConfiguration: loading platform configuration for variant Linux.
PlatformConfiguration: platform configuration for variant Linux was not found.
PlatformConfiguration: loading platform configuration for variant PC.
Fallback handler could not load library /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/data-0x54cc4350.so
Fallback handler could not load library /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/data-0x550440f0.so
Initializing Steamworks with AppID 1621690
[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
Shutdown handler: initialize.
CAppInfoCacheReadFromDiskThread took 28 milliseconds to initialize
Setting breakpad minidump AppID = 1621690
[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
Steam API initialized
Shutdown handler: cleanup.

At the moment I try to figure out what causes this problem.

More detailed logs:

Using emulated ./linux64/steamclient.so
Warning: Weak Symbol _ITM_RU1 not found, cannot apply R_X86_64_JUMP_SLOT @0x3f1a2dd158 (0xb4fa90)
Warning: Weak Symbol _ZGTtnam not found, cannot apply R_X86_64_JUMP_SLOT @0x3f1a2dd160 (0xb4fa90)
Warning: Weak Symbol _ITM_memcpyRtWn not found, cannot apply R_X86_64_JUMP_SLOT @0x3f1a2dd168 (0xb4fa90)
Warning: Weak Symbol _ITM_RU8 not found, cannot apply R_X86_64_JUMP_SLOT @0x3f1a2dd170 (0xb4fa90)
[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
Using native(wrapped) crashhandler.so
CAppInfoCacheReadFromDiskThread took 8 milliseconds to initialize
Setting breakpad minidump AppID = 1621690
Error loading needed lib libsteam.so
Warning: Cannot dlopen("libsteam.so"/0x3f1503fe79, 2)
[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
Steam API initialized
43401|Double SIGSEGV (code=1, pc=0x350913f8, addr=0xa, prot=00)!
Shutdown handler: cleanup.
Sigfault/Segbus while quitting, exiting silently

[Kuratius]

Did you install box86 also? Steam may depend on 32 bit libraries

[Micke90s]

Yes, Box86 is installed. On the latest test I removed the manual installation from the Docker file as Box64 and Box86 is already installed in the used base image sonroyaalmerol/steamcmd-arm64 (See steamcmd-arm64 - What makes this compatible with ARM64?)

I did not commit the changes of last night yet.

[vagkalosynakis]

@Micke90s any luck? I get:

Started server process with pid 140
./launch.sh: line 72: ./CoreKeeperServer: cannot execute binary file: Exec format error

Trying to run on Raspberry pi 4B

[Micke90s]

@vagkalosynakis I still testing around. Tried a FEX based docker base image (teriyakigod/steamcmd:arm64) today. Only got 100% CPU usage 😞 So I did not commit it.

Exec format error is the amd64 build. To test the arm64 build you can try my curren unstable dev branch.

git clone https://github.com/Micke90s/core-keeper-dedicated/
cd core-keeper-dedicated
git checkout arm64-box64
docker build --build-arg TARGETARCH=arm64 . --tag core-keeper-dedicated-arm64
docker run core-keeper-dedicated-arm64

Then you can check the logs or play around by opening a new shell.

#Get the name of the container 
docker ps 
docker exec -it <ContainerName> /bin/bash

Feel free to try. May you will find something I missed.

[Kuratius]

There seem to be recent issues related to steamCMD on the box86 GitHub repo. Since the last test ended on a sigfault, it may be good to open an issue or add the report to an existing one, as it may be a bug in box86 (potentially, anyway).

[hsau]

There seem to be recent issues related to steamCMD on the box86 GitHub repo. Since the last test ended on a sigfault, it may be good to open an issue or add the report to an existing one, as it may be a bug in box86 (potentially, anyway).

This seems to be the case as I am having the same issue. However, I did get it working with a workaround using the Box64 docker image from @Micke90s.

Instead of relying on steamcmd to grab the server files directly, I had to grab them from another Linux system where steamcmd is able to launch, and then put them in the /home/steam/core-keeper-dedicated/ folder within the container (which should be tied to the "server-files" folder outside of the container, as specified as one of the volumes in the "docker run" command). I also had to update Box86 and Box64 in the Docker container by using "apt upgrade" command within the container, and set the environment variables as explained in the steamcmd-arm64 page. I also referred to others running Valheim servers on ARM for the environment variables, since Valheim is also Unity-based, such as this post on Box64.

Note

• Not updating Box86 and Box64 in the container results in the server being stuck while launching.
• Not setting the environment variables results in the server becoming unresponsive without any error messages after few minutes. The server will kick connected players and they won't be able to reconnect afterwards.
• While I haven't experimented much with Box86 environment variables, they don't seem to fix the steamcmd sigfault error when I tried a few.
• Tested using the 1.0.0.8 version released on September 16, 2024.

These are the steps I took as an example:

# Create a docker using Box86 and Box64 environment variables
# Modify WORLD_NAME and MAX_PLAYERS environment variables as needed
docker run -d \
  -e BOX64_DYNAREC_BIGBLOCK=0 \
  -e BOX64_DYNAREC_SAFEFLAGS=2 \
  -e BOX64_DYNAREC_STRONGMEM=3 \
  -e BOX64_DYNAREC_FASTROUND=0 \
  -e BOX64_DYNAREC_FASTNAN=0 \
  -e BOX64_DYNAREC_X87DOUBLE=1 \
  -e BOX64_DYNAREC_BLEEDING_EDGE=0 \
  -e BOX86_DYNAREC_BIGBLOCK=0 \
  -e BOX86_DYNAREC_SAFEFLAGS=2 \
  -e BOX86_DYNAREC_STRONGMEM=3 \
  -e BOX86_DYNAREC_FASTROUND=0 \
  -e BOX86_DYNAREC_FASTNAN=0 \
  -e BOX86_DYNAREC_X87DOUBLE=1 \
  -e BOX86_DYNAREC_BLEEDING_EDGE=0 \
  -e WORLD_NAME="Core Keeper Server" \
  -e MAX_PLAYERS=5 \
  -v $(pwd)/server-data:/home/steam/core-keeper-data \
  -v $(pwd)/server-files:/home/steam/core-keeper-dedicated \
  --restart=unless-stopped \
  --name core-keeper-dedicated escaping/core-keeper-dedicated-arm64

# Copy the server files from another Linux system to the "server-files" folder linked to the 
# /home/steam/core-keeper-dedicated folder within the container
cp -rf /server_files_from_another_system ./server-files

# Enter into the container as root
docker exec -u root -t -i core-keeper-dedicated

When inside the docker container as root:

# Update packages within the container
apt update && apt upgrade -y
# Update /home/steam folder owner to user "steam"
chown -R steam /home/steam
# Exit the container
exit

After exiting the container:

# Restart the docker container
docker restart core-keeper-dedicated

[Micke90s]

Instead of relying on steamcmd to grab the server files directly,

The Project palworld-server-docker is using DepotDownloader
May would also work for us.

• Not updating Box86 and Box64 in the container results in the server being stuck while launching.

I will add this to the image
EDIT: Just saw that I changed from sonroyaalmerol/steamcmd-arm64:root-2024-07-08 to sonroyaalmerol/steamcmd-arm64:root already.

• Not setting the environment variables results in the server becoming unresponsive without any error messages after few minutes. The server will kick connected players and they won't be able to reconnect afterwards.

I will add the missing parameters. I only tried the on steamcmd-arm64 page mentioned parameters yet.

[Micke90s]

I pushed the current development brach.

• Added BOX64&BOX86 Parameters (Thanks to @hsau)
• Removed box64 installation (part of base image)
• Added apt-get update
• Use ARCHITECTURE variable for launch

The error Error loading needed lib libsteam.so Warning: Cannot dlopen("libsteam.so"/0x3f1503fe79, 2) is still present.

I tried following error fix without success:

mkdir -p ~/.steam/sdk32/
ln -s ~/Steam/linux32/steamclient.so ~/.steam/sdk32/steamclient.so

Source https://github.com/haoyume/ssr/blob/master/docs/game-servers/install-steamcmd-for-a-steam-game-server.md#add-an-error-fix

[hsau]

Thanks for updating the image @Micke90s, I tested it and I was able to run the server no problem using similar steps as my previous post but without the BOX86 and BOX64 environment variables manually set.

The error Error loading needed lib libsteam.so Warning: Cannot dlopen("libsteam.so"/0x3f1503fe79, 2) is still present.

The steamclient.so file loads fine for me and the server is able to launch. There are multiple steamclient.so files and I'm not sure which one is being used. If I had to guess, it's one of /home/steam/core-keeper-dedicated/linux64/steamclient.so or /home/steam/core-keeper-dedicated/steamclient.so, both of which are downloaded from Steam along with all other Core Keeper Dedicated Server files. Obtaining those steamclient.so files from Steam and putting them in their respective locations might help with the issue.

I listed the hash for all steamclient.so files in the working container below. Only two of them are different, which are the files I mentioned above.

$ find "$(pwd -P)" -name "steamclient.so" -exec sha256sum {} \;
14bcc777fef3fe26ecc293a68e04aca811b6f58371f35103765563d688024882  /home/steam/.steam/sdk32/steamclient.so
c93b2101d17906505e5f7dbc738b452e0a5c602bc4a115592b2fabeea219e4fd  /home/steam/.steam/sdk64/steamclient.so
14bcc777fef3fe26ecc293a68e04aca811b6f58371f35103765563d688024882  /home/steam/steamcmd/linux32/steamclient.so
c93b2101d17906505e5f7dbc738b452e0a5c602bc4a115592b2fabeea219e4fd  /home/steam/steamcmd/linux64/steamclient.so
b13b8f02e8703d2cea3fcbef51e5d46507dc0287b65b54c88e626880cdce1d05  /home/steam/core-keeper-dedicated/linux64/steamclient.so
27d089e304d05f7573b09941117dfff77ab8ecd03ce1c210dd1797dde713cd67  /home/steam/core-keeper-dedicated/steamclient.so
14bcc777fef3fe26ecc293a68e04aca811b6f58371f35103765563d688024882  /usr/lib/i386-linux-gnu/steamclient.so
c93b2101d17906505e5f7dbc738b452e0a5c602bc4a115592b2fabeea219e4fd  /usr/lib/x86_64-linux-gnu/steamclient.so

[Micke90s]

@hsau Thank you. Great idea to compare the available steamclient.so

I think the LD_LIBRARY_PATH is wrong, as the additional value points to a not existent directory. Also, the default value seems to be empty. DISPLAY=:99 LD_LIBRARY_PATH="$LD_LIBRARY_PATH:../Steamworks SDK Redist/linux64/" /usr/local/bin/box64 ./CoreKeeperServer "${params[@]}"& I tried several values now, but nothing worked, yet.

I also will reenabled the RUN dpkg --add-architecture i386. In one of the first versions this caused the docker build to fail, but now it seems to work. (I am not sure if this is still needed as the amd64 image worked fine without it)

[hsau]

@Micke90s I was able to see from your log in the earlier post that /home/steam/core-keeper-dedicated/linux64/steamclient.so is the one that causes issues.

More detailed logs:

Using emulated ./linux64/steamclient.so
Warning: Weak Symbol _ITM_RU1 not found, cannot apply R_X86_64_JUMP_SLOT @0x3f1a2dd158 (0xb4fa90)
Warning: Weak Symbol _ZGTtnam not found, cannot apply R_X86_64_JUMP_SLOT @0x3f1a2dd160 (0xb4fa90)
Warning: Weak Symbol _ITM_memcpyRtWn not found, cannot apply R_X86_64_JUMP_SLOT @0x3f1a2dd168 (0xb4fa90)
Warning: Weak Symbol _ITM_RU8 not found, cannot apply R_X86_64_JUMP_SLOT @0x3f1a2dd170 (0xb4fa90)
[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
Using native(wrapped) crashhandler.so
CAppInfoCacheReadFromDiskThread took 8 milliseconds to initialize
Setting breakpad minidump AppID = 1621690
Error loading needed lib libsteam.so
Warning: Cannot dlopen("libsteam.so"/0x3f1503fe79, 2)
[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
Steam API initialized
43401|Double SIGSEGV (code=1, pc=0x350913f8, addr=0xa, prot=00)!
Shutdown handler: cleanup.
Sigfault/Segbus while quitting, exiting silently

Mine is below, which uses /usr/lib/x86_64-linux-gnu/steamclient.so and is able to launch. This file has the hash c93b2101d17906505e5f7dbc738b452e0a5c602bc4a115592b2fabeea219e4fd. Try overwriting your /home/steam/core-keeper-dedicated/linux64/steamclient.so with the one from /usr/lib/x86_64-linux-gnu/steamclient.so.

EDIT: I tried the different steamclient.so (hash b13b8f02e8703d2cea3fcbef51e5d46507dc0287b65b54c88e626880cdce1d05) out of curiosity and it still launches. Perhaps steamclient.so is unrelated.

...
Using emulated /lib/x86_64-linux-gnu/steamclient.so
Warning: Weak Symbol _ITM_RU1 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff1a366798 (0xb84f80)
Warning: Weak Symbol _ZGTtnam not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff1a3667a0 (0xb84f80)
Warning: Weak Symbol _ITM_memcpyRtWn not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff1a3667a8 (0xb84f80)
Warning: Weak Symbol _ITM_RU8 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff1a3667b0 (0xb84f80)
[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
Using native(wrapped) crashhandler.so
Setting breakpad minidump AppID = 1621690
IPC function call IClientUtils::GetSteamRealm took too long: 145 msec
Error loading needed lib libsteam.so
Warning: Cannot dlopen("libsteam.so"/0x7fff1503fe79, 2)
[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
Steam API initialized
Logged in with userid:3015774224
clear list of unsupported mods that is loaded anyway due to version change  -> 1.0.0
UnloadTime: 28.806480 ms
...

[Micke90s]

I tried a few things the last days:

• using the DepotDownloader instead of steamcmd
• tried to install mono-complete to avoid any missing dependencies
• tried to set the LD_LIBRARY_PATH variable based on ldconfig -v

Unfortunately, I am still unable to get the server starting 😞

I will try a few more things, maybe I can find the problem.

[Micke90s]

Short update on this. I try to get the server running native on my raspberry pi without docker. I hope to get further information on how to set up the docker image correct.

[kelvin124124]

@Micke90s hello, I've created a version that is runnable on my oracle free tier machine (arm) on my fork https://github.com/kelvin124124/core-keeper-dedicated/tree/exp2 I can connect to the server and interact with it normally despite some lags.

Can you give it a try on your RPi?

[Micke90s]

@kelvin124124 Thank you.

At the moment I get the following output:

[S_API] SteamAPI_Init(): Loaded '/home/steam/.steam/sdk64/steamclient.so' OK.  (First tried local 'steamclient.so')
CAppInfoCacheReadFromDiskThread took 2 milliseconds to initialize
Setting breakpad minidump AppID = 1621690
[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
Steam API initialized
Steam server API failed to log in anonymously
Thread "CHTTPClientThreadPool:0" (ID 141) failed to shut down
Thread "CHTTPClientThreadPool:0" (ID 141) failed to shut down

As I am not sure if I broke a few things during my tests I will try to setup a clean raspian system today and give it a new try then.

[kelvin124124]

@Micke90s I deleted some unnecessary code in the exp branch. You might as well try that.

[Micke90s]

Unfortunately, it did not work.

The raspian is new 2024-10-22-raspios-bookworm-arm64-lite.

I only ran a few commands:

  curl -sSL https://get.docker.com | sh
  git clone https://github.com/kelvin124124/core-keeper-dedicated.git
  cd core-keeper-dedicated/
  git checkout exp
  sudo docker build . --tag ck
  sudo docker compose up

Output:

ck  | [S_API] SteamAPI_Init(): Loaded '/home/steam/.steam/sdk64/steamclient.so' OK.  (First tried local 'steamclient.so')
ck  | CAppInfoCacheReadFromDiskThread took 4 milliseconds to initialize
ck  | Setting breakpad minidump AppID = 1621690
ck  | [S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
ck  | Steam API initialized
ck  |
ck  | =================================================================
ck  |   Native Crash Reporting
ck  | =================================================================
ck  | Got a SIGSEGV while executing native code. This usually indicates
ck  | a fatal error in the mono runtime or one of the native libraries
ck  | used by your application.
ck  | =================================================================
ck  |
ck  | =================================================================
ck  |   Native stacktrace:
ck  | =================================================================
ck  |   0x3f0411550e - /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_breakpoint_clean_code
ck  |   0x3f040bdf89 - /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_unity_backtrace_from_context
ck  |   0x3f04043410 - /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_jit_set_domain
ck  |   0x30000080 - Unknown
ck  |   0x5b895f391d355a91 - Unknown
ck  |
ck  | =================================================================
ck  |   Telemetry Dumper:
ck  | =================================================================
ck  | Thread 0x7eeed3af60 may have been prematurely finalized* Assertion at mono-threads.c:702, condition `info' not met, function:mono_thread_info_current,
ck  |
ck  | An error has occured in the native fault reporting. Some diagnostic information will be unavailable.
ck  |
ck  | =================================================================
ck  |   Native stacktrace:
ck  | =================================================================
ck  |   0x3f0411550e - /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_breakpoint_clean_code
ck  |   0x3f04261972 - /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_assertion_message_disabled
ck  |   0x7eeef3a498 - Unknown
ck  |
ck  | =================================================================
ck  |   External Debugger Dump:
ck  | =================================================================
ck  | mono_gdb_render_native_backtraces not supported on this platform, unable to find gdb or lldb
ck  |
ck  | Exiting early due to double fault.

I also tried to create a swap file as the memory of 4GB could cause problems:

sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

[kelvin124124]

@Micke90s maybe give the main branch another try? That should be more resistant to that kind of errors. If that didn't work either then : (

[Micke90s]

Sorry, but it does not work. The system seems to stop here:

core-keeper  | Begin MonoManager ReloadAssembly
core-keeper  | - Loaded All Assemblies, in  3.130 seconds
core-keeper  | - Finished resetting the current domain, in  0.065 seconds
core-keeper  | Error: Symbol _ZSt28__throw_bad_array_new_lengthv not found, cannot apply R_X86_64_JUMP_SLOT @0x3f18054200 (0x6400) in /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/Plugins/libsentry.so
core-keeper  | Error: relocating Plt symbols in elf libsentry.so
core-keeper  | Fallback handler could not load library /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/sentry
core-keeper  | PlatformConfiguration: loading platform configuration for variant Linux.
core-keeper  | PlatformConfiguration: platform configuration for variant Linux was not found.
core-keeper  | PlatformConfiguration: loading platform configuration for variant PC.
core-keeper  | Fallback handler could not load library /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/data-0x7e068a70b0.so
core-keeper  | Fallback handler could not load library /home/steam/core-keeper-dedicated/CoreKeeperServer_Data/MonoBleedingEdge/x86_64/data-0x7e06423040.so
core-keeper  | Initializing Steamworks with AppID 1621690
core-keeper  | dlopen failed trying to load:
core-keeper  | steamclient.so
core-keeper  | with error:
core-keeper  | Cannot dlopen("steamclient.so"/0x3f1503fe85, 2)
core-keeper  |
core-keeper  | [S_API] SteamAPI_Init(): Loaded '/home/steam/.steam/sdk64/steamclient.so' OK.  (First tried local 'steamclient.so')
core-keeper  | CAppInfoCacheReadFromDiskThread took 6 milliseconds to initialize
core-keeper  | Setting breakpad minidump AppID = 1621690
core-keeper  | [S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
core-keeper  | Steam API initialized
core-keeper  | Steam server API failed to log in anonymously
core-keeper  | Thread "CHTTPClientThreadPool:0" (ID 135) failed to shut down
core-keeper  | Thread "CHTTPClientThreadPool:0" (ID 135) failed to shut down

[kelvin124124]

@Micke90s I'm sorry, but I have replicated the success on an ARM machine I rented on Azure for temporary testing. The server ran without the above issues. Unlike the server on oracle free tier machine, the server on azure have incredible stability despite higher ping, to the point that I don't feel any lag.

The issues are probably specific to RPi. Maybe using the box64 + 86 combo built for RPi would work, but I don't have a RPi so I couldn't test it.

[Micke90s]

I am not sure if we are able to create a general solution for all arm64 systems. There are a lot of different systems.

I will try Ubuntu as an additional test case. May there are some limitation on the raspian. Also it would be possible that my Raspberry Pi 4 (4GB) is just too weak and the 8GB version or Raspberry Pi 5 would work.

@hsau @Shamgar365 @vagkalosynakis @mwessman Could you please try the version of @kelvin124124 ? It also would be interesting which architecture (e.g. ARMv7 or ARMv8), operating system and memory your systems have and if it works or not.

[feserr]

Hi everyone. I have forked this repo and made some changes to run into an ARM machine. I have it running in an Oracle instance using Ampere ARM-based since 2 weeks ago without any problem so far.

The repo can be found here: https://github.com/feserr/core-keeper-dedicated

I am using the Docker image sonroyaalmerol/steamcmd-arm64 for it. Right now my image is set to be run for Ampere ARM-based machines, but it supports other machines as mention here: https://github.com/sonroyaalmerol/steamcmd-arm64?tab=readme-ov-file#box64-builds

Please let me know if you run with any issue using it.

[feserr]

I have raised a PR to add support for it: https://github.com/escapingnetwork/core-keeper-dedicated/pull/73

[Micke90s]

@kelvin124124 Could you please try to build and run the PR of @feserr on your arm64 host? If everything works, I think we could ask @arguser to accept the PR.