⚠️ Please do not mark Unreleased Versions as affected. You don't have access to them yet.

_{-- I am a bot. This action was performed automatically! If you think it was incorrect, please notify us on Discord or Reddit}

Shortly after posting it, I realized there was a dedicated section for BDS. — I'm unsure whether moving it to that section would be more appropriate but apologies for the headache.

The issue appears to be present on the latest release of The Wild Update. The client says it's using v1.19.0 while BDS itself is using v1.19.1.01 if I understand correctly.

Using the same setup, it works perfectly unless it is on AlmaLinux with XFS using ftype=0.

The 1.19 files can be downloaded from here: https://archive.geri.dev/bedrock_test_v2.zip

This still appears to be an issue in the latest BDS version (v1.19.2.xx) downloaded from https://minecraft.azureedge.net/bin-linux/bedrock-server-1.19.2.02.zip

I don't think mojang accept issues for linux distros other then ubuntu and I think another distro

Thank you for your report!
However, this issue is Invalid.

Only Ubuntu 18 and later versions are supported. 

Quick Links:
📓 Bug Tracker Guidelines – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 BDS Wiki – 📖 FAQs

I can confirm the issue presents itself on Ubuntu 22.04

Also had a hunch that it could have been due to the filesystems CRC setting but this does not seem to be the case. It seems to only fail if ftype=0 is specified when generating the XFS filesystem.

Hi

Does this issue still occur after updating to 1.19.22?

This ticket will automatically reopen when you reply.

This is still indeed an issue, though it seems like I was able to discover some more information.

On systems using XFS with the `ftype` flag set to `0` servers with these resource packs were no longer able to launch. 

Here is a download link to the testing files: https://archive.geri.dev/bedrock_test_v3.zip

For reference, here is what happens on all of our other nodes that are working, where we use different file system types or `ftype` `1`:

• Server logs: https://p.geri.dev/raw/zipifidoninihisemide

• Login screen: https://i.geri.dev/YWeRFLSgMhjX.png

• Inventory: https://i.geri.dev/XvsD2VxfAjIh.png

—

On a node with XFS and `ftype` 0, here is the startup crash: https://p.geri.dev/raw/lewipejokeficagoqifo

Out of curiosity, I tried disabling the resource/behaviour pack to see if that's the issue and it still crashed with the same log.

After poking around I found that simply removing the `level.dat` file allows the server to launch even when the resource/behaviour packs are enabled. 

I do not know much about the format of this file but from reading the wiki, it seems like experiments are stored here: https://minecraft.fandom.com/wiki/Bedrock_Edition_level_format#level.dat

After a closer look and a DIFF check, it does seem like the freshly generated `level.dat` file has none of the experiments: https://i.geri.dev/iuKaQpolLV7j.png (aside from some of the other, seemingly irrelevant differences)

Just to confirm, I checked in-game and indeed the resource/behaviour packs are not working without these experiments: https://i.geri.dev/9dGTxw3Dy0Om.png

I went back to check if these specific experiments were enabled for the packs that we reported before and that indeed appears to have been the case. 

Using a combination of hex editors and other 3rd party tools, I was able to modify the original level.dat to discover that in this case, the `gametest` experiment when it's set to `1` was causing this crash

Modifying the `level.dat` file to set this to `0` allowed the server to boot without crashes and the resource/behaviour packs worked without any issues as well.

For reference, here are all the files at the end of this test: https://archive.geri.dev/bedrock_test_v4.zip

—

Lastly, I tested a resource as well as a behaviour pack that did not require any experiments to be enabled and sure enough, that appears to work without any issues as well across all different file system types and file system flags. 

—

To summarize: It seems like the issue is being caused by some of these experiments that are failing to load correctly on systems using the XFS file system type with the `ftype` flag set to `1`.

While we completely understand that experiments are just that and may cause instability, it'd be great if the team could check why it would not work on such a widely used file system type and configuration.

Though with the mentioned configuration and full server file downloads, it should be fairly easy to replicate this issue, we would be more than happy to provide a testing server and tools to replicate this issue consistently.

Thanks,
Geri K.

Unable to run scripts under an `xfs` filesystem if the `ftype` is set to 0. This issue continues to be a problem and identical to the issue we were having a year ago.

I’ve entirely isolated this issue to a VPS using the service called `Vulr` and replicated the problem by doing the following. This is worth noting as when installing `AlmaLinux` as the (“Host Machine”) with an xfs filesystem it was `ext4` in this environment.

Additional things to note. We do know this isn’t meant to be run on AlmaLinux, and we run our bedrock servers in docker running Ubuntu. However, since the (“Host Machine”) is an xfs filesystem with ftype=0. This will cause (“scripts”) to fail. We isolated it to make sure it wasn’t a docker-related issue, and it’s not.

yum -y install zip unzip parted screen
echo -e "yes\nyes" | parted /dev/vda ---pretend-input-tty resizepart 2 15GB
echo -e "n\np\n1\n\n\n+5G\nw" | fdisk /dev/vda
echo -e "n\np\n1\n\n\n+5G\nw" | fdisk /dev/vda
mkfs.xfs -f -n ftype=1 /dev/vda3
mkfs.xfs -f -m crc=0 -n ftype=0 /dev/vda4
mkdir -p /ftype1
mkdir -p /ftype0
systemctl daemon-reload
mount /dev/vda3 /ftype1
mount /dev/vda4 /ftype0

If you use `Vultr` they do have a scripts area where you can easily copy/paste to build this server from scratch and don’t have to manually do it. The main command is creating partitions with the `mkfs.xfs` parameters.

Once the server has booted or completed the tasks.

#check meta data
xfs_info /ftype1 | grep "ftype"
xfs_info /ftype0 | grep "ftype"
xfs_info /ftype1 | grep "crc"
xfs_info /ftype0 | grep "crc"

If everything looks set up properly. We’re going to build a server mostly from scratch. This will create the essential files/worlds required.

mkdir -p /home/new/
cd /home/new/
wget https://minecraft.azureedge.net/bin-linux/bedrock-server-1.20.15.01.zip -O bedrock-server.zip
unzip -o bedrock-server.zip
cp -rf "config/default" "config/Bedrock level"
screen -dmS bedrock ./bedrock_server
screen -S bedrock -p 0 -X stuff 'stop^M'

The next step is the scripts. You can find your own scripts or use the one provided. This includes behavior and resource packs and a modified `level.dat` to enable experimental builds. Might want to do this manually to ensure the files get extracted properly.

cd "/home/new/worlds/Bedrock level/"
wget https://cory.pro/Origins.zip -O Origins.zip
unzip -o Origins.zip

Next, we will proceed by copying these same files into the new directories/partitions we created earlier.

cd /home/
cp -rf new /ftype0/
cp -rf new /ftype1/

Modify the ports to avoid conflicts or just run one at a time.

sed -i 's/server-port=[0-9]*/server-port=19142'/g /ftype0/new/server.properties
sed -i 's/server-port=[0-9]*/server-port=19152'/g /ftype1/new/server.properties
sed -i 's/server-portv6=[0-9]*/server-portv6=19143'/g /ftype0/new/server.properties
sed -i 's/server-portv6=[0-9]*/server-portv6=19153'/g /ftype1/new/server.properties

Let us confirm the issue. Go into each directory and start the server respectively.

cd /home/new/; screen -dmS bedrock_ext4 ./bedrock_server
cd /ftype0/new/; screen -dmS bedrock_ftype0 ./bedrock_server
cd /ftype1/new/; screen -dmS bedrock_ftype1 ./bedrock_server

You will see that `ext4` and `ftype1` works perfectly fine, and for `ftype0` the scripts don’t load at all. Keep in mind these are identical servers we just copied and the 2 main differences are the filesystem and server port.

This is where it becomes interesting…

cd /home/new/
screen -dmS bedrock_ext4 /home/new/bedrock_server; screen -x bedrock_ext4

This will load the scripts fine. However, if we switch to:

cd /ftype0/
screen -dmS bedrock_ext4 /home/new/bedrock_server; screen -x bedrock_ext4

Do you notice we’re using the same `screen` command as above? The difference in this case, we ran the command from `/ftype0` and the result is that it failed. However, we run it from `cd /home/new/` directly. It doesn’t fail. Not likely a path issue per Se. This is still a `ftype=0` issue and needs to be resolved.