Container exits immediately after starting #1
Comments
|
Hey Mootch, I was surprised by this but when I tried the image on Raspberry Pi as is it "just worked" on my Pi 400: After this the console loads normally. Do you get that same platform based warning for the image? Was it for aarch64 instead of arm? I thought this Pi was running the 64 bit flavor of Raspberry Pi OS but apparently it's not. I would expect the 32 bit version to have even less of a chance of working though. I did find this: https://stackoverflow.com/questions/67458621/how-to-run-amd64-docker-images-on-arm64-host-platform It sounds like this should be possible period (through the Rosetta engine) but you may have to use a modified startup launch line. I'm not sure why you would have to use it and I didn't encounter this but it does look like it's a thing. The modified startup would be something like:
If this works let me know and I will definitely add this to the documentation. Mine launched normally again with this but it no longer had the warning about there not being an ARM image. My volume name was "minecraft2" so you'd replace that with your volume. I also tried a volume3 to make sure it worked from scratch. Thanks for investigating and reporting this! |
|
Thanks for the response. Adding the |
|
Thank you for following up with this on me and being my first issue / feedback I've got for the container! I'm not sure why I didn't need it either. It could be that if you are running it on 32 bit then Docker makes some assumptions that it doesn't make on 64 bit. It could also be Docker defaults or configuration related meaning whoever packaged our distro's package could be influencing some tiny setting that does whatever mine did automatically and that isn't present in your version/distro/package. I'll definitely get this added to the documentation. Undoubtedly other people have already encountered this as I think the likelihood of people reporting / filing issues is probably less than 10% and maybe even a lot less than that. Thanks a ton! |
|
I found a better way to do this. I am basically doing it for you in the Dockerfile now with: to: So theoretically you should no longer need that parameter. Thanks again! |
|
Thanks for looking into this. I'll try it with the update when I get a chance. |
|
Hello I just pulled the image but I'm getting this on my RPI 4: According to your blog post comment (https://jamesachambers.com/legendary-minecraft-bedrock-container/#comment-13460) this shouldn't happen with the latest version, but apparently it still do. Adding Maybe this can help: |
|
Can you try the following commands: It's your packages I think. From https://docs.docker.com/desktop/multi-arch/ : My guess is your system is missing binfmt-support or possibly qemu-user-static. Can you try that and let's see if it works after that! I found more requirements here: https://medium.com/@artur.klauser/building-multi-architecture-docker-images-with-buildx-27d80f7e2408 I think you may have finally helped me solve this mystery. It appears for it to run smoothly on ARM you need qemu-user-static and binfmt-support installed via Let me know if this takes care of it for you as it will need to be added to the documentation that when running on ARM you need these packages to run multiarch images! I found some documentation saying that this can work if I install it myself inside the container and that it isn't "required" on the host system if done that way. I just added this. Can you try pulling the latest and running again? |
|
Thanks for all the suggestions! I started with this Furthermore it takes forever to connect to the server, I'm stuck on "connecting to server...". 1 time it connected after several minutes, but I haven't had success since. Installing qemu ( You also asked me to try this and now the minecraft docker container won't start either :-( I'm gonna start over removing the container and image and re-pulling the image now. |
|
Not going well this time again |
|
I re-installed |
|
Thanks for your investigation into this! Can you do a: My Ubuntu 20.02 desktop gives 6.2.0 and my Raspberry Pi gives 5.2.0 for the QEMU version. I suspect that this is significantly older than that. I remember seeing these errors years ago when Raspberry Pi was on an older version of QEMU like that. It doesn't actually hurt anything to have those warnings I'd remove qemu, qemu-user-static and binfmt-utilities now and try running the container and let it use my versions (definitely newer). I'm not sure if this will work yet but the documentation I read said it could work to have them on either side. Mine looked like this: No warnings with this QEMU version. I'd like to see if it can get it working with the built in one. I'm going to remove QEMU from my Pi and try to do it from the container side. I'm not sure if this will work yet but I read that it should. If it does then you would delete that old version your OS installed and just let it use mine from the latest Ubuntu. Let's see what yours looks like here! |
|
I redesigned the entire container around this issue. Thank you to everyone for reporting this. Now there actually is an image. For each platform! Go ahead and do a:
and now it will select the right image for your platform. Can anyone who was having trouble with this give the latest one a try? |
You're right, it's a really old version! So I removed the container, qemu, qemu-user-static, binfmt-support and started over: The error messages are gone, but the server seem to fail. |
|
Forgot this |
|
Dunno if this is useful to you |
|
Hey cenobitedk, Great, that helps! So basically I uninstalled qemu on my Pi as well as binfmt-utils. It took about 9 hours of constant failed builds but it doesn't use your system's QEMU at all anymore. It's just built in basically. I did this to get around the system QEMU being old (or not present). I don't want this to be a requirement. It's all self contained now and there's separate images for each. I assume you did pull the latest here as you would still be getting that platform warning on the older version. Is this real Debian? I assume it is because my cat /etc/os-release does say Raspbian. It may be worth it for you to upgrade to Bullseye. This is pretty easy. You pretty much just edit your apt sources.list file and then let apt upgrade it. There's a guide on how to do this here: https://www.cyberciti.biz/faq/update-upgrade-debian-10-to-debian-11-bullseye/ There's another possibility. Maybe something isn't set up quite right for aarch64 and I haven't tested this yet. I'm positive with armv71 (32 bit) that you don't need QEMU as I completely deleted it from my system and none of that stuff we talked about earlier applies anymore (it's all done in the container). I'm mentioning upgrading your OS though because I wonder if it is potentially Docker version related. Like my Docker on my Pi is giving this version: The containers are all built on x86_64 using QEMU which means it must be working to build the image (otherwise it fails). That's why my mind is running to these other things as well. I think I may need to do a aarch64 install just to confirm this! I have a Pi next to me that's not being used and may already have a 64 bit install on it so I will definitely try with aarch64 today to see if this is architecture related or not! |
Yeah it's Raspbian. I'm not 100% sure but I'm almost certain that I followed your guide here: https://jamesachambers.com/where-to-get-the-64-bit-raspberry-pi-os-image-for-pi-4-400/ Sounds like upgrading would be ideal. However, this PI is also running my Home Assistant and Unifi Controller along with Esphome, Mosquitto and Portainer (all as containers), so I'm reluctant to just do the upgrade right away. I don't have a good backup solution running so if it goes down I'm screwed. As you know, RPi's are not in abundance currently, so I only have this RPi 4 currently (except for an old RPi (1) Model B). But I believe a RPi 3 would also do the job if I can find one used, right? Btw, my docker version is good. |
|
Hey cenobitedk, I'm glad you brought this up because when I went downstairs to connect my Pi the air conditioners draining pipe had backed up and there was about 1/2 an inch of water right by all my cryptocurrency miners (it actually got a couple of my wife's wet, I told her not to leave them on the floor!). I've got that under control and just powered on the Pi and am going to try here on aarch64 and see if I can figure out what the problem is here! |
|
Okay, I did a completely clean install today and I can confirm I'm seeing a problem here. It's not you (and I suspected as much which is why I busted out the test device). I will get it working and then post a followup for aarch64! |
|
Alright, I finally have it here. It wasn't easy but I think it may have fixed it for more than just aarch64. Can you do a docker pull and try running now? |
|
I pulled the latest version and works great! No error messages or anything! Great work, thank you! Only problem I have no is that it takes forever to load the game when connecting, and I quickly see unrendered areas. I'm suspecting IPv6 to be an issue, but I'm not sure at all. I'll try to get my docker env to support IPv6 |
|
Hey cenobitedk, That is great news, thank you so much for following up and letting me know that got it for you! So the speed of this is going to vary widely depending on the ARM device. Anything that isn't x86_64 does have a layer of emulation. On the latest container this is only bedrock_server. The container's OS and architecture are now native. The devices that will do the best are probably ones with lower core counts and higher clock speed. While Minecraft Bedrock isn't single threaded it is considered single "cored" meaning most of the game logic is in fact only using one CPU core. Unfortunately the Pi 4 for example is a device with 4 low powered cores. The 4 cores are usually great but Minecraft is not great at leveraging the additional cores like I mentioned. It would actually be better if the Pi was dual cored with higher single core clock speeds (and Minecraft is not the only software that likes lower core counts with high clock speeds). Despite this the most important thing you can do to improve performance on the Pi is to switch to a SSD. The SD card is likely your bottleneck (assuming you are using one). This is the one thing in your control you can do basically. It still won't be perfect on a Pi 4 though. I'm expecting the Pi 5 to be pretty much perfect though as it will address a lot of the current bottlenecks. If Microsoft would release a native ARM dedicated server build this would completely solve it. It's the emulation + the SD card that you are hitting when you are travelling quickly across the world. What you are literally seeing is the Pi waiting to generate the new chunks and write them to disk (this is why a SSD helps especially with the specific lag you are seeing). I'd be curious if the networking has any impact. My guess is that the bottlenecks are what I was saying earlier based on my experience from my previous project (which can run it natively on the Pi in the standalone version but with the same limitations). Overclocking the Pi's CPU does have a noticeable impact. If you have a SSD then the CPU becomes the bottleneck. It's pretty easy and safe to overclock these. If you want to try this I frequently use the "middle" overclocking settings on my Pi 4s without really any incident or instability: https://www.seeedstudio.com/blog/2020/02/12/how-to-safely-overclock-your-raspberry-pi-4-to-2-147ghz/. This person takes it to several different overclocking levels and if you pick the lower or medium ones you can get some "free" performance gains from this. If you go too high you want some sort of cooling case / airflow. Hopefully that gives you some ideas on where to start! |
|
Thank you so much, this is really helpful! I'm actually running the system on a 64GB Sandisk Flash disk and not the SD card. However, I do experience some kind of bottleneck and most specifially when pulling docker images. It starts off in great speed and then drops to something that reminds me of 56K modem, so sometimes it takes forever to pull images. I'm currently running machine with passive cooling and it's around 50° celcius, so that works great, but I'll see what happens with overclocking. Could be interesting to try. Btw, we can move the speed talk to another issue if you want, now the core problem is fixed. |
|
No problem at all! I actually have a specialty site for benchmarking storage for the Pi at https://pibenchmarks.com. It's basically a one-liner to run the benchmark (at the top of the site). You're definitely on the right track here. The Docker pulling you are seeing is also bottlenecking. It does feel like a 56K modem when it starts doing this. When I did my testing I used a SD card so I got a little bit of this too. It's very "spotty" where it will bottleneck and get stuck for a while then it will seem to go back to full speed again. This is definitely some bottlenecking. Unless the SanDisk flash drive is one of their SSD models (basically these look like USB thumb drives but are actually real SSDs) it is very likely to perform about the same or possibly slightly worse than a SD card. I may be able to use a different emulator than QEMU to speed things up as well but the bottlenecking on storage will not go away from this (it would help with the CPU load though). This would be called box64 and it's only an option on aarch64 specifically. I'll be investigating this so stay tuned for further possible improvements (specifically for your architecture, I've been working on this problem a long time and know a few tricks I've picked up over the years for emulation). You can tell this won't solve it though from the fact you're still seeing the bottlenecking and rubberbanding effects while pulling Docker images and other disk i/o intensive activities. This is a Pi problem in general and why I created the storage benchmark. It was exceptionally difficult to tell how people's storage performance was on the Pi until this benchmark (and tens of thousands of tests later) we actually have hard data on this and can make comparisons. Definitely pibenchmarks.com will already have tests for your drive you can just search for as well. I think this will likely turn out to be a regular flash drive which are pretty slow (surprisingly so). Hopefully that helps as well! |
|
Running your benchmarking now. But I did some testing before and was getting horrible results! Write speed down to 2MB/s and Read speed down to 9MB/s. I really didn't realise the flash disk is this bad. :-( I'll definitely switch this one out as soon as possible. |
LOL! no wonder it feel slow |
|
Ahh yes, this was one of my misconceptions too before I made the storage benchmark. I knew it was a much lower grade of memory/storage they use in flash drives (compared to a SSD) but I had no idea it was roughly equivalent to a SD card and probably inferior to a A1 or A2 (application class) SD card (that literally is higher grade memory on a application class SD card than they use in these flash drives). Good stuff, I really think that will alleviate your bottlenecking to take care of that first. I'll probably be doing some stuff with the container side over the next few weeks to see what I can do via emulation with box64 and that will help everyone on aarch64 but I think more of your issue right now is the storage. It might not even feel too bad with that taken care of even without my changes. Thanks for testing it on there! We probably should make this a separate issue like you were alluding to as this is becoming a bit of a mess now but if you want to continue the conversation feel free to open one and we can keep this discussion in there for future reference / others to read! My blog is probably great for this stuff too as that tends to just be more of what people need help with or the interesting topics going on at the moment. People frequently drop in and out too and I'm usually pretty fast to respond on there! |
|
help; arm64, linux, ubuntu |
|
That's a permissions error. It needs to be ran as sudo (or you need to add your user to the docker group and configure the system so you don't need sudo) and it is not this issue. Yours isn't even getting this far. Yours isn't even downloading the container because it says 'permission denied' which is why it says no such file or directory when it tries to run it. The container can't be downloaded since that's a privileged location and this user hasn't been set up to access sudoless docker. Please open new issues going forward as I won't be responding further (I just said it was becoming a mess in here, there is no reason to put them in here like this thinking I'll just keep responding and I won't). When this different issue does happen and people search for it they are not going to find it since now it's wrapped up with this totally unrelated issue which is why we want to keep them separate as this is clearly not this. Nothing personal but I should have cut it off there a long time ago because now it's actively hurting the project/documentation and people are just dropping everything into one thread apparently (and you weren't the first). Let's separate these out for everyone's sake! |
The server is running very slowly, and logging in takes a long time.
My server is arm64
Equipment model CM311-1a-YST
CPU amlogic
Memory size 2 GB
Flash memory size 16 GB
|
|
CPU amlogic 1.9 GHz ， Cortex-A55， 4C/4T |
Hi,
I'm running a raspberry pi on Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-1052-raspi aarch64). I built a docker image from your dockerfile since the Docker Hub only has an amd64 image. When I start a container from the image, it appears to go through the set-up but then exits immediately. I don't see any specific error message when it exits. What should I be looking for to address this?
Thanks for putting this together!
The text was updated successfully, but these errors were encountered: