Official Minecraft Bedrock Dedicated Server on Raspberry Pi*

Minecraft Bedrock Edition logo
Minecraft Bedrock Edition logo

One of the most requested features in my Raspberry Pi Minecraft server guide is support for the Bedrock edition of Minecraft. This is the edition that powers Minecraft on iOS / Android / Xbox / Nintendo Switch as well as the free Windows 10 edition.

There’s one big problem though. The official Minecraft Bedrock dedicated server is only compiled for Windows and Ubuntu X86_64. Without ARM support it seems impossible to run the Bedrock dedicated server on a Raspberry Pi. I couldn’t find a documented instance of anyone doing it anywhere.

So naturally today in this guide we are going to do the impossible. But right off the bat let me point out that there is an asterisk in my article title. Why you ask? That is because unlike my other guides this one will not yield you a well performing server. That is because we will be emulating a x86_64 processor on ARM. This is slow. VERY slow.

What’s the point?

So if the server doesn’t perform well and it’s too slow why did I even bother to write this article?

Basically “too slow” is only in the context of today’s hardware and software we currently have available to us. Both hardware and software for ARM have been evolving at a furious pace. ARM powers smartphones which means it is not going anywhere and will continue to have tons of R&D money put into it and it may not be long before the hardware is powerful enough.

There’s also the possibility that by sharing this work that someone who reads this may know or discover ways to speed things up and build on what I present here. If you’re one of those people drop me a comment or send me an email and I will gladly credit and share your work!

And last but not least, the techniques I use here can be used to run other x86_64 binaries on Raspberry Pi. Many applications will perform just fine even on current generation gear.

Hardware

This is the hardware I used for the server.  I always recommend using solid state storage for the best performance.  To see why check out the Raspberry Pi storage benchmarks section.  This contains benchmarks submitted by others who ran the benchmark so you can see what other people are using and provides the best performance.

Raspberry Pi 4 Model B 2GB

Official Minecraft Bedrock Dedicated Server on Raspberry Pi*

StarTech 2.5″ SATA to USB Adapter -AND- Kingston A400 SSD 120GB SATA 3 2.5” Solid State Drive

Official Minecraft Bedrock Dedicated Server on Raspberry Pi*
Official Minecraft Bedrock Dedicated Server on Raspberry Pi*
SATA to 2.5″ USB Adapter

Or for a compact setup: SanDisk Extreme Pro 128GB USB Solid State Flash Drive

Official Minecraft Bedrock Dedicated Server on Raspberry Pi*

Linux Distribution

For this to work it is required that we use a 64 bit aarch64/arm64 distribution. This is because when we try to emulate 32 bit ARM we will get a “bus error” as soon as the server tries to start. This is likely because QEMU 32 bit is missing some support we need to emulate the x86_64 architecture.

Distributions that will work:

Since the server is natively compiled for Ubuntu it is best to use a Debian based distribution. For the Raspberry Pi I recommend Ubuntu Server 18.04.2. Check out my article on how to install Ubuntu Server on Raspberry Pi.

You can also use the Debian “Buster” preview which has the advantage of having QEMU 3.1 available in the apt repository right now which will save you several steps later of having to acquire a newer static binary of QEMU the “evil” way.

Raspbian will not work with this method because it is only 32 bit. You will get a segmentation fault when you run it on a 32 bit ARM system instead of a 64 bit one.

Automatic Setup Script

If you just want to get your hands on the finished working server my Minecraft Bedrock Dedicated Server guide already supports ARM and will setup the dependencies and download the server for you. It also supports the following:

  • Sets up fully operational Minecraft Bedrock edition server in a couple of minutes
  • Ubuntu / Debian distributions supported
  • Sets up Minecraft as a system service with option to autostart at boot
  • Automatic backups when server restarts
  • Updates automatically to the latest version when server is started
  • Easy control of server with start.sh, stop.sh and restart.sh scripts
  • Optional scheduled daily restart of server using cron

Run the automatic setup script by pasting / typing the following on the command line:

wget https://raw.githubusercontent.com/TheRemote/MinecraftBedrockServer/master/SetupMinecraft.sh
chmod +x SetupMinecraft.sh
./SetupMinecraft.sh

Keep in mind that on the current Raspberry Pi things will be so slow that your connection will often time out before you finish logging in and when you do log in the lag does not provide a smooth playing experience. We’ll discuss this more later in the article.

Getting the Dedicated Server

The latest official dedicated Minecraft Bedrock server binary is available at: https://minecraft.net/en-us/download/server/bedrock/. We will download the Ubuntu Server version.

mkdir bedrock
cd bedrock
wget https://minecraft.azureedge.net/bin-linux/bedrock-server-1.12.0.28.zip
unzip -o bedrock-server-1.12.0.28.zip

We now have the Bedrock dedicated server unzipped into a folder called “bedrock”. However, if we try to run it by typing ./bedrock_server we get:

-bash: ./bedrock_server: cannot execute binary file: Exec format error

This is because we are on the ARM architecture and this file type is compiled for x86_64. In Linux we can get the file type format of any executable by using the file command:

# file bedrock_server
bedrock_server: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped

Now that we know what target architecture we need to run we need to get QEMU.

Installing QEMU Host Mode Emulator

You may have used QEMU before in the past to create virtual machines. But QEMU has another less known operating mode called user mode emulation. User mode emulation is faster than a virtual machine because it takes advantage of the host operating system to do a lot of functions rather than emulate an entire operating system.

On top of being much faster, this will allow us to run a x86_64 binary on the ARM platform without having to install a full blown x86_64 operating system inside a QEMU container.

At the time of writing the binaries provided in Ubuntu Server and Raspbian are too old and don’t have the x86_64 support we need. The binaries available in apt are QEMU 2.8 and we need 3.0 or higher.

Check what the latest version of QEMU available for your distribution is by typing:

sudo apt search qemu-user-static

On my system this yielded the result:

qemu-user/stable 1:2.8+dfsg-6+deb9u4 armhf
   QEMU user mode emulation binaries
qemu-user-static/stable 1:2.8+dfsg-6+deb9u4 armhf
   QEMU user mode emulation binaries (static version)

Notice the version is 2.8 and not 3.0 or higher. If your version is 3.0 or higher you can (and should) install qemu-user-static from apt.

Mine aren’t, so we are going to cheat. But before we cheat, I am going to explain why we are violating the Holy Sacred Linux Bylaws by doing what I’m about to show you and explain why it should basically never be used. If you are using the Debian Buster distribution you can skip the next section since QEMU 3.1 is already available in apt for Debian.

Evil way to get latest QEMU

The proper thing to do in this situation is to download QEMU from source and build the newer version yourself. The problem is QEMU takes forever and a day to compile. Even just trying to compile the user mode binaries I came back to my Pi a full 24 hours later and it still wasn’t even close to done.

Okay so building this binary in the Pi is too slow. So what is the proper thing to do then? The proper thing to do would be to set up a development machine for cross compiling on your main more powerful system and compile it that way. The downside? Unless you already have a system set up with a cross compiling chain this is going to also take a lot of research and effort to get set up.

So where could we possibly get precompiled binaries for our system? Well, since we are using a Debian based Linux distribution we are downstream from Debian proper. So let’s take a look at Debian’s repository and see what is available: https://packages.debian.org/buster/qemu-user-static

Well look at that. The upcoming Debian Buster repository contains QEMU 3.1! We can just grab it from there. But wait… RED ALERT!

Picard Facepalm
Captain Picard disliked that

This is very bad practice. The reason we can get away with it in this case is because qemu-user-static is statically compiled and only has one dependency (binfmt-support). All of the current stock Raspberry Pi distributions don’t have anything that depends on either of these packages. This makes qemu-user-static and binfmt-support relatively self contained. Nothing else in our system depends on them and they aren’t a part of any dependency chains.

Have you ever tried to install a package and been stopped by some little dependency? It may be tempting to use this technique in situations like that. However, when you introduce foreign packages into your package tree you will very likely break your entire system. If anything depends on those packages apt will go haywire since it won’t be able to resolve the dependency chains and you will lose the ability to update or install new packages. Many packages have dozens of dependencies and a single wrong one in the chain will break everything. Therefore this technique should almost never be used.

Okay, with all that out of the way, let’s proceed. These links change often so you will likely need to navigate to the repository yourself to find the latest package names.

wget http://ftp.us.debian.org/debian/pool/main/q/qemu/qemu-user-static_4.1-1+b3_arm64.deb
wget http://ftp.us.debian.org/debian/pool/main/b/binfmt-support/binfmt-support_2.2.0-2_arm64.deb
sudo dpkg --install binfmt*.deb
sudo dpkg --install qemu-user*.deb  

You should now have QEMU installed. You can verify this with the following:

# qemu-x86_64-static --version

qemu-x86_64 version 3.1.0 (Debian 1:3.1+dfsg-7)
 Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

Satisfying Dependencies

Now that we have QEMU installed if we try to run bedrock_server we get the following:

# ./bedrock_server
 /lib64/ld-linux-x86-64.so.2: No such file or directory

This is progress. We’re no longer getting an error that the system can’t read the binary format of the file. We are now met with a dependency error.

This is to be expected because we are running on a ARM system and don’t have any x86_64 dependencies installed. The Minecraft server executable is dynamically linked as we learned earlier with the file info tool. This means that we will need to provide some libraries for the executable to work.

The easiest and fastest way to get them is to install Ubuntu x86_64 on a virtual machine using something like VirtualBox or on a spare machine. If you want to download my copy of the dependencies and skip this step I have them zipped up at https://raw.githubusercontent.com/TheRemote/MinecraftBedrockServer/master/depends.zip

One alternative would be to set up a chroot environment containing a x86_64 environment but I have had nothing but problems trying to create such an environment on ARM. Usually the chroot will crash out QEMU and when you google the crash codes you will come across bug posts where the QEMU authors state that ARM to x86_64 isn’t used all that often and some things are unimplemented. This is also why we need to use QEMU 3.0 or higher to get the support we need to run the server as the support was improved in that version.

Once you have set up a x86_64 environment download the server like we did earlier and we will use the ldd tool to look up the dependencies. On your x86_64 installation type ldd bedrock_server:

# ldd bedrock_server
         linux-vdso.so.1 (0x00007fff04bb0000)
         libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007fb77c01b000)
         libCrypto.so => /home/james/minecraftbe/./libCrypto.so (0x00007fb77bdf0000)
         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb77bbd1000)
         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb77b9cd000)
         libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fb77b763000)
         libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fb77b2eb000)
         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fb77b0ce000)
         libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb77ad45000)
         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb77a9a7000)
         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb77a78f000)
         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb77a39e000)
         /lib64/ld-linux-x86-64.so.2 (0x00007fb780d6b000)
         libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007fb77a179000)
         libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007fb779f5c000)
         librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007fb779d40000)
         libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007fb779b32000)
         libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fb7798e7000)
         libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007fb779695000)
         liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007fb779487000)
         libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007fb779109000)
         libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fb778da4000)
         libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007fb778b70000)
         libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007fb77893a000)
         libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fb7786b9000)
         libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fb7783e3000)
         libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fb7781b1000)
         libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fb777fad000)
         libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fb777da2000)
         libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fb777b87000)
         libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fb77796c000)
         libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007fb77772b000)
         libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fb7773fc000)
         libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fb7771e9000)
         libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fb776fe5000)
         libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007fb776ddc000)
         libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007fb776b4f000)
         libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007fb7768ad000)
         libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007fb776677000)
         libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007fb776461000)
         libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fb776259000)
         libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007fb776030000)
         libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007fb775e21000)
         libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007fb775bd7000)
         libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fb7758ce000)
         libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fb775696000)

Yikes. This thing has a ton of dependencies! This is because it is dynamically linked executable so none of the source code is compiled into the binary for any of these dependencies.

Fortunately I have a bash one liner that will gather a copy of all these dependencies and put it into a folder:

mkdir depends
ldd bedrock_server | grep "=> /" | awk '{print $3}' | xargs -I '{}' cp -v '{}' depends

Now zip or tar this folder and move it to your Raspberry Pi. We are going to put the dependencies right in the root of the bedrock folder that we created earlier. Your file structure on the Pi should now look something like this:

 bedrock_server               libgnutls.so.30      libresolv.so.2
bedrock-server-1.10.0.7.zip libgpg-error.so.0 librtmp.so.1
bedrock_server_how_to.html libgssapi_krb5.so.2 libsasl2.so.2
behavior_packs libhogweed.so.4 libssh2.so.1
definitions libidn2.so.0 libssl.so.1.1
depends.zip libk5crypto.so.3 libstdc++.so.6
ld-2.28.so libkeyutils.so.1 libtasn1.so.6
libcom_err.so.2 libkrb5.so.3 libunistring.so.2
libCrypto.so libkrb5support.so.0 libz.so.1
libcrypto.so.1.1 liblber-2.4.so.2 permissions.json
libc.so.6 libldap_r-2.4.so.2 README.txt
libcurl.so.4 libm.so.6 release-notes.txt
libdl.so.2 libnettle.so.6 resource_packs
libffi.so.6 libnghttp2.so.14 server.properties
libgcc_s.so.1 libp11-kit.so.0 structures
libgcrypt.so.20 libpsl.so.5 whitelist.json
libgmp.so.10 libpthread.so.0

Now for the last step there is one more dependency we need to resolve that won’t be included in the command we executed. This dependency is the linker dependency ld-2.28.so and the trick we are going to use in the next section won’t work on it. Use these commands:

sudo mkdir /lib64
sudo ln -s /home/pi/bedrock/ld-2.28.so /lib64/ld-linux-x86-64.so.2

This will install the linker binary where it needs to be for us to run the application by creating a symbolic link. The rest of the dependencies will be able to be in the folder that the server is running.

Running the Server

Now we have all our dependencies in place and are ready to run the server. I can’t wait to issue a ./bedrock_server! Let’s try it:

# ./bedrock_server

/lib64/ld-linux-x86-64.so.2: No such file or directory

Ugh. It’s looking for the dependencies in the wrong place! So how do we fix that? The trick is actually on the Minecraft Bedrock server dedicated server download page. We need to change the library load path to our local directory. So the proper way to run the server will be like this:

LD_LIBRARY_PATH=. ./bedrock_server

Now that we run the server this way we see the following output:

 NO LOG FILE! - setting up server logging…
[2019-04-27 00:47:16 INFO] Starting Server
[2019-04-27 00:47:16 INFO] Version 1.11.1.2
[2019-04-27 00:47:16 INFO] Level Name: Bedrock level
[2019-04-27 00:47:16 INFO] Game mode: 0 Survival
[2019-04-27 00:47:16 INFO] Difficulty: 1 EASY
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unsupported setsockopt level=41 optname=20
Unsupported setsockopt level=41 optname=20
Unsupported setsockopt level=41 optname=34
[2019-04-27 00:51:14 INFO] IPv4 supported, port: 19132
[2019-04-27 00:51:15 INFO] IPv6 supported, port: 19133
[2019-04-27 00:53:48 INFO] Server started.

As we can see QEMU does complain about several missing QEMU_IFLA types. These messages relate to certain functionality not being implemented in QEMU yet. These can be safely ignored for now but hopefully if QEMU implements these later it will provide a speed boost to the server.

Another thing to note is the timestamps. The server takes some time to load when using emulation. The total time to reach the “Server started.” line was about 5 minutes. I told you it was slow!

You may now connect to the server but expect it to time out many of your connection attempts. When you do get in monsters will be very slow and glitchy. Breaking blocks will have a significant delay.

Conclusion

With the tools and hardware that are available to us today we are able to run the Minecraft Bedrock dedicated server on Pi but it is too slow.

Improvements in hardware and software such as more updates and better implemented of x86_64 emulation on the ARM platform will likely change this in the near future.

Another game changer would be if Mojang chooses to distribute a native ARM binary that we can run on the Pi. This would be *much* faster and would be the ideal scenario. Definitely send them an email or leave a comment on their feedback form if you want to see this!

I will update this article as things change going forward. If you are experimenting with this and find a way to speed things up definitely leave a comment here so I can credit you and publish your findings!

If your goal with this project was to have a small self contained Minecraft server that doesn’t use a lot of power I do have some alternative recommendations below to use in the mean time for getting a well performing Bedrock server.

Viable Alternatives

Cheap SBC Option

The closest thing to a Raspberry Pi that natively supports x86_64 is the Intel Compute Stick. It’s a Intel X86_64 with 1 GB of RAM for around the same price as a Raspberry Pi:

Intel Compute Stick STCK1A8LFC

This image has an empty alt attribute
Intel Compute Stick

The Intel compute stick is just a little bit bigger than a USB flash drive and is powered by Micro USB.

If you choose this option check out my guide here for how to install Ubuntu Server 18.04.2 on it here: https://jamesachambers.com/2019/02/install-ubuntu-server-18-04-on-intel-compute-stick-guide/

Mid Range Option

This is a cheap mini PC that has 2 GB of RAM and comes preloaded with Windows 10. These are still very small but not nearly as small as a Raspberry Pi or Intel Compute Stick. You can also upgrade to the 4 GB of RAM version for slightly more.

ACEPC T8 Fanless Mini PC

Official Minecraft Bedrock Dedicated Server on Raspberry Pi*
ACEPC Mini PC

Higher End Option

This is a full blown PC in Micro ATX form that uses much less power and takes up much less space than a traditional ATX or Mini ATX PC.

Warning: This is the absolute highest price point you want to go before it makes much more sense to just buy a used PC off eBay or local listings. You should be able to find a used PC with 4-8 GB of RAM for less than any new PC will cost fairly easily.

The upside of this option is that you are covered by manufacturer’s warranty and have support if needed but above this price point it’s easier to just buy a different used one if you start having problems!

Dell Optiplex Micro 8GB RAM

Official Minecraft Bedrock Dedicated Server on Raspberry Pi*

I have tested running the Bedrock server on a couple of these that I have at home and performance has been great. Power usage is low for a full blown PC as the power adapter it comes with can only draw 65 watts.

19 thoughts on “Official Minecraft Bedrock Dedicated Server on Raspberry Pi*”

  1. Avatar for raticide

    I’m running successfully a Minecraft Bedrock server without emulation and good performance on my Raspberry Pi. I’ve just installed open-jdp on a raspbian-buster-lite and installed NukkitX (which is java based hence the very good performances I guess)

    NukkitX can be found here : https://github.com/NukkitX/Nukkit

    Basic installation process :
    . Install Raspbian Lite, apt update & upgrade
    . Install open-jdk
    . create /srv/mcserver folder
    . go to /srv/mcserver folder
    . copy nukkit-1.0-SNAPSHOT.ja file that you can grab here https://ci.nukkitx.com/job/NukkitX/job/Nukkit/job/master
    . start for the first time so that it creates all the structure : java -jar nukkit-1.0-SNAPSHOT.jar
    . stop in console
    . setup server.properties
    . adding some compatible plugins (essentials, …)
    . restart server : java -jar nukkit-1.0-SNAPSHOT.jar

    Seems a great solution to me performance wise 🙂

    1. Avatar for jamesachambers

      This is great raticide and essentially supersedes my guide. This is definitely the way you would want to run the Bedrock server on the Pi. I will add writing an updated guide to my to-do list!

  2. Avatar for Flo

    I use the Debian buster. Got no Problems, everything worked fine with the srcipt.

    When I try to start the server I get an Segmentation fault, any ideas?

    pi@raspberrypi-minecraft:~/minecraftbe/minecraft-server $ LD_LIBRARY_PATH=. ./bedrock_server
    NO LOG FILE! – setting up server logging…
    [2019-07-14 12:45:50 INFO] Starting Server
    [2019-07-14 12:45:50 INFO] Version 1.12.0.28
    [2019-07-14 12:45:50 INFO] Session ID 38b6ca3c-eb46-47c6-a566-f2a08ab680a4
    [2019-07-14 12:45:50 INFO] Level Name: Bedrock level
    Segmentation fault
    pi@raspberrypi-minecraft:~/minecraftbe/minecraft-server $

    1. Avatar for BZ

      I received this same error two days ago as well. The best I can tell is that there is an issue with the Bedrock Server executable that is causing the failure on Debian. Maybe if we try again in a week or so, with whatever server patch, the issue will no longer exist?

  3. Avatar for Ben

    when i run it, it gives me the error:

    /lib64/ld-linux-x86-64.so.2: No such file or directory

    I did the lb library path thing and all, and I looked in the lib64 folder, and i saw a file called ld-linux-x86-64.so.2
    I have no idea what to do to fix this. Do you have any ideas?

    1. Avatar for Flo

      Please look if the symlink is correct, in my case I had to relink it

      pi@raspberrypi-minecraft:~/minecraftbe/minecraft-server $ ls -l /lib64/ld-linux-x86-64.so.2
      lrwxrwxrwx 1 root root 48 Jul 13 14:20 /lib64/ld-linux-x86-64.so.2 -> /home/pi/minecraftbe/minecraft-server/ld-2.28.so
      pi@raspberrypi-minecraft:~/minecraftbe/minecraft-server $

    1. Avatar for jamesachambers
      jamesachambers

      I have my order coming to do a review and a bunch of testing. I ordered the 2GB one to get right away (in stock) and preordered the 4GB version that will ship July 18th.

      I can already tell you the more memory the better so I would recommend buying the 4GB version but I will have more concrete tests coming soon!

    1. Avatar for jamesachambers
      jamesachambers

      Unfortunately no! I wish there was but Mojang has made their new version (Bedrock) in C++ instead of Java and they communicate completely differently. Maybe some day they will add this capability but there’s no official or unofficial fork currently that can do both at the same time.

  4. Avatar for Nicholas Duran
    Nicholas Duran

    Hey there,
    I followed the tutorial and still haven’t got it working.
    What would you set the LD_LIBRARY_PATH=. to?

    1. Avatar for jamesachambers
      jamesachambers

      Usually the LD_LIBRARY_PATH=. is what you want as long as you are in the server directory when you run it. It is just telling it to load all the libraries from that path.

      When you run that command is it giving you any errors like a missing library?

      1. Avatar for Ben

        when i run it, it gives me the error:

        /lib64/ld-linux-x86-64.so.2: No such file or directory

        I did the lb library path thing and all, and I looked in the lib64 folder, and i saw a file called ld-linux-x86-64.so.2
        I have no idea what to do to fix this. Do you have any ideas?

  5. Avatar for oui

    Hello!
    I also tried in the same way as you did, but it was very slow as was expected…
    (In my case, I compiled and used qemu 4.0.)

    I want to know if there are good ideas to improve performance.
    The best thing is that the native ARM binary is released.
    Thanks.

    1. Avatar for jamesachambers
      jamesachambers

      Hey oui,

      One option I’m investigating is the MCPELauncher project which uses the binary from the Google Play store to launch a Bedrock server.

      For QEMU I haven’t explored whether there are any compiler flags or patches out there that can affect performance but I would assume yes. QEMU support may also improve at the future (in the old versions of QEMU x86_64 on ARM was just a bunch of stubs but was recently fleshed out).

      We’re in pretty uncharted territory here though so if you are able to discover anything let us know!

      1. Avatar for Black Hat

        I can confirm that the MCPELauncher approach works perfectly. It is also performant enough for a server with a couple of people.

        1. Avatar for Flo

          Is there a guide on how this works with the MCPELauncher? I’m not very familiar with the subject, but I can follow instructions very well.

Leave a Comment

Your email address will not be published. Required fields are marked *

Type here..