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.
The script is working on Raspberry Pi but if you use the Raspberry Pi OS’s Debian repositories the QEMU version in there will give a bus error. If you compile a newer QEMU from source or use a different operating system it works (very slowly)!
You may need to build the dependencies yourself if you are getting segfaults from my prepackaged depends.zip. This is because I generated a static dump of dependencies at a snapshot in time and they’ve likely been updated to a point they are no longer compatible. See the “Satisfying Dependencies” section for how to build the dependencies!
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.
Here’s the recommendations:
Recommended Gear
Raspberry Pi 4
The Raspberry Pi 4 is available in different memory configurations all the way up to 8 GB. It’s about the size of a credit card and uses an extremely low amount of power making it ideal for all sorts of projects and ideas!
The Raspberry Pi 400 kit includes everything you need for a full Pi 400 desktop build. The Pi 400 is the fastest Raspberry Pi ever released and comes in the form factor of a keyboard!
The Kingston A400 has been a great drive to use with the Pi for years. It’s reliable, widely available around the world, has low power requirements and performs very well. It’s also very affordable. This drive has been benchmarked over 1000 times at pibenchmarks.com and is the #1 most popular SSD among the Pi community!
The USB 3.1 variant of the StarTech 2.5″ SATA adapter works well with the Pi 4. The USB 3.0 variant doesn’t have firmware updates available and is not recommended.
The SanDisk Extreme Pro USB SSD is a true solid state drive. This is different than a typical “flash drive” which uses extremely cheap memory and has very low random I/O performance/throughput compared to a real solid state drive. I’ve used both the USB 3.1 and USB 3.2 variants with the Pi successfully and they benchmark very well!
The SanDisk Extreme A1-A2 SD card has the best scoring SD card on Pi Benchmarks for years and is second in popularity only to the SanDisk Ultra (often included in combo kits). The application class (A1) means random I/O speeds (very important when running an OS) have to meet a higher standard. There’s no benefit on the Pi for A2 right now so get whichever is cheaper/available.
All of these versions support cross-platform play with each other (but not with the Java edition).
Minecraft Bedrock Digital Code
This is the PC Minecraft for Windows 10 (Bedrock) edition of Minecraft. It is able to play cross-platform with other players on Android / iOS / Playstation / Xbox / Switch. Available as a code that is instantly activated to give you permanent access to the game!
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.
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 unless you use the 64 bit beta 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:
Before you join the server for the first time make sure the server has started by typing:
screen -r
You should be inside the Minecraft server console. What you want to look for before you try to join is that the server has completely finished starting. This can take a while on ARM. The line we want to see to know it’s ready is this:
[INFO] Server started.
The first time it joins will be very very slow. You may have to try several times as the server generates the starting area. Eventually you’ll get in and be able to move around. You’re able to break blocks but there’s definitely a delay when you break blocks and things are pretty laggy.
Manual Instructions
You only need to follow the manual instructions if you want to recreate my process step by step. Here are the steps:
mkdir bedrock
cd bedrock
wget https://minecraft.azureedge.net/bin-linux/bedrock-server-1.16.0.200.zip
unzip -o bedrock-server-1.16.0.200.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:
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!
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. First we are going to grab a prebuilt QEMU package for our ARM architecture. We can get these from the Debian repository. These links change often so you will need to navigate to the repository yourself and see what the latest available QEMU repository is. First we need to find qemu-user-static. Here’s where that will be in the Debian repository:
http://ftp.us.debian.org/debian/pool/main/q/qemu/
Make a note of the exact name of the package. You will need it in the next step. Now we need to find one more package which is binfmt-support from here:
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
Your version should be a lot newer than mine since this output is from the date of publication but if you didn’t get an error you should be all set to move on to the next step.
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 Minecraft Bedrock Server Dependencies – 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:
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:
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:
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 (your version may be different/newer) and the trick we just used to get the other dependencies won’t work on it. On the x86_64 machine copy ld-linux-x86-64.so.2 like this:
cd depends
cp /lib64/ld-linux-x86-64.so.2 ld-2.28.so
cp /lib64/ld-linux-x86-64.so.2 ld-2.31.so
If you have a different version of the linker you can find it with:
ldd --version
The version of the linker your system is using will be at the end of the very first line of the output from that command.
On the Pi use these commands to set up the linker:
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:
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.
Benchmarking / Testing Storage
If you want to verify your drive’s performance you may want to run my storage benchmark with:
If you search for the model of your drive on Pi Benchmarks you can compare your score with others and make sure the drive is performing correctly!
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!
Welcome! If I were to guess from similar issues people had it’s probably that this Pi is running Debian Buster or an older version and not Bullseye. Looks like ARM 32 bit which should be fine here.
It looks like that version of QEMU is throwing a bunch of warnings which definitely means it’s an older version of QEMU available on there. Those warnings are all fixed in the latest version.
I would recommend trying the Docker version for sure on that one. The Docker version uses the version of QEMU from ubuntu:latest so it’s always the newest no matter what is available in apt. Upgrading to Bullseye will work too as I had just fixed the standalone version a week or two ago and we had people successfully using it.
There’s a lot of people in this situation now because Raspberry Pi OS doesn’t automatically upgrade to the newest release (not even with sudo apt dist-upgrade) and Bullseye only was released earlier this year. That means anyone who imaged their Pi before about April of 2022 doesn’t have Bullseye. You have to actually edit the apt sources to get it to upgrade but to be honest I usually just reimage the SD for them as I’ve found the upgrades sometimes have weird issues when you edit the apt sources manually that disappear when I do a clean image on them with the latest.
I think either upgrading or trying with Docker would get it working on this one. Hopefully that helps!
No problem at all, you are very welcome and thanks for letting me know that worked for you since that helps and others reading this as well. Enjoy and have fun!
This has now been updated with Box64 for both Docker and the standalone versions! This should speed things up. If you’re already using the standalone version run the update.sh script from your server folder and it will get you to the Box64 updated version.
Note that for this to make a difference you need to be running a 64 bit OS. Both Ubuntu and Raspberry Pi OS have 64 bit versions available. A quick way to check this is if you do a:
uname -m
you should get aarch64 if you are on 64 bit ARM. Anyone on the Pi should give the updated version a try!
Great question, it has been a while since this has come up but other people have asked how to do this before! Basically all of the magic for backups happens in start.sh. To disable the backups altogether you could remove this section:
# Create backup
if [ -d "worlds" ]; then
echo "Backing up server (to minecraftbe/servername/backups folder)"
if [ -n "$(which pigz)" ]; then
echo "Backing up server (multiple cores) to minecraftbe/servername/backups folder"
tar -I pigz -pvcf backups/$(date +%Y.%m.%d.%H.%M.%S).tar.gz worlds
else
echo "Backing up server (single cored) to minecraftbe/servername/backups folder"
tar -pzvcf backups/$(date +%Y.%m.%d.%H.%M.%S).tar.gz worlds
fi
fi
That starts at line 69 in start.sh and you can open the file with a text editor and delete that entire section and backups will be gone. A more popular change though is to change the backups from 10 to 1 (so you at least have one backup while saving the maximum amount of space). You can do that by changing this line:
# Rotate backups -- keep most recent 10
Rotate=$(
pushd dirname/minecraftbe/servername/backups
ls -1tr | head -n -10 | xargs -d '\n' rm -f --
popd
)
Here you can change the head -n -10 to how many backups you want. head -n 1 would only keep a single backup. Hopefully that helps!
Hi James,
This is some real quality work. I thank you for your time documenting it and writing it. Everything went fine but the server wouldn’t start.
bedrock_server: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory
And I noticed no libcurl.so.4 had been copied to local directory. So I copied it over. Same result. I compiled a c program and linked that library in and called the curl_version_info function and dumped it out
lib curl version 7.74.0
So the .so file seems okay. Running bedrock_server these two ways produces
pi@raspberrypi:~/mcserver/bedrock/minecraftbe/mcbedrock $ ./bedrock_server
./bedrock_server: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory
pi@raspberrypi:~/mcserver/bedrock/minecraftbe/mcbedrock $ LD_LIBRARY_PATH=. ./bedrock_server
./bedrock_server: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory
So it seems to be finding other .so in that directory okay. You have any suggestions?
It looks like it’s time to move to libssl3 because the new version seems to be linking against that (along with a bunch of other new dependencies, any one of these which could explain this).
You’re right, I actually just *barely* updated depends.zip here about 15 minutes ago! I knew exactly what to add after fighting with the Docker container version last night and getting that one working. The changes are pretty wild. It’s about 3x bigger which is almost exactly what we would expect from 3x the dependencies as any previous version has ever had.
The depends.zip should be changed now when you have a chance to give it a try here! I’m not 100% sure everything it needs will be in there as on the Docker container version there were 2 additional dependencies that weren’t even listed in ldd as dependencies but were still needed. I’m still catching up / in a scramble here but let me know if you get any more additional errors!
No problem at all, thanks for your patience and willingness to try so many times through the various fixes. Take care and enjoy!
Moses
I tried the Box64 method Ishaan mentioned below, and it works great (kinda). However I noticed that some stuff is broken for some reason. For instance whenever I try to row a boat, it just sinks, so we can’t use it. Also the player skin is always invisible, which can cause some strange glitches etc. Am I the only one who have these issues?? I do have a Raspberry Pi 4b with 8GB, and I still have these issues :/
I actually found a thread on reddit with a bunch of replies from 3 months ago on this. It seems like this is a thing.
Some people are saying that the 1.18.3 release will fix it in that thread (or if we are unlucky they mean the prerelease after 1.18.3). At any rate I’m certain this has nothing to do with this script, your Raspberry Pi or memory or anything like that. It looks like this is just a really weird bug in the current version and that it has already been patched in the new betas (according to people on reddit at least)!
The thing is that the video shown in that Reddit link, they can at least board and row the boat. I can’t even do that due to, as soon as I board the boat, it just sinks… Like it goes underwater. And when it’s under the water it just ejects me from the boat. So I can’t row anywhere with it :/
And again I have the same issue with the players skin being invisible. Can’t see the characters hands or what I’m holding.
I agree with you. I even searched to see if anyone had ever even filed a bug like this. Nobody ever has. No invisible skin. No nothing even close.
I’m not sure what is going on here but nobody has ever reported anything like this outside that thread I linked on reddit. I searched for “open” and “in progress” issues and I believe that reddit bug is supposedly fixed already.
Do you have any other computers to run the client on or any other multiplayer servers you can connect to? It’s such a weird issue that I think you probably need to rule some things out here and make sure we’re looking in the right places. If you run the Minecraft client on another computer and connect does this still happen?
We’d also be looking for things like does this happen if you run the server on a PC, or can you recreate it by connecting to another multiplayer world? You’d want to actually connect to another multiplayer server to test this and not just run it in offline mode as maybe the problem is with the skin cache on the client or something really weird like that. It could even be network/firewall related and this test will also check that as you will see it if it is.
I think we need to probably narrow things down kind of like I’m describing above here. Does it happen if you start a completely fresh server? That would indicate the server is corrupted perhaps but usually you will be getting error messages all over the place when this is the case but it’s possible.
You may have checked some of these things already in our replies but we need the big picture (to put it all together in one place) especially since it’s a weird issue that nobody else is really saying they have (meaning we need to double check a whole bunch of things). Can you check those things and let’s see if we can narrow it down!
Well then I’ve tried to host a Bedrock server in both Windows and Linux Mint. Everything works great when I join, in mobile, Computer etc. The issue is when I try to host a Bedrock server in Raspberry Pi itself for some reason.
And yes everything is completely a fresh install. What I did was:
1. Used Raspberry Pi Imager.
2. Installed the latest Raspberry Pi OS 64-bit (not the Beta. The have released an official 64-bit).
3. Followed Ishaan’s method.
4. Host the server
5. Baaam the issue is still there for some reason.
So yeah everything is freshly installed, even the OS. I tried to reinstall the OS 3 times now, still have that specific problem.
Now when I think about it, could it be possible that the Raspberry Pi OS 64-bit itself might be the problem in this case?
Should I try the Ubuntu server instead? And if I try that, could I use the one from Raspberry Pi Imager or should I use the one you linked?
If I use the one you linked, which Ubuntu server version works the best? 20.04 or 20.10? 🙂
Great questions, and you answered all the questions I was wondering! So basically yes I would try on Ubuntu 20.04 first (the 64 bit version). That is the version I made the script for on Raspberry Pi (or at least generated the dependencies on which is probably the more important part here).
I think there’s an excellent chance this will get it. I didn’t realize you were running the regular Raspberry Pi OS. I would definitely give Ubuntu a try and let’s see if that gets it for you here!
I just installed Ubuntu Server 20.04 from the Raspberry Pi Imager and the installation worked fine.
HOWEVER when following Ishaan mehtod again, the EXACT same issue still remains. I can’t row the dam boat, and the characters skin is invisible. I don’t know what else to do.
I have a good internet connection (100/100 fiber) i’ve tried both Wifi and using the cable and the MicroSD card i use is the SanDisk MicroSD Extreme Plus 64GB. I’ve even tried other MicroSD cards, same issue…
I don’t know what else to do xD
I’ll think i just give up since it clearly is something strange and i can’t figure out why :/
That is very strange! I’ll definitely fire mine up here and make sure that nothing has changed that is a recent change. I don’t think anyone has reported anything like this.
Even when it’s lagging really badly usually nothing like you’re saying or even close to that happens. Everything is kind of just stuck but it sounds like on yours things are going bonkers / actually moving really weird like that. Very strange indeed, thanks for letting me know regardless so I can investigate!
Moses
Hahaha i know right?!
If you try it out, let me know how it ended up. If didn’t get any of these issues then it might be wrong with my Raspberry Pi or the SD card (even though the SD card is new and not a fake one). 🙂
H4what
It’s working great so far, but how do you get it to run on boot/when the Pi is powered on?
putting in the name you entered for your server when you ran SetupMinecraft.sh. It should ask you as one of the questions if you want to run it at startup so you do have the option of running SetupMinecraft.sh again to set up the service again.
One of those should definitely get it going and let me know if you have any trouble!
The best way is to use a SSD but I’m sure that’s not what you meant. I wanted to put that out there first to just say that will make the biggest difference for sure. Assuming you mean by without throwing money at it though there are definitely a few things you can do.
The slow chunk loading is the worst / most noticeable when it’s generating new chunks. You will especially see this if you are flying around the server in a place nobody has ever gone before. It can get very behind to where you can almost reach the edge when it’s really bad before chunks will start appearing.
Once these have been generated if you try flying back over the same area you will see that it does much better. It still won’t be perfect as you’re hitting some IO limits but it really is like 90% better if the chunks already exist.
With that background solution #1 that is pretty common is to pregenerate all of the chunks on your server. This involves using a plugin like you could use Chunky Pregenerator for this. You basically generate all of the chunks at once and get it “over with” for a defined area. This will dramatically reduce the chunk loading times to have them already available where it just has to fetch them from the disk.
Solution #2 is a little uglier in my opinion. The other think you can do to reduce the load is reduce the server view distance. This is a quality of life reduction and my script actually runs at full view distance 10 for that very reason. It’s an option though if moving to something like a SSD is not an option and pregenerating is not making enough of a difference (it should for most people). You could definitely experiment though with cutting the view distance (which won’t load chunks that are as far out). I call this the “nuclear option” for performance as well. You won’t be able to see as far in game, but it definitely works if you have to.
Hopefully one of those two easy ones will get it for you!
hi, thanks for the ideas you gave me! but before i do that i wanted to try out box64 and see if its any good but i keep getting an error saying “/lib64/ld-linux-x86-64.so.2: No such file or directory” is there maybe a way to fix this? If not i wont mind going to load the chunks. I also followed some articles, the install is successful but starting the server is not. Thanks again.
I don’t have a step by step for this method unfortunately as this is just what some people used who needed it to run faster than it does in regular QEMU. I’m guessing just like QEMU there’s several ways to configure it. It looks like from that link you can use the static binary (that’s why I do for this script) or you can use the dynamic one but I’m guessing that will need more configuration.
Your error message specifically means it can’t find the x86_64 libraries. That means it’s probably not running through box86 as you will need to change your Minecraft startup line to use it. QEMU uses binfmt-tools to basically just let you “run” any binary but I’m guessing with box86 you will need to run it with box86 and not just run it from the CLI normally.
There are several others that have commented here about box86 and some have posted some guides. I’ve actually never done this for the Minecraft server (I didn’t have a need but others needed more performance) but several people have told me it 100% solved their problem though and it ran fast enough after that. If you type “box86” in the comment search box above these comments I think you’ll probably find some more detailed steps for sure (several of them wrote up instructions if I recall correctly, if not let me know and I will see if I can find them on here as they may have been posted on the main Bedrock article but I think they were here off the top of my head).
I’ve watched this go from absolutely impossible to run to on the Pi 3 to very nearly possible (and fast enough for some people) on the Pi 4. It’s *almost* good enough but still chunks a little bit too much for more than a few players on at once. I fully expect the next Pi to run it fine using QEMU just judging from the pace of how it has improved over the years.
I can’t really help with the step by step configuration though for it as I don’t really use this method for this script or at home but I think you’re probably really close. My goal was to make the script as simple as possible for people to use and box86 would have made it several times more complicated at least. It was the opposite direction I wanted to take the script basically as I wanted to keep it running pure vanilla with as *little* emulation as possible if that makes sense. If I had to do this though to meet those requirements I would have but QEMU’s speed has been improving by leaps and bounds both due to the hardware advancements of the Pi and the software advancements of them updating QEMU’s emulation engine.
It probably just needs a tweaked startup line or an additional dependency installed. It’s definitely more configuration and more tricky though which is why I vastly prefer the QEMU way but there’s no question that box86/box64 is faster for emulating the server right now in 2022 and is still one of the absolute best solutions for running on ARM.
A good place to start would be the box86 homepage which has instructions configuring it for the Pi. You don’t necessarily need to follow a Minecraft specific box86/box64 guide as it’s more important that you get the overall environment configured correctly. Once that happens everything else should fall into place.
It looks like there’s 32-bit vs 64-bit trickiness:
Because Box86 works by directly translating function calls from x86 to host system, the host system (the one Box86 is running on) needs to have 32-bit libraries. Box86 doesn’t include any 32-bit <-> 64-bit translation. So basically, to run Box86 on, for example, an ARM64 platform, you will need to build Box86 for ARM 32-bit, and also need to have a chroot with 32-bit libraries.
If you look at a 64bits version of box86, look at Box64: this one is able to run x86_64 binaries on 64-bit platforms. But note that you still need Box86 (and a 32-bit chroot) to run x86 binaries (as it also happens on actual x86_64 Linux that need x86 libs and binary on multiarch to run).
My guess is that this will be easier if you’re running a 64-bit architecture (aarch64 or arm64 instead of armhf which is 32-bit). You probably aren’t, most people are running 32-bit Raspberry Pi OS and other operating systems as it’s usually one you have to “choose” to get and isn’t the default (most distros have a 64 bit version though including Raspberry Pi OS and Ubuntu). It may actually be a requirement from what I’m seeing. I have a guide on where to get the 64-bit Raspberry Pi OS image if you wanted to try this. The Bedrock server itself is a 64-bit binary and is not a 32-bit binary for what it’s worth.
It looks like the problem is that they actually call the 64-bit version of box86 “box64”. I’m certain you need the 64-bit version or box64 after reading the requirements on box86’s home page I linked. If today is your lucky day you may just need to swap out box86 for box64 (especially if you already have a 64-bit OS installed).
This is pretty important as the bedrock binary will not even run in 32-bit mode at all. It doesn’t have any 32-bit compatibility built in and they expect you to be running Ubuntu x86_64 as the only officially supported platform (if Microsoft distributed an arm version it would be a cakewalk to run normally, only they can decide to provide this though). I get the impression box64 doesn’t work on 32-bit ARM so a reimage may be required to a 64-bit OS version/architecture.
I did find one of the old comments and they are indeed using box64 here so I bet this is the problem.
Hopefully those at least point you in the right direction though!
hi,
That helped a lot but it came up with a new error lol. Says something about run the program natively (using box86). So i think ill just use the script you made. Its so much easier and loading a few chunks is probably fine. I was using the OS ubuntu 20.04 with an arm64 CPU. The device/machine i was using is actually a VPS with an ARM CPU. I thought bedrock would still work anyway. Ill try using Linux this time and see if it makes any difference.
That sounds right to me especially for the Pi 4 with more than a couple of people online I would say. There is a way to make it faster using Box64 if you have any more events you need to do. That has come up a lot here in the comments and people have had great success even with multiple people if you add in the Box64 piece.
Thanks for letting me know your experience!
Rajiv
I tried the Box64 method Ishaan mentioned and it worked great on rasberry pi 4b (4gb).
The perfomance is quit well with 4 appliences.
When i tried the auto install script the server was just not workable for normal use with 4 childeren :).
Thanks for stopping by and sharing your experience! This sounds right to me, especially with 4 people. My guess is the next Pi will be able to do this okay but for now I think you are doing the best approach possible using box86.
Hi, when I start the server, I get this error message:
sudo LD_LIBRARY_PATH=. ./bedrock_serverERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
best regards, Ingo
Hey Ingo,
Welcome! If I were to guess from similar issues people had it’s probably that this Pi is running Debian Buster or an older version and not Bullseye. Looks like ARM 32 bit which should be fine here.
It looks like that version of QEMU is throwing a bunch of warnings which definitely means it’s an older version of QEMU available on there. Those warnings are all fixed in the latest version.
I would recommend trying the Docker version for sure on that one. The Docker version uses the version of QEMU from ubuntu:latest so it’s always the newest no matter what is available in apt. Upgrading to Bullseye will work too as I had just fixed the standalone version a week or two ago and we had people successfully using it.
There’s a lot of people in this situation now because Raspberry Pi OS doesn’t automatically upgrade to the newest release (not even with sudo apt dist-upgrade) and Bullseye only was released earlier this year. That means anyone who imaged their Pi before about April of 2022 doesn’t have Bullseye. You have to actually edit the apt sources to get it to upgrade but to be honest I usually just reimage the SD for them as I’ve found the upgrades sometimes have weird issues when you edit the apt sources manually that disappear when I do a clean image on them with the latest.
I think either upgrading or trying with Docker would get it working on this one. Hopefully that helps!
Hi, thanks a lot, it worked! It seems that Raspbian was not the latest version. I started with a clean install and now I got it up running 🙂
Hey Ingo,
No problem at all, you are very welcome and thanks for letting me know that worked for you since that helps and others reading this as well. Enjoy and have fun!
This has now been updated with Box64 for both Docker and the standalone versions! This should speed things up. If you’re already using the standalone version run the update.sh script from your server folder and it will get you to the Box64 updated version.
For Docker users do:
docker pull 05jchambers/legendary-bedrock-container:latestNote that for this to make a difference you need to be running a 64 bit OS. Both Ubuntu and Raspberry Pi OS have 64 bit versions available. A quick way to check this is if you do a:
uname -myou should get aarch64 if you are on 64 bit ARM. Anyone on the Pi should give the updated version a try!
is there a way to either stop the backups or change the storage device they save to?
Hey Glitcher,
Great question, it has been a while since this has come up but other people have asked how to do this before! Basically all of the magic for backups happens in start.sh. To disable the backups altogether you could remove this section:
# Create backupif [ -d "worlds" ]; then
echo "Backing up server (to minecraftbe/servername/backups folder)"
if [ -n "$(which pigz)" ]; then
echo "Backing up server (multiple cores) to minecraftbe/servername/backups folder"
tar -I pigz -pvcf backups/$(date +%Y.%m.%d.%H.%M.%S).tar.gz worlds
else
echo "Backing up server (single cored) to minecraftbe/servername/backups folder"
tar -pzvcf backups/$(date +%Y.%m.%d.%H.%M.%S).tar.gz worlds
fi
fi
That starts at line 69 in start.sh and you can open the file with a text editor and delete that entire section and backups will be gone. A more popular change though is to change the backups from 10 to 1 (so you at least have one backup while saving the maximum amount of space). You can do that by changing this line:
# Rotate backups -- keep most recent 10Rotate=$(
pushd dirname/minecraftbe/servername/backups
ls -1tr | head -n -10 | xargs -d '\n' rm -f --
popd
)
Here you can change the head -n -10 to how many backups you want. head -n 1 would only keep a single backup. Hopefully that helps!
Hi James,
This is some real quality work. I thank you for your time documenting it and writing it. Everything went fine but the server wouldn’t start.
bedrock_server: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory
And I noticed no libcurl.so.4 had been copied to local directory. So I copied it over. Same result. I compiled a c program and linked that library in and called the curl_version_info function and dumped it out
lib curl version 7.74.0
So the .so file seems okay. Running bedrock_server these two ways produces
pi@raspberrypi:~/mcserver/bedrock/minecraftbe/mcbedrock $ ./bedrock_server./bedrock_server: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory
pi@raspberrypi:~/mcserver/bedrock/minecraftbe/mcbedrock $ LD_LIBRARY_PATH=. ./bedrock_server
./bedrock_server: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory
So it seems to be finding other .so in that directory okay. You have any suggestions?
Thanks,
BBB
Hey bittramp,
I’m investigating now and I think Microsoft changed the dependencies in the newer version.
Old version linking (1.18.33.02):
james@jamesgigabyte-linux:~/minecraftbe/james/downloads$ ldd bedrock_serverlinux-vdso.so.1 (0x00007ffd62dfb000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56e7f30000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f56e7f14000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f56e7e7c000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f56e7ba1000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f56e7b9c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f56e7b95000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f56e7aae000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f56e7aa9000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f56e787d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f56e785d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f56e7635000)
/lib64/ld-linux-x86-64.so.2 (0x00007f56e7f6d000)
New version linking (1.19.10 – unofficial codename “libssl linking hell version”):
james@jamesgigabyte-linux:~/minecraftbe/james$ ldd bedrock_serverlinux-vdso.so.1 (0x00007ffd075c6000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f6c4f858000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f6c4f7c0000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f6c4f4e5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6c4f4e0000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6c4f4db000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6c4f3f2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6c4f3ed000)
libcurl.so.4 => /lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f6c4f347000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6c4f11b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6c4f0fb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6c4eed3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6c4f895000)
libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f6c4eea7000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f6c4ee86000)
librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f6c4ee67000)
libssh.so.4 => /lib/x86_64-linux-gnu/libssh.so.4 (0x00007f6c4edfa000)
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f6c4ede6000)
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f6c4ed42000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f6c4e8fe000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f6c4e8aa000)
libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 (0x00007f6c4e84b000)
liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0 (0x00007f6c4e83a000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f6c4e76b000)
libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f6c4e75d000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6c4e73f000)
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f6c4e595000)
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f6c4e3aa000)
libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007f6c4e362000)
libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007f6c4e31c000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f6c4e298000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f6c4e1cd000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f6c4e19e000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f6c4e198000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f6c4e18a000)
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f6c4e16d000)
libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f6c4e14a000)
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f6c4e00f000)
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f6c4dff7000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f6c4dff0000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f6c4dfda000)
libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007f6c4dfcd000)
My goodness, there are literally like twice as many linked dependencies, what a mess! I think this is the culprit:
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f6c4ed42000)It looks like it’s time to move to libssl3 because the new version seems to be linking against that (along with a bunch of other new dependencies, any one of these which could explain this).
I’ll get some updates going here!
I added libssl3 to the dependencies. Can you try running SetupMinecraft.sh again now to install the latest version?
Hey, thanks for checking. Getting syntax error with script now.
Hey bittramp,
That should be taken care of now here!
Still has the libcurl dependency error. Doesn’t look like depends.zip has changed checking a diff from previous attempt.
Hey bittramp,
You’re right, I actually just *barely* updated depends.zip here about 15 minutes ago! I knew exactly what to add after fighting with the Docker container version last night and getting that one working. The changes are pretty wild. It’s about 3x bigger which is almost exactly what we would expect from 3x the dependencies as any previous version has ever had.
The depends.zip should be changed now when you have a chance to give it a try here! I’m not 100% sure everything it needs will be in there as on the Docker container version there were 2 additional dependencies that weren’t even listed in ldd as dependencies but were still needed. I’m still catching up / in a scramble here but let me know if you get any more additional errors!
That worked like a charm! Thanks for your help!
Hey bittramp,
No problem at all, thanks for your patience and willingness to try so many times through the various fixes. Take care and enjoy!
I tried the Box64 method Ishaan mentioned below, and it works great (kinda). However I noticed that some stuff is broken for some reason. For instance whenever I try to row a boat, it just sinks, so we can’t use it. Also the player skin is always invisible, which can cause some strange glitches etc. Am I the only one who have these issues?? I do have a Raspberry Pi 4b with 8GB, and I still have these issues :/
Hey Moses,
That is strange behavior for sure.
I actually found a thread on reddit with a bunch of replies from 3 months ago on this. It seems like this is a thing.
Some people are saying that the 1.18.3 release will fix it in that thread (or if we are unlucky they mean the prerelease after 1.18.3). At any rate I’m certain this has nothing to do with this script, your Raspberry Pi or memory or anything like that. It looks like this is just a really weird bug in the current version and that it has already been patched in the new betas (according to people on reddit at least)!
The thing is that the video shown in that Reddit link, they can at least board and row the boat. I can’t even do that due to, as soon as I board the boat, it just sinks… Like it goes underwater. And when it’s under the water it just ejects me from the boat. So I can’t row anywhere with it :/
And again I have the same issue with the players skin being invisible. Can’t see the characters hands or what I’m holding.
I have no idea why this even happens xD
Hey Moses,
I agree with you. I even searched to see if anyone had ever even filed a bug like this. Nobody ever has. No invisible skin. No nothing even close.
I’m not sure what is going on here but nobody has ever reported anything like this outside that thread I linked on reddit. I searched for “open” and “in progress” issues and I believe that reddit bug is supposedly fixed already.
Do you have any other computers to run the client on or any other multiplayer servers you can connect to? It’s such a weird issue that I think you probably need to rule some things out here and make sure we’re looking in the right places. If you run the Minecraft client on another computer and connect does this still happen?
We’d also be looking for things like does this happen if you run the server on a PC, or can you recreate it by connecting to another multiplayer world? You’d want to actually connect to another multiplayer server to test this and not just run it in offline mode as maybe the problem is with the skin cache on the client or something really weird like that. It could even be network/firewall related and this test will also check that as you will see it if it is.
I think we need to probably narrow things down kind of like I’m describing above here. Does it happen if you start a completely fresh server? That would indicate the server is corrupted perhaps but usually you will be getting error messages all over the place when this is the case but it’s possible.
You may have checked some of these things already in our replies but we need the big picture (to put it all together in one place) especially since it’s a weird issue that nobody else is really saying they have (meaning we need to double check a whole bunch of things). Can you check those things and let’s see if we can narrow it down!
Hi again James!
Thank you for the reply,
Well then I’ve tried to host a Bedrock server in both Windows and Linux Mint. Everything works great when I join, in mobile, Computer etc. The issue is when I try to host a Bedrock server in Raspberry Pi itself for some reason.
And yes everything is completely a fresh install. What I did was:
1. Used Raspberry Pi Imager.
2. Installed the latest Raspberry Pi OS 64-bit (not the Beta. The have released an official 64-bit).
3. Followed Ishaan’s method.
4. Host the server
5. Baaam the issue is still there for some reason.
So yeah everything is freshly installed, even the OS. I tried to reinstall the OS 3 times now, still have that specific problem.
Now when I think about it, could it be possible that the Raspberry Pi OS 64-bit itself might be the problem in this case?
Should I try the Ubuntu server instead? And if I try that, could I use the one from Raspberry Pi Imager or should I use the one you linked?
If I use the one you linked, which Ubuntu server version works the best? 20.04 or 20.10? 🙂
Hey Moses,
Great questions, and you answered all the questions I was wondering! So basically yes I would try on Ubuntu 20.04 first (the 64 bit version). That is the version I made the script for on Raspberry Pi (or at least generated the dependencies on which is probably the more important part here).
I think there’s an excellent chance this will get it. I didn’t realize you were running the regular Raspberry Pi OS. I would definitely give Ubuntu a try and let’s see if that gets it for you here!
Hi again James!
I just installed Ubuntu Server 20.04 from the Raspberry Pi Imager and the installation worked fine.
HOWEVER when following Ishaan mehtod again, the EXACT same issue still remains. I can’t row the dam boat, and the characters skin is invisible. I don’t know what else to do.
I have a good internet connection (100/100 fiber) i’ve tried both Wifi and using the cable and the MicroSD card i use is the SanDisk MicroSD Extreme Plus 64GB. I’ve even tried other MicroSD cards, same issue…
I don’t know what else to do xD
I’ll think i just give up since it clearly is something strange and i can’t figure out why :/
Hey Moses,
That is very strange! I’ll definitely fire mine up here and make sure that nothing has changed that is a recent change. I don’t think anyone has reported anything like this.
Even when it’s lagging really badly usually nothing like you’re saying or even close to that happens. Everything is kind of just stuck but it sounds like on yours things are going bonkers / actually moving really weird like that. Very strange indeed, thanks for letting me know regardless so I can investigate!
Hahaha i know right?!
If you try it out, let me know how it ended up. If didn’t get any of these issues then it might be wrong with my Raspberry Pi or the SD card (even though the SD card is new and not a fake one). 🙂
It’s working great so far, but how do you get it to run on boot/when the Pi is powered on?
Hey H4what,
Glad to hear it’s working well! Try doing a:
sudo systemctl enable yourservernameputting in the name you entered for your server when you ran SetupMinecraft.sh. It should ask you as one of the questions if you want to run it at startup so you do have the option of running SetupMinecraft.sh again to set up the service again.
One of those should definitely get it going and let me know if you have any trouble!
It worked really well 😀 but is there maybe a way to speed up chunk loading a little. Thats my only issue
Hey nj165,
The best way is to use a SSD but I’m sure that’s not what you meant. I wanted to put that out there first to just say that will make the biggest difference for sure. Assuming you mean by without throwing money at it though there are definitely a few things you can do.
The slow chunk loading is the worst / most noticeable when it’s generating new chunks. You will especially see this if you are flying around the server in a place nobody has ever gone before. It can get very behind to where you can almost reach the edge when it’s really bad before chunks will start appearing.
Once these have been generated if you try flying back over the same area you will see that it does much better. It still won’t be perfect as you’re hitting some IO limits but it really is like 90% better if the chunks already exist.
With that background solution #1 that is pretty common is to pregenerate all of the chunks on your server. This involves using a plugin like you could use Chunky Pregenerator for this. You basically generate all of the chunks at once and get it “over with” for a defined area. This will dramatically reduce the chunk loading times to have them already available where it just has to fetch them from the disk.
Solution #2 is a little uglier in my opinion. The other think you can do to reduce the load is reduce the server view distance. This is a quality of life reduction and my script actually runs at full view distance 10 for that very reason. It’s an option though if moving to something like a SSD is not an option and pregenerating is not making enough of a difference (it should for most people). You could definitely experiment though with cutting the view distance (which won’t load chunks that are as far out). I call this the “nuclear option” for performance as well. You won’t be able to see as far in game, but it definitely works if you have to.
Hopefully one of those two easy ones will get it for you!
hi, thanks for the ideas you gave me! but before i do that i wanted to try out box64 and see if its any good but i keep getting an error saying “/lib64/ld-linux-x86-64.so.2: No such file or directory” is there maybe a way to fix this? If not i wont mind going to load the chunks. I also followed some articles, the install is successful but starting the server is not. Thanks again.
Hey nj165,
I don’t have a step by step for this method unfortunately as this is just what some people used who needed it to run faster than it does in regular QEMU. I’m guessing just like QEMU there’s several ways to configure it. It looks like from that link you can use the static binary (that’s why I do for this script) or you can use the dynamic one but I’m guessing that will need more configuration.
Your error message specifically means it can’t find the x86_64 libraries. That means it’s probably not running through box86 as you will need to change your Minecraft startup line to use it. QEMU uses binfmt-tools to basically just let you “run” any binary but I’m guessing with box86 you will need to run it with box86 and not just run it from the CLI normally.
There are several others that have commented here about box86 and some have posted some guides. I’ve actually never done this for the Minecraft server (I didn’t have a need but others needed more performance) but several people have told me it 100% solved their problem though and it ran fast enough after that. If you type “box86” in the comment search box above these comments I think you’ll probably find some more detailed steps for sure (several of them wrote up instructions if I recall correctly, if not let me know and I will see if I can find them on here as they may have been posted on the main Bedrock article but I think they were here off the top of my head).
I’ve watched this go from absolutely impossible to run to on the Pi 3 to very nearly possible (and fast enough for some people) on the Pi 4. It’s *almost* good enough but still chunks a little bit too much for more than a few players on at once. I fully expect the next Pi to run it fine using QEMU just judging from the pace of how it has improved over the years.
I can’t really help with the step by step configuration though for it as I don’t really use this method for this script or at home but I think you’re probably really close. My goal was to make the script as simple as possible for people to use and box86 would have made it several times more complicated at least. It was the opposite direction I wanted to take the script basically as I wanted to keep it running pure vanilla with as *little* emulation as possible if that makes sense. If I had to do this though to meet those requirements I would have but QEMU’s speed has been improving by leaps and bounds both due to the hardware advancements of the Pi and the software advancements of them updating QEMU’s emulation engine.
It probably just needs a tweaked startup line or an additional dependency installed. It’s definitely more configuration and more tricky though which is why I vastly prefer the QEMU way but there’s no question that box86/box64 is faster for emulating the server right now in 2022 and is still one of the absolute best solutions for running on ARM.
A good place to start would be the box86 homepage which has instructions configuring it for the Pi. You don’t necessarily need to follow a Minecraft specific box86/box64 guide as it’s more important that you get the overall environment configured correctly. Once that happens everything else should fall into place.
It looks like there’s 32-bit vs 64-bit trickiness:
My guess is that this will be easier if you’re running a 64-bit architecture (aarch64 or arm64 instead of armhf which is 32-bit). You probably aren’t, most people are running 32-bit Raspberry Pi OS and other operating systems as it’s usually one you have to “choose” to get and isn’t the default (most distros have a 64 bit version though including Raspberry Pi OS and Ubuntu). It may actually be a requirement from what I’m seeing. I have a guide on where to get the 64-bit Raspberry Pi OS image if you wanted to try this. The Bedrock server itself is a 64-bit binary and is not a 32-bit binary for what it’s worth.
It looks like the problem is that they actually call the 64-bit version of box86 “box64”. I’m certain you need the 64-bit version or box64 after reading the requirements on box86’s home page I linked. If today is your lucky day you may just need to swap out box86 for box64 (especially if you already have a 64-bit OS installed).
This is pretty important as the bedrock binary will not even run in 32-bit mode at all. It doesn’t have any 32-bit compatibility built in and they expect you to be running Ubuntu x86_64 as the only officially supported platform (if Microsoft distributed an arm version it would be a cakewalk to run normally, only they can decide to provide this though). I get the impression box64 doesn’t work on 32-bit ARM so a reimage may be required to a 64-bit OS version/architecture.
I did find one of the old comments and they are indeed using box64 here so I bet this is the problem.
Hopefully those at least point you in the right direction though!
hi,
That helped a lot but it came up with a new error lol. Says something about run the program natively (using box86). So i think ill just use the script you made. Its so much easier and loading a few chunks is probably fine. I was using the OS ubuntu 20.04 with an arm64 CPU. The device/machine i was using is actually a VPS with an ARM CPU. I thought bedrock would still work anyway. Ill try using Linux this time and see if it makes any difference.
Anyways just tried Linux, didn’t work. So looks like ill use the script
Hey nj165,
Sounds good, let me know how it turns out here!
hi,
I used it has a temp event server just to see how it runs and it seems like everyone was lagging including mobs.
Hey nj165,
That sounds right to me especially for the Pi 4 with more than a couple of people online I would say. There is a way to make it faster using Box64 if you have any more events you need to do. That has come up a lot here in the comments and people have had great success even with multiple people if you add in the Box64 piece.
Thanks for letting me know your experience!
I tried the Box64 method Ishaan mentioned and it worked great on rasberry pi 4b (4gb).
The perfomance is quit well with 4 appliences.
When i tried the auto install script the server was just not workable for normal use with 4 childeren :).
Hey Rajiv,
Thanks for stopping by and sharing your experience! This sounds right to me, especially with 4 people. My guess is the next Pi will be able to do this okay but for now I think you are doing the best approach possible using box86.
Take care and have fun (or at least the kids)!