{ "expand": "operations,versionedRepresentations,editmeta,changelog,renderedFields", "id": "504627", "self": "https://bugs.mojang.com/rest/api/2/issue/504627", "key": "BDS-17043", "fields": { "issuetype": "1", "project": "11700", "fixVersions": [], "resolution": null, "customfield_10500": { "self": "https://bugs.mojang.com/rest/api/2/customFieldOption/10302", "value": "Community Consensus", "id": "10302", "disabled": false }, "customfield_12800": null, "customfield_12602": [], "customfield_12601": null, "customfield_12604": null, "customfield_12603": null, "customfield_12606": null, "customfield_12605": null, "customfield_12608": null, "resolutiondate": null, "customfield_12607": null, "customfield_12609": null, "workratio": -1, "lastViewed": null, "watches": { "self": "https://bugs.mojang.com/rest/api/2/issue/BDS-17043/watchers", "watchCount": 5, "isWatching": false }, "created": "2022-06-01T09:50:04.000+0300", "customfield_12000": null, "customfield_12201": null, "customfield_12600": null, "labels": [], "customfield_11700": "{}", "versions": [ "20813", "20923", "20948" ], "issuelinks": [], "assignee": null, "updated": "2024-06-11T22:10:37.000+0300", "status": "4", "description": "h1. Issue\r\n\r\nBehaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.\r\n\r\nWe discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:\r\n - CentOS 7 `ext4`: works\r\n - CentOS 7 `XFS`: works\r\n - Almalinux 8 `ext4`: works\r\n - Almalinux 8 `XFS` with `ftype=1`: works\r\n - Almalinux 8 `XFS` with `ftype=0`: does not work\r\n\r\nThe flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.\r\n\r\nUnfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). \u2014 This isn't feasible for us so we hope there's a way this can be resolved upstream.\r\n\r\n\u00a0\r\n----\r\nh1. Replication Process\r\n\r\n1. For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)\r\n\r\n2. Once the files are downloaded, one will be a behaviour pack, and the other will be a resource pack. Let's import both to the client by simply double-clicking them.\r\n\r\n3. After that, let's create a new single-player world and under 'Add-Ons', select both.\r\n\r\n4. Once created, we can verify in creative that it does work in single-player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png\r\nNow, let's exit out of this world and copy the files into a server.\r\n\r\n5. Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)\r\n\r\n6. Upload the freshly created world folder from `%LocalAppData%\\Packages\\Microsoft.MinecraftUWP_8wekyb3d8bbwe\\LocalState\\games\\com.mojang\\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.\r\n\r\n7. Start the server directly and attempt to connect.\r\nh3. On a working machine, here is what we'll see:\r\n - Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) \u2014 [https://i.geri.dev/vI1nYpMRyzHk.png]\r\n - Once logged in, we can search for the amethyst ring without any issues: [https://i.geri.dev/2YpxTzICd7fP.png]\r\n\r\nh3. On a machine that has `XFS` with `ftype=0`, here is what we see:\r\n - Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) \u2014 [https://i.geri.dev/maxb4yn9SdoA.png]\r\n - In-game, we cannot view any new items such as the amethyst ring \u2014 [https://i.geri.dev/pPaLxrJnyHCi.png]\r\n\r\n----\r\nh1. More Information\r\n\r\nAdditionally, this happens to all players on different devices from further testing.\r\n\r\nAs for the cache, it looks like if you already connected previously to a world with the exact resource/behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu \u279c 'Settings' \u279c 'Storage' when possible just so that is not the problem.\r\n\r\nWe have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly \u2014 though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.\r\n\r\nFor convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: [https://archive.geri.dev/bedrock_test.zip] (~73 MB total)", "customfield_11100": 0.0, "customfield_11300": "Multiple, see below", "customfield_11500": "891850", "customfield_12503": null, "customfield_12700": "[Briefly describe the bug here]\r\n\r\n*Steps to Reproduce:*\r\n# [Step 1]\r\n# [Step 2]\r\n# [Step 3]\r\n\r\n*Observed Results:*\r\n[Describe what happens]\r\n\r\n*Expected Results:*\r\n[Describe what should happen]\r\n\r\n*Screenshots/Videos attached:* [please attach an image or short video]\r\n\r\n*Notes:*", "customfield_12502": null, "customfield_12504": null, "attachment": [], "summary": "Behaviour/Resource Packs \u2014 File System Issue", "creator": "geeeri", "reporter": "geeeri", "customfield_10002": null, "customfield_12501": null, "customfield_12500": null, "customfield_11601": null, "customfield_11600": "0|i28ign:", "environment": null, "customfield_11801": null, "customfield_11800": null, "customfield_11602": null, "customfield_11802": null, "comment": { "comments": [ { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1168379", "id": "1168379", "author": "arisabot", "body": "{panel:borderColor=orange}(!) Please do not mark _Unreleased Versions_ as affected. You don't have access to them yet.{panel}\n~{color:#888}-- I am a bot. This action was performed automatically! If you think it was incorrect, please notify us on [Discord|https://discordapp.com/invite/rpCyfKV] or [Reddit|https://www.reddit.com/r/Mojira/]{color}~", "updateAuthor": "arisabot", "created": "2022-06-01T09:50:15.214+0300", "updated": "2022-06-01T09:50:15.214+0300" }, { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1168380", "id": "1168380", "author": "geeeri", "body": "Shortly after posting it, I realized there was a dedicated section for BDS. \u2014 I'm unsure whether moving it to that section would be more appropriate but apologies for the headache.", "updateAuthor": "geeeri", "created": "2022-06-01T10:14:10.737+0300", "updated": "2022-06-01T10:14:10.737+0300" }, { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1173015", "id": "1173015", "author": "geeeri", "body": "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.\r\n\r\nUsing the same setup, it works perfectly unless it is on AlmaLinux with XFS using ftype=0.\r\n\r\nThe 1.19 files can be downloaded from here: [https://archive.geri.dev/bedrock_test_v2.zip]", "updateAuthor": "geeeri", "created": "2022-06-14T07:35:22.698+0300", "updated": "2022-06-14T07:35:22.698+0300" }, { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1179744", "id": "1179744", "author": "geeeri", "body": "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]", "updateAuthor": "geeeri", "created": "2022-07-05T11:09:56.550+0300", "updated": "2022-07-05T11:09:56.550+0300" }, { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1180207", "id": "1180207", "author": "JIRAUSER656552", "body": "I don't think mojang accept issues for linux distros other then ubuntu and I think another distro", "updateAuthor": "JIRAUSER656552", "created": "2022-07-06T16:24:09.619+0300", "updated": "2022-07-06T16:24:09.619+0300" }, { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1181959", "id": "1181959", "author": "JIRAUSER648376", "body": "*Thank you for your report!*\r\nHowever, this issue is {color:#ff5722}*Invalid*{color}.\r\n\r\nOnly Ubuntu 18 and later versions are supported.\u00a0\r\n\r\n{*}Quick Links{*}:\r\n\ud83d\udcd3 [Bug Tracker Guidelines|https://aka.ms/MCBugTrackerHelp]\u00a0\u2013 \ud83d\udce7 [Mojang Support|https://help.minecraft.net/hc/en-us/requests/new]\r\n\ud83d\udcd3 [Project Summary|https://bugs.mojang.com/projects/BDS/summary] \u2013 \u270d\ufe0f [Feedback and Suggestions|https://feedback.minecraft.net/] \u2013 \ud83d\udcd6 [BDS Wiki|https://minecraft.fandom.com/wiki/Bedrock_Dedicated_Server] \u2013 \ud83d\udcd6 [FAQs|https://help.minecraft.net/hc/en-us/articles/360035131651-Dedicated-Servers-for-Minecraft-on-Bedrock-]", "updateAuthor": "JIRAUSER648376", "created": "2022-07-13T14:57:40.937+0300", "updated": "2022-07-13T14:57:40.937+0300" }, { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1182749", "id": "1182749", "author": "lordsherman", "body": "I can confirm the issue presents itself on Ubuntu 22.04\r\n\r\nAlso 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.", "updateAuthor": "lordsherman", "created": "2022-07-15T15:13:57.985+0300", "updated": "2022-07-15T15:13:57.985+0300" }, { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1198728", "id": "1198728", "author": "JIRAUSER648376", "body": "Hi\r\n\r\nDoes this issue still occur after updating to 1.19.22?\r\n\r\nThis ticket will automatically reopen when you reply. ", "updateAuthor": "JIRAUSER648376", "created": "2022-09-08T12:45:46.758+0300", "updated": "2022-09-08T12:45:46.758+0300" }, { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1198800", "id": "1198800", "author": "geeeri", "body": "This is still indeed an issue, though it seems like I was able to discover some more information.\r\n\r\nOn systems using XFS with the `ftype` flag set to `0` servers with these resource packs were no longer able to launch.\u00a0\r\n\r\nHere is a download link to the testing files: https://archive.geri.dev/bedrock_test_v3.zip\r\n\r\nFor reference, here is what happens on all of our other nodes that are working, where we use different file system types or `ftype` `1`:\r\n\r\n- Server logs: https://p.geri.dev/raw/zipifidoninihisemide\r\n- Login screen: https://i.geri.dev/YWeRFLSgMhjX.png\r\n- Inventory: https://i.geri.dev/XvsD2VxfAjIh.png\r\n\r\n---\r\n\r\nOn a node with XFS and `ftype` 0, here is the startup crash: https://p.geri.dev/raw/lewipejokeficagoqifo\r\n\r\nOut of curiosity, I tried disabling the resource/behaviour pack to see if that's the issue and it still crashed with the same log.\r\n\r\nAfter poking around I found that simply removing the `level.dat` file allows the server to launch even when the resource/behaviour packs are enabled.\u00a0\r\n\r\nI 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\r\n\r\nAfter 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)\r\n\r\nJust to confirm, I checked in-game and indeed the resource/behaviour packs are not working without these experiments: https://i.geri.dev/9dGTxw3Dy0Om.png\r\n\r\nI 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.\u00a0\r\n\r\nUsing 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\r\n\r\nModifying 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.\r\n\r\nFor reference, here are all the files at the end of this test: https://archive.geri.dev/bedrock_test_v4.zip\r\n\r\n---\r\n\r\nLastly, 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.\u00a0\r\n\r\n---\r\n\r\nTo 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`.\r\n\r\nWhile 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.\r\n\r\nThough 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.\r\n\r\nThanks,\r\nGeri K.", "updateAuthor": "geeeri", "created": "2022-09-08T17:30:03.605+0300", "updated": "2022-09-08T17:30:03.605+0300" }, { "self": "https://bugs.mojang.com/rest/api/2/issue/504627/comment/1280229", "id": "1280229", "author": "cory", "body": "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.\r\n\r\nI\u2019ve 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 (\u201cHost Machine\u201d) with an xfs filesystem it was `ext4` in this environment.\r\n\r\nAdditional things to note. We do know this isn\u2019t meant to be run on AlmaLinux, and we run our bedrock servers in docker running Ubuntu. However, since the (\u201cHost Machine\u201d) is an xfs filesystem with ftype=0. This will cause (\u201cscripts\u201d) to fail. We isolated it to make sure it wasn\u2019t a docker-related issue, and it\u2019s not.\r\n\r\n\u00a0\r\n{code:java}\r\nyum -y install zip unzip parted screen\r\necho -e \"yes\\nyes\" | parted /dev/vda ---pretend-input-tty resizepart 2 15GB\r\necho -e \"n\\np\\n1\\n\\n\\n+5G\\nw\" | fdisk /dev/vda\r\necho -e \"n\\np\\n1\\n\\n\\n+5G\\nw\" | fdisk /dev/vda\r\nmkfs.xfs -f -n ftype=1 /dev/vda3\r\nmkfs.xfs -f -m crc=0 -n ftype=0 /dev/vda4\r\nmkdir -p /ftype1\r\nmkdir -p /ftype0\r\nsystemctl daemon-reload\r\nmount /dev/vda3 /ftype1\r\nmount /dev/vda4 /ftype0 {code}\r\n\u00a0\r\n\r\nIf you use `Vultr` they do have a scripts area where you can easily copy/paste to build this server from scratch and don\u2019t have to manually do it. The main command is creating partitions with the `mkfs.xfs` parameters.\r\n\r\n\u00a0\r\n\r\nOnce the server has booted or completed the tasks.\r\n\r\n\u00a0\r\n{code:java}\r\n#check meta data\r\nxfs_info /ftype1 | grep \"ftype\"\r\nxfs_info /ftype0 | grep \"ftype\"\r\nxfs_info /ftype1 | grep \"crc\"\r\nxfs_info /ftype0 | grep \"crc\" {code}\r\n\u00a0\r\n\r\nIf everything looks set up properly. We\u2019re going to build a server mostly from scratch. This will create the essential files/worlds required.\r\n\r\n\u00a0\r\n{code:java}\r\nmkdir -p /home/new/\r\ncd /home/new/\r\nwget https://minecraft.azureedge.net/bin-linux/bedrock-server-1.20.15.01.zip -O bedrock-server.zip\r\nunzip -o bedrock-server.zip\r\ncp -rf \"config/default\" \"config/Bedrock level\"\r\nscreen -dmS bedrock ./bedrock_server\r\nscreen -S bedrock -p 0 -X stuff 'stop^M' {code}\r\n\u00a0\r\n\r\nThe 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.\r\n{code:java}\r\ncd \"/home/new/worlds/Bedrock level/\"\r\nwget https://cory.pro/Origins.zip -O Origins.zip\r\nunzip -o Origins.zip {code}\r\nNext, we will proceed by copying these same files into the new directories/partitions we created earlier.\r\n{code:java}\r\ncd /home/\r\ncp -rf new /ftype0/\r\ncp -rf new /ftype1/ {code}\r\nModify the ports to avoid conflicts or just run one at a time.\r\n{code:java}\r\nsed -i 's/server-port=[0-9]*/server-port=19142'/g /ftype0/new/server.properties\r\nsed -i 's/server-port=[0-9]*/server-port=19152'/g /ftype1/new/server.properties\r\nsed -i 's/server-portv6=[0-9]*/server-portv6=19143'/g /ftype0/new/server.properties\r\nsed -i 's/server-portv6=[0-9]*/server-portv6=19153'/g /ftype1/new/server.properties {code}\r\nLet us confirm the issue. Go into each directory and start the server respectively.\r\n{code:java}\r\ncd /home/new/; screen -dmS bedrock_ext4 ./bedrock_server\r\ncd /ftype0/new/; screen -dmS bedrock_ftype0 ./bedrock_server\r\ncd /ftype1/new/; screen -dmS bedrock_ftype1 ./bedrock_server {code}\r\nYou will see that `ext4` and `ftype1` works perfectly fine, and for `ftype0` the scripts don\u2019t load at all. Keep in mind these are identical servers we just copied and the 2 main differences are the filesystem and server port.\r\n\r\n\u00a0\r\n\r\nThis is where it becomes interesting\u2026\r\n{code:java}\r\ncd /home/new/\r\nscreen -dmS bedrock_ext4 /home/new/bedrock_server; screen -x bedrock_ext4 {code}\r\nThis will load the scripts fine. However, if we switch to:\r\n{code:java}\r\ncd /ftype0/\r\nscreen -dmS bedrock_ext4 /home/new/bedrock_server; screen -x bedrock_ext4 {code}\r\nDo you notice we\u2019re 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\u2019t fail. Not likely a path issue per Se. This is still a `ftype=0` issue and needs to be resolved.", "updateAuthor": "cory", "created": "2023-09-19T00:33:55.875+0300", "updated": "2023-09-19T00:33:55.875+0300" } ], "maxResults": 10, "total": 10, "startAt": 0 }, "votes": { "self": "https://bugs.mojang.com/rest/api/2/issue/BDS-17043/votes", "votes": 3, "hasVoted": false } }, "changelog": { "startAt": 0, "maxResults": 12, "total": 12, "histories": [ { "id": "2600638", "author": "arisabot", "created": "2022-06-01T09:50:15.074+0300", "items": [ { "field": "Version", "fieldtype": "jira", "from": "15397", "fromString": "Future Release", "to": null, "toString": null } ] }, { "id": "2600639", "author": "geeeri", "created": "2022-06-01T09:53:26.195+0300", "items": [ { "field": "description", "fieldtype": "jira", "from": null, "fromString": "h1. Issue\r\n\r\nBehaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.\r\n\r\nWe discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:\r\n - CentOS 7 `ext4`: works\r\n - CentOS 7 `XFS`: works\r\n - Almalinux 8 `ext4`: works\r\n - Almalinux 8 `XFS` with `ftype=1`: works\r\n - Almalinux 8 `XFS` with `ftype=0`: does not work\r\n\r\nThe flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.\r\n\r\nUnfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). \u2014 This isn't feasible for us so we hope there's a way this can be resolved upstream.\r\n\r\n\u2014\r\nh1. Replication Process\r\n # For demonstration purposes, let's use a known working one from a public library: [https://mcpedl.com/extended-amethyst-add-on/] (though any would work as far as we can tell)\r\n\r\n\r\n # Once the files are downloaded, one will be a behaviour pack, the other will be a resource pack. Let's import both to the client by simply double clicking them.\r\n\r\n\r\n # After that, let's create a new single player world and under 'Add-Ons', select both.\r\n\r\n\r\n # Once created, we can verify in creative that it does work in single player by simply searching for an amethyst ring: [https://i.geri.dev/sQIRTPXwBGj5.png]\r\nNow, let's exit out of this world and copy the files into a server.\r\n\r\n\r\n # Download the dedicated server files from [https://www.minecraft.net/en-us/download/server/bedrock] (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)\r\n\r\n\r\n # Upload the freshly created world folder from `%LocalAppData%\\Packages\\Microsoft.MinecraftUWP_8wekyb3d8bbwe\\LocalState\\games\\com.mojang\\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.\r\n\r\n\r\n # Start the server directly and attempt to connect.\r\n\r\nOn a working machine, here is what we'll see:\r\n - Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) \u2014 [https://i.geri.dev/vI1nYpMRyzHk.png]\r\n - Once logged in, we can search for the amethyst ring without any issues: [https://i.geri.dev/2YpxTzICd7fP.png]\r\n\r\nOn a machine that has `XFS` with `ftype=0`, here is what we see:\r\n - Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) \u2014 [https://i.geri.dev/maxb4yn9SdoA.png]\r\n - In game, we cannot view any new items such as the amethyst ring \u2014 [https://i.geri.dev/pPaLxrJnyHCi.png]\r\n\r\n\u2014\r\n\r\nAdditionally, this happens to all players on different devices from further testing.\r\n\r\nAs for the cache, it looks like if you already connected to a world with the exact resource / behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu \u279c 'Settings' \u279c 'Storage' when possible just so that is not the problem.\r\n\r\nWe have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly \u2014 though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.\r\n\r\nFor convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: [https://archive.geri.dev/bedrock_test.zip] (~73 MB total)", "to": null, "toString": "h1. Issue\r\n\r\nBehaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.\r\n\r\nWe discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:\r\n - CentOS 7 `ext4`: works\r\n - CentOS 7 `XFS`: works\r\n - Almalinux 8 `ext4`: works\r\n - Almalinux 8 `XFS` with `ftype=1`: works\r\n - Almalinux 8 `XFS` with `ftype=0`: does not work\r\n\r\nThe flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.\r\n\r\nUnfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). \u2014 This isn't feasible for us so we hope there's a way this can be resolved upstream.\r\n\r\n\u00a0\r\n----\r\nh1. Replication Process\r\n # For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)\r\n\r\n\u00a0\r\n\r\n # Once the files are downloaded, one will be a behaviour pack, and the other will be a resource pack. Let's import both to the client by simply double-clicking them.\r\n\r\nAfter that, let's create a new single-player world and under 'Add-Ons', select both.\r\n\r\n\u00a0\r\n\r\n # Once created, we can verify in creative that it does work in single-player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png\r\n\r\n # Now, let's exit out of this world and copy the files into a server.\r\n\r\n\u00a0\r\n\r\n # Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)\r\n\r\n\u00a0\r\n\r\n # Upload the freshly created world folder from `%LocalAppData%\\Packages\\Microsoft.MinecraftUWP_8wekyb3d8bbwe\\LocalState\\games\\com.mojang\\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.\r\n\r\n\u00a0\r\n\r\n # Start the server directly and attempt to connect.\r\n\r\n\u00a0\r\nh3. On a working machine, here is what we'll see:\r\n - Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) \u2014 [https://i.geri.dev/vI1nYpMRyzHk.png]\r\n - Once logged in, we can search for the amethyst ring without any issues: [https://i.geri.dev/2YpxTzICd7fP.png]\r\n\r\nh3. On a machine that has `XFS` with `ftype=0`, here is what we see:\r\n - Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) \u2014 [https://i.geri.dev/maxb4yn9SdoA.png]\r\n - In-game, we cannot view any new items such as the amethyst ring \u2014 [https://i.geri.dev/pPaLxrJnyHCi.png]\r\n\r\n----\r\nh1. More Information\r\n\r\nAdditionally, this happens to all players on different devices from further testing.\r\n\r\nAs for the cache, it looks like if you already connected previously to a world with the exact resource/behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu \u279c 'Settings' \u279c 'Storage' when possible just so that is not the problem.\r\n\r\nWe have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly \u2014 though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.\r\n\r\nFor convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: [https://archive.geri.dev/bedrock_test.zip] (~73 MB total)" } ] }, { "id": "2600640", "author": "geeeri", "created": "2022-06-01T09:54:06.273+0300", "items": [ { "field": "description", "fieldtype": "jira", "from": null, "fromString": "h1. Issue\r\n\r\nBehaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.\r\n\r\nWe discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:\r\n - CentOS 7 `ext4`: works\r\n - CentOS 7 `XFS`: works\r\n - Almalinux 8 `ext4`: works\r\n - Almalinux 8 `XFS` with `ftype=1`: works\r\n - Almalinux 8 `XFS` with `ftype=0`: does not work\r\n\r\nThe flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.\r\n\r\nUnfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). \u2014 This isn't feasible for us so we hope there's a way this can be resolved upstream.\r\n\r\n\u00a0\r\n----\r\nh1. Replication Process\r\n # For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)\r\n\r\n\u00a0\r\n\r\n # Once the files are downloaded, one will be a behaviour pack, and the other will be a resource pack. Let's import both to the client by simply double-clicking them.\r\n\r\nAfter that, let's create a new single-player world and under 'Add-Ons', select both.\r\n\r\n\u00a0\r\n\r\n # Once created, we can verify in creative that it does work in single-player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png\r\n\r\n # Now, let's exit out of this world and copy the files into a server.\r\n\r\n\u00a0\r\n\r\n # Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)\r\n\r\n\u00a0\r\n\r\n # Upload the freshly created world folder from `%LocalAppData%\\Packages\\Microsoft.MinecraftUWP_8wekyb3d8bbwe\\LocalState\\games\\com.mojang\\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.\r\n\r\n\u00a0\r\n\r\n # Start the server directly and attempt to connect.\r\n\r\n\u00a0\r\nh3. On a working machine, here is what we'll see:\r\n - Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) \u2014 [https://i.geri.dev/vI1nYpMRyzHk.png]\r\n - Once logged in, we can search for the amethyst ring without any issues: [https://i.geri.dev/2YpxTzICd7fP.png]\r\n\r\nh3. On a machine that has `XFS` with `ftype=0`, here is what we see:\r\n - Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) \u2014 [https://i.geri.dev/maxb4yn9SdoA.png]\r\n - In-game, we cannot view any new items such as the amethyst ring \u2014 [https://i.geri.dev/pPaLxrJnyHCi.png]\r\n\r\n----\r\nh1. More Information\r\n\r\nAdditionally, this happens to all players on different devices from further testing.\r\n\r\nAs for the cache, it looks like if you already connected previously to a world with the exact resource/behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu \u279c 'Settings' \u279c 'Storage' when possible just so that is not the problem.\r\n\r\nWe have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly \u2014 though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.\r\n\r\nFor convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: [https://archive.geri.dev/bedrock_test.zip] (~73 MB total)", "to": null, "toString": "h1. Issue\r\n\r\nBehaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.\r\n\r\nWe discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:\r\n - CentOS 7 `ext4`: works\r\n - CentOS 7 `XFS`: works\r\n - Almalinux 8 `ext4`: works\r\n - Almalinux 8 `XFS` with `ftype=1`: works\r\n - Almalinux 8 `XFS` with `ftype=0`: does not work\r\n\r\nThe flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.\r\n\r\nUnfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). \u2014 This isn't feasible for us so we hope there's a way this can be resolved upstream.\r\n\r\n\u00a0\r\n----\r\nh1. Replication Process\r\n\r\n1. For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)\r\n\r\n2. Once the files are downloaded, one will be a behaviour pack, and the other will be a resource pack. Let's import both to the client by simply double-clicking them.\r\n\r\n3. After that, let's create a new single-player world and under 'Add-Ons', select both.\r\n\r\n4. Once created, we can verify in creative that it does work in single-player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png\r\nNow, let's exit out of this world and copy the files into a server.\r\n\r\n5. Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)\r\n\r\n6. Upload the freshly created world folder from `%LocalAppData%\\Packages\\Microsoft.MinecraftUWP_8wekyb3d8bbwe\\LocalState\\games\\com.mojang\\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.\r\n\r\n7. Start the server directly and attempt to connect.\r\nh3. On a working machine, here is what we'll see:\r\n - Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) \u2014 [https://i.geri.dev/vI1nYpMRyzHk.png]\r\n - Once logged in, we can search for the amethyst ring without any issues: [https://i.geri.dev/2YpxTzICd7fP.png]\r\n\r\nh3. On a machine that has `XFS` with `ftype=0`, here is what we see:\r\n - Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) \u2014 [https://i.geri.dev/maxb4yn9SdoA.png]\r\n - In-game, we cannot view any new items such as the amethyst ring \u2014 [https://i.geri.dev/pPaLxrJnyHCi.png]\r\n\r\n----\r\nh1. More Information\r\n\r\nAdditionally, this happens to all players on different devices from further testing.\r\n\r\nAs for the cache, it looks like if you already connected previously to a world with the exact resource/behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu \u279c 'Settings' \u279c 'Storage' when possible just so that is not the problem.\r\n\r\nWe have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly \u2014 though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.\r\n\r\nFor convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: [https://archive.geri.dev/bedrock_test.zip] (~73 MB total)" } ] }, { "id": "2600711", "author": "ocelotonesie", "created": "2022-06-01T12:55:11.211+0300", "items": [ { "field": "Key", "fieldtype": "jira", "from": null, "fromString": "MCPE-156545", "to": null, "toString": "BDS-17043" }, { "field": "Platform", "fieldtype": "custom", "from": "11503", "fromString": "Multiple", "to": null, "toString": "" }, { "field": "Version", "fieldtype": "jira", "from": null, "fromString": null, "to": "20813", "toString": "1.18.31" }, { "field": "Version", "fieldtype": "jira", "from": "20901", "fromString": "1.18.33 Hotfix", "to": null, "toString": null }, { "field": "Version", "fieldtype": "jira", "from": "20821", "fromString": "1.18.32", "to": null, "toString": null }, { "field": "Version", "fieldtype": "jira", "from": "20809", "fromString": "1.18.31", "to": null, "toString": null }, { "field": "Version", "fieldtype": "jira", "from": "20913", "fromString": "1.19.10.20 Preview", "to": null, "toString": null }, { "field": "Workflow", "fieldtype": "jira", "from": "674971", "fromString": "MCPE Workflow", "to": "674977", "toString": "Global Mojang Workflow" }, { "field": "project", "fieldtype": "jira", "from": "10200", "fromString": "Minecraft (Bedrock codebase)", "to": "11700", "toString": "Bedrock Dedicated Server" } ] }, { "id": "2611078", "author": "geeeri", "created": "2022-06-14T07:32:14.966+0300", "items": [ { "field": "Version", "fieldtype": "jira", "from": null, "fromString": null, "to": "20923", "toString": "1.19.0" } ] }, { "id": "2624444", "author": "geeeri", "created": "2022-07-05T11:08:30.462+0300", "items": [ { "field": "Version", "fieldtype": "jira", "from": null, "fromString": null, "to": "20948", "toString": "1.19.2 Hotfix" } ] }, { "id": "2629388", "author": "JIRAUSER648376", "created": "2022-07-13T14:57:40.944+0300", "items": [ { "field": "resolution", "fieldtype": "jira", "from": null, "fromString": null, "to": "7", "toString": "Invalid" }, { "field": "status", "fieldtype": "jira", "from": "1", "fromString": "Open", "to": "5", "toString": "Resolved" } ] }, { "id": "2631141", "author": "umija5895", "created": "2022-07-15T18:03:02.488+0300", "items": [ { "field": "resolution", "fieldtype": "jira", "from": "7", "fromString": "Invalid", "to": null, "toString": null }, { "field": "status", "fieldtype": "jira", "from": "5", "fromString": "Resolved", "to": "4", "toString": "Reopened" } ] }, { "id": "2666268", "author": "JIRAUSER648376", "created": "2022-09-08T12:45:46.766+0300", "items": [ { "field": "resolution", "fieldtype": "jira", "from": null, "fromString": null, "to": "10001", "toString": "Awaiting Response" }, { "field": "status", "fieldtype": "jira", "from": "4", "fromString": "Reopened", "to": "5", "toString": "Resolved" } ] }, { "id": "2666373", "author": "arisabot", "created": "2022-09-08T17:30:06.227+0300", "items": [ { "field": "resolution", "fieldtype": "jira", "from": "10001", "fromString": "Awaiting Response", "to": null, "toString": null }, { "field": "status", "fieldtype": "jira", "from": "5", "fromString": "Resolved", "to": "4", "toString": "Reopened" } ] }, { "id": "2667747", "author": "JIRAUSER648376", "created": "2022-09-12T17:18:14.127+0300", "items": [ { "field": "ADO", "fieldtype": "custom", "from": null, "fromString": null, "to": null, "toString": "891850" }, { "field": "status", "fieldtype": "jira", "from": "4", "fromString": "Reopened", "to": "4", "toString": "Reopened" } ] }, { "id": "3014046", "author": "jarl-penguin", "created": "2024-06-11T22:10:37.591+0300", "items": [ { "field": "Confirmation Status", "fieldtype": "custom", "from": "10300", "fromString": "Unconfirmed", "to": "10302", "toString": "Community Consensus" }, { "field": "status", "fieldtype": "jira", "from": "4", "fromString": "Reopened", "to": "4", "toString": "Reopened" } ] } ] } }