Minecraft Bedrock Launcher - Bookworm - 64-bit system about pi-apps HOT 34 CLOSED

CC @TheBrokenRail any ideas here? ^
edit: sorry wrong person

from pi-apps.

@bagong sorry our current appimage shipped in pi-apps is quite old for the bedrock launcher and there is a newer version upstream. You can try it out by downloading it anywhere and running it directly via terminal. https://github.com/minecraft-linux/appimage-builder/releases . If that still does not work then we can ping @ChristopherHX (edited this in afterwards to avoid pinging him now).

I will check myself if it is stable later today and add a pi-apps auto-updater

from pi-apps.

@theofficialgman doesn't work, same error

from pi-apps.

@ChristopherHX thoughts on this issue? ^

from pi-apps.

@ChristopherHX thoughts on this issue? ^

Append the -v (verbose) flag, it may reveal the error. I prefer upstream linux distributions, raspberry pi os used to remove debian packages (I assume you cannot install the bookworm apt package on it https://github.com/minecraft-linux/pkg).

from pi-apps.

(edited this in afterwards to avoid pinging him now).

BTW no this doesn't work anymore, I got the edit as mail

from pi-apps.

I prefer upstream linux distributions, raspberry pi os used to remove debian packages (I assume you cannot install the bookworm apt package on it https://github.com/minecraft-linux/pkg).

64bit piOS uses debian default repos with only an additional repo added for piOS specific packages (such as their desktop environment, rpi-imager, and the like). So no they don't remove any packages (the only way to do that in this configuration would be to have a apt pin that disables packages from the debian repos which they do not have).

I was not aware that you built debs. They bookworm apt package should install without any problems.

from pi-apps.

@ChristopherHX can confirm the issue on the arm64 appimage myself. passing -v does not produce any more output.
The issue is already present in the original log
/tmp/.mount_MCBedrt5K5AW/usr/bin/msa-ui-qt: /tmp/.mount_MCBedrt5K5AW/usr/lib/libselinux.so.1: no version information available (required by /lib/aarch64-linux-gnu/libgio-2.0.so.0)
the version of libselinux.so.1 that you bundle in the appimage is incompatible with the system libgio-2.0.so.0 that tries to load it.

btw, the arm64 bookworm debs do work but we prefer to use the same install methods on all systems when possible. When I say they work, I mean the QT gui runs. Attempting to run the latest version of minecraft crashes wayfire back to the login screen. More investigation needed.

from pi-apps.

@theofficialgman , thanks for the deep analysis, way better than I could have ever done! So is "wayfire-compatibility" Rpi.com or MS' job? Is it likely to happen? Thanks for your care!!

from pi-apps.

@theofficialgman Can you do --appimage-extract, delete usr/lib/libselinux.so.1 from squashfs-root and run AppRun

My arm appimages are an old experiment...

from pi-apps.

btw, the arm64 bookworm debs do work but we prefer to use the same install methods on all systems when possible. When I say they work, I mean the QT gui runs. Attempting to run the latest version of minecraft crashes wayfire back to the login screen. More investigation needed.

crashing was because of 16K kernel used on the pi5. KDE Plasma wayland DE did not crash but instead showed a useless error in verbose logs and then a GUI popup saying the version of minecraft selected was unsupported and to select a support version (which was untrue). changing to the 4K kernel the game does run with the debs

from pi-apps.

@theofficialgman Can you do --appimage-extract, delete usr/lib/libselinux.so.1 from squashfs-root and run AppRun

@ChristopherHX the warnings/errors go away but it still segfaults on mcpelauncher-ui-qt like before

from pi-apps.

Like I thought, usr/lib/libselinux.so.1 is an unrelated warning.

I have no clue, why the AppImage is binary incompatible with your OS.

So --help doesn't work too?

from pi-apps.

So --help doesn't work too?

correct, it does not work

from pi-apps.

crashing was because of 16K kernel used on the pi5

I'm asking because, I never heard from the 16K kernel term.

Your linux used a pagesize other than 4K?

16K requires hacks to fake a 4K alignment, so libminecraftpe.so can be loaded.

from pi-apps.

The macOS m1 port uses such a hack, but the m1 macs never have 4K pages.

from pi-apps.

I'm asking because, I never heard from the 16K kernel term.

Your linux used a pagesize other than 4K?

16K requires hacks to fake a 4K alignment, so libminecraftpe.so can be loaded.

yeah raspberry pi ltd has decided to make 16K pagesize kernels the default on Pi5. A 4k kernel is also available (same one that pi3-4 use). The haven't publicized this at all because they think "not much software is affected" but I have given them a decent list so we will see if they change their mind.
raspberrypi/bookworm-feedback#107

from pi-apps.

@ChristopherHX does this backtrace tell you anything (extracted appimage, determined what the LD_PRELOAD_PATH should be given the AppRun script, then executed in gdb)

(gdb) set environment LD_LIBRARY_PATH = /home/gman/.local/share/flatpak/exports/share/mcpelauncher/libs/native:/var/lib/flatpak/exports/share/mcpelauncher/libs/native:/usr/local/share/mcpelauncher/libs/native:/usr/share/mcpelauncher/libs/native:/tmp/mc/squashfs-root/usr/share/mcpelauncher/libs/native:/tmp/mc/squashfs-root/usr/lib:/tmp/mc/squashfs-root/usr/lib32
(gdb) show environment LD_LIBRARY_PATH
LD_LIBRARY_PATH = /home/gman/.local/share/flatpak/exports/share/mcpelauncher/libs/native:/var/lib/flatpak/exports/share/mcpelauncher/libs/native:/usr/local/share/mcpelauncher/libs/native:/usr/share/mcpelauncher/libs/native:/tmp/mc/squashfs-root/usr/share/mcpelauncher/libs/native:/tmp/mc/squashfs-root/usr/lib:/tmp/mc/squashfs-root/usr/lib32
(gdb) r
Starting program: /tmp/mc/squashfs-root/usr/bin/mcpelauncher-ui-qt 
/tmp/mc/squashfs-root/usr/bin/mcpelauncher-ui-qt: /tmp/mc/squashfs-root/usr/lib/libselinux.so.1: no version information available (required by /lib/aarch64-linux-gnu/libgio-2.0.so.0)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fe810eb00 (LWP 6436)]
WARNING: v3d support for hw version 71 is neither a complete nor a conformant OpenGL implementation. Testing use only.
[New Thread 0x7fd94eeb00 (LWP 6437)]

Thread 1 "mcpelauncher-ui" received signal SIGSEGV, Segmentation fault.
__GI___strlen_asimd () at ../sysdeps/aarch64/multiarch/strlen_asimd.S:195
195     ../sysdeps/aarch64/multiarch/strlen_asimd.S: No such file or directory.
(gdb) bt
#0  __GI___strlen_asimd () at ../sysdeps/aarch64/multiarch/strlen_asimd.S:195
#1  0x0000007ff6481e98 in QByteArray::QByteArray(char const*, int) () at /tmp/mc/squashfs-root/usr/lib/libQt5Core.so.5
#2  0x0000007fe78dc1c4 in  () at /tmp/mc/squashfs-root/usr/plugins/xcbglintegrations/libqxcb-egl-integration.so
#3  0x0000000000bc72f0 in  ()

from pi-apps.

@ChristopherHX just to add some more context, the reason that we are using the appimages is because we support both armhf and arm64 across a variety of OSs. You don't produce any armhf debs

from pi-apps.

from pi-apps.

May I ask where to obtain arm64 debs? I'd like to try them on Rpi OS Bookworm, and on Ubuntu 22.04 running on a (Rockchip RK3588) Orange Pi 5. On both systems the debs aren't available through apt. Is there some public ppa or a direct download?

@bagong
the info page on adding the apt repo is here -> https://github.com/minecraft-linux/pkg . it is best to just add that repo and install using the documentation at the official website

the debs are not directly downloadable through the web gui (unless you grab them from github actions artifact storage soon after they are built). if you want to manually download and install the debs you will have to use inherent knowledge of how a debian repo is structured and parse the Packages file for your intended dist
eg: bionic arm64 -> https://minecraft-linux.github.io/pkg/deb/dists/bionic/main/binary-arm64/Packages

from pi-apps.

No I have no clue how to fix the AppImage, which wouldn't mean delete the AppInage script and start from scratch (probably build qt6 webengine ci run time about 8+ hours, distro packages are always outdated) or retargeting the appimage on bookworm. The latter would phase out a larger group of people and the AppImage no longer works pre bookworm

#0  __GI___strlen_asimd () at ../sysdeps/aarch64/multiarch/strlen_asimd.S:195
#1  0x0000007ff6481e98 in QByteArray::QByteArray(char const*, int) () at /tmp/mc/squashfs-root/usr/lib/libQt5Core.so.5
#2  0x0000007fe78dc1c4 in  () at /tmp/mc/squashfs-root/usr/plugins/xcbglintegrations/libqxcb-egl-integration.so
#3  0x0000000000bc72f0 in  ()

crash in qt5.9 for ubuntu 18.04, I don't get support for that binary package.

Probably due to v3d mesa drivers of the raspberry pi os.

It's probably easier for me to add armhf to the ppa instead of touching the AppImage with it's extreme complexity.

The launcher project is more or less floating around as a secondary side project, this means such large changes are not a high priority for me

, the reason that we are using the appimages is because we support both armhf and arm64 across a variety of OSs. You don't produce any armhf debs

I understand, it would be for both of us a xxxl time consuming project to fix this issue.
All my devices run on old linux distros if they are running linux. A lot of my micro sd's died due to flashing them over and over again.

If I would create 2 new AppImage files for bookworm as well by forking the existing job, it would still require you to detect bookworm or equivalent or later. (e.g. test for glibc version)

My question is, would you willing to add this kind of complexity. Replacing the existing file means a breaking change for everyone (glibc requirement increment).

from pi-apps.

It's probably easier for me to add armhf to the ppa instead of touching the AppImage with it's extreme complexity.

this would be my preference of the above choices ^

Of course it would be better if all users simply used an arm64 OS but this simply isn't the case. At least Raspberry Pi LTD just started recommending 64bit PiOS Bookworm as the default for Pi4 and Pi5 rather than 32bit PiOS for all hardware.

On another note, why do you even use QT webengine in the first place? I know it is for authentication purposes but wouldn't it have been easier to delegate that to the users default browser like other applications that require microsoft authentication tokens/keys/sessions ? I am not familiar with how that process works in this launcher so forgive my ignorance if that is not possible here for technical reasons.

from pi-apps.

I know it is for authentication purposes but wouldn't it have been easier to delegate that to the users default browser like other applications that require microsoft authentication tokens/keys/sessions ?

My rule of dumb, don't change a running system. Using dev tools for google and ms login kinda works, but is not feasible for end users.

Xbox login might be possible without it, but then you depend on uri registration of your system. I think for AppImages, flatpak and macOS this can get buggy.

Google doesn't want to allow third party apps to login as an android device (The regular oauth app is probably different in level of access, but I'm not an expert.)

from pi-apps.

@theofficialgman hi, this is bagong with another account. I have checked the debs and they work fine except for logging in. The bookworm deb works fine on Rpi4 64 bit. I could log into Google after multiple attempts (and ignoring security warnings), but I could not log into the MS account, and thus couldn't play on a remote server (which is the major benefit of Bedrock, as you can play with console owners). Playing on local worlds works fine however, and is surprisingly snappy.

On Ubuntu Jammy (22.04, Orange Pi 5+, using the Joshua Riek image) it was less of a success. I could install the debs, but I couldn't log in anywhere. I then remembered that there is a flatpack which allows login for both Google and MS (it's UI version 0.12 rather than 0.11, maybe that is the reason). For some reason however this install was extremely slow while playing, while the olders were very snappy. The Orange Pi 5 has about twice the power of the RPI IV.

from pi-apps.

For some reason however this install was extremely slow while playing, while the olders were very snappy. The Orange Pi 5 has about twice the power of the RPI IV.

no, it was not "older builds" that were snappy. orange pi 5 has a non mesa supported gpu in it (valhall II mali gpu).
the "orange pi" distributions ship a fork of mesa called "panfork" that supports these valhall II mali gpus.

For reasons I won't go into, the developer working on that is banned from mesa development. Use google to find out more info. Of course flatpak (which has its own integrated driverstack) does not use this cursed "panfork" mesa fork so you end up with software rendering

from pi-apps.

. I have checked the debs and they work fine except for logging in.

My experience with rpi drivers and qt webengine is disable the gpu for the webview. appimage does it for arm, I have my reasons

Does this show an weird error instead of google? ( could be also a broken depenency chain of the deb )

export QT_QUICK_BACKEND=software
mcpelauncher-webview https://google.com test://exit

You can also try, and log in

QT_QUICK_BACKEND=software mcpelauncher-ui-qt

You only need gpu for the game, but not really for qt.

Steam OS mslogin is broken recently, not shure if you see the same bug...

from pi-apps.

Thanks both of your for tips and explanations. Everything happens as you predicted:

• MS-login doesn't work on both installs, so I guess that means it's a MS problem (?)
• QT_QUICK_BACKEND=software instantly fixed Google login
• On the Ubuntu System using the deb's rather than flatpak brought the snappines/hardware support back.

export QT_QUICK_BACKEND=software
mcpelauncher-webview https://google.com test://exit

In my environment this did produce a browser Window, no weird error. There are Wayland warnings, but they're normal ;-)

Thanks for your help, both of you, much appreciated!

from pi-apps.

This patch should make the launcher runnable on 16k and 32k kernels minecraft-linux/android_bionic@0a23d12, by using a fallback like for windows (all archs) and macOS (arm64).
Will take a while to reach nightly prebuilds if it still compiles...

from pi-apps.

rpi4 with 64k pagesize (latest nightly of 0.12.0)

loading so is ok.

MCPELAUNCHER_LINKER_VERBOSITY=0 DISPLAY=:0 mcpelauncher-client -dg .local/share/mcpelau
ncher/versions/1.20.41.02
15:24:31 Info  [Launcher] Version: client cd294ac / manifest 28cca8f
15:24:31 Trace [Launcher] Loading hybris libraries
15:24:31 Trace [Launcher] linker loaded
15:24:32 Trace [REDIRECT] /data/data/com.mojang.minecraftpe to /home/christopher/.local/share/mcpelauncher/
15:24:32 Trace [REDIRECT] /data/data/usr/proc/8521/cmdline to /home/christopher/.local/share/mcpelauncher/
15:24:32 Trace [REDIRECT] /data/data/mcpelauncher-client to /home/christopher/.local/share/mcpelauncher/
15:24:32 Trace [REDIRECT] /data/data to /home/christopher/.local/share/mcpelauncher/
15:24:32 Trace [REDIRECT] . to .local/share/mcpelauncher/versions/1.20.41.02/assets/
15:24:32 Trace [LinkerUtils] Loaded OS library libm.so.6
15:24:32 Trace [LinkerUtils] Loaded OS library libz.so.1
15:24:32 Warn  [FMOD] Failed to load host libfmod: 'Failed to find data file: lib/native/arm64-v8a/libfmod.so.12.0', use experimental pulseaudio backend if available
15:24:32 Info  [Launcher] Loading gamepad mappings
15:24:32 Trace [Launcher] Loading gamepad mappings: /usr/share/mcpelauncher/gamecontrollerdb.txt
15:24:32 Trace [Launcher] Loading gamepad mappings: /usr/share/mcpelauncher/gamecontrollerdb.txt
15:24:32 Info  [Launcher] Creating window
15:24:32 Trace [Launcher] Loading Minecraft library
linker: Detected an Android Binary incompatible pagesize of 65536 bytes, usually android has a fixed pagesize of 4096
linker: Warning: "/media/christopher/01D2F02110B39FC0/minecraft-linux/data/versions/1.20.41.02/lib/arm64-v8a/libc++_shared.so" unused DT entry: unknown processor-specific (type 0x70000001 arg 0x0) (ignoring)
WARNING: linker: Warning: "/media/christopher/01D2F02110B39FC0/minecraft-linux/data/versions/1.20.41.02/lib/arm64-v8a/libc++_shared.so" unused DT entry: unknown processor-specific (type 0x70000001 arg 0x0) (ignoring)
linker: mcpelauncher_linker_notifylldb /media/christopher/01D2F02110B39FC0/minecraft-linux/data/versions/1.20.41.02/lib/arm64-v8a/libc++_shared.so 0x3fc3ff80000
linker: Detected an Android Binary incompatible pagesize of 65536 bytes, usually android has a fixed pagesize of 4096
linker: Detected an Android Binary incompatible pagesize of 65536 bytes, usually android has a fixed pagesize of 4096
linker: mcpelauncher_linker_notifylldb /media/christopher/01D2F02110B39FC0/minecraft-linux/data/versions/1.20.41.02/lib/arm64-v8a/libfmod.so 0x3fc308c0000
linker: mcpelauncher_linker_notifylldb /media/christopher/01D2F02110B39FC0/minecraft-linux/data/versions/1.20.41.02/lib/arm64-v8a/libminecraftpe.so 0x3fc30a80000
Found hook: _ZN11AppPlatform16showMousePointerEv @ 0x69895c
Found hook: _ZN11AppPlatform16hideMousePointerEv @ 0x698944
Found hook: _ZN11AppPlatform17setFullscreenModeE14FullscreenMode @ 0x698974
15:24:32 Info  [Launcher] Loaded Minecraft library
15:24:32 Debug [Launcher] Minecraft is at offset 0x3FC30A80000
15:24:32 Info  [Launcher] Game version: 0.0.0.0
15:24:32 Info  [Launcher] Applying patches
15:24:32 Debug [CorePatches] Failed to patch, vtable _ZTV21AppPlatform_android23 not found
15:24:32 Info  [Launcher] Initializing JNI
15:24:32 Error [JniSupport] Missing native symbol: Java_com_mojang_minecraftpe_MainActivity_nativeRegisterThis
15:24:32 Error [JniSupport] Missing native symbol: Java_com_mojang_minecraftpe_MainActivity_nativeInitializeWithApplicationContext
15:24:32 Error [JniSupport] Missing native symbol: Java_com_mojang_minecraftpe_MainActivity_nativeUnregisterThis
15:24:32 Error [JniSupport] Missing native symbol: Java_com_mojang_minecraftpe_MainActivity_nativeinitializeLibHttpClient
15:24:32 Error [JniSupport] Missing native symbol: Java_com_microsoft_xal_browser_WebView_urlOperationSucceeded
15:24:32 Error [JniSupport] Missing native symbol: Java_com_mojang_minecraftpe_PlayIntegrity_nativePlayIntegrityComplete
15:24:32 Trace [Minecraft] Entering JNI_OnLoad 0x3fc3ff0eec0
15:24:32 Trace [Minecraft] JNI_OnLoad completed
15:24:32 Trace [JniSupport] Invoking nativeRegisterThis
15:24:32 Trace [JniSupport] Invoking ANativeActivity_onCreate
15:24:32 Info  [Launcher] Executing main thread
15:24:32 Warn  [Main] Android stub called
15:24:32 Warn  [Main] Android stub called
15:24:32 Warn  [Main] Android stub called
15:24:32 Warn  [Main] Android stub called
15:24:33 Info  [Minecraft] android_main starting. internalDataPath is '/internal', externalDataPath is '/external'
15:24:33 Trace [JniSupport] Invoking start activity callbacks

EDIT works just fine. Just not the qt5webengine components of ubuntu 20.04.

The cpu socket of the raspberry Pi 4 cannot handle 16k page sizes.
4k and 64k are valid and something much higher. Compiled the kernel myself to increase the pagesize significantly on the old hardware.

from pi-apps.

@theofficialgman All bugs mentioned here are fixed, but you are required to install a bookworm AppImage.
As I mentioned before, the old AppImages are for pre bookworm and don't yet have an upgrade path caused by having the required glibc version

Notice only arm64 is tested with 4k and 64k pagesize.

You should use a -bookworm AppImage from the v0.12.1 release

• Session crash on exit (This is not expected and doesn't happen in kde/x11)
• Qt6 of bookworm AppImage works with wayland, game uses xwayland
• arm64 deb's can now sign in
• armhf deb's now exists for debian (bookworm and oldstable), but not installable on Raspberry Pi OS / raspbian. Distro issue
• Bookworm AppImage and deb cannot use qt6-webengine on 64k kernel
  • does chromium work on 16k? Because it crashed too, firefox works.
  • Fallback google login method can be used, xbox live has no fallback in the binary. Using a different page size works.

This is no longer considered an upstream bug for me.

from pi-apps.

• Session crash on exit (This is not expected and doesn't happen in kde/x11)

does this happen in the x11 openbox based session? which session crashes (piOS wayfire session I assume)? what about kde wayland session?

• armhf deb's now exists for debian (bookworm and oldstable), but not installable on Raspberry Pi OS / raspbian. Distro issue

I have gone ahead and created a bug report just now at raspbian via official methods for this issue https://bugs.launchpad.net/raspbian/+bug/2043742

• Bookworm AppImage and deb cannot use qt6-webengine on 64k kernel

oh yeah sorry I should have warned you about that. it is due to too old chromium version used in qt5 and qt6 webengine before they were patched for larger pagesize support, see -> raspberrypi/bookworm-feedback#107 (comment)

• does chromium work on 16k? Because it crashed too, firefox works.

on Pi5 chromium does work on 4K and 16K kernels

from pi-apps.

which session crashes (piOS wayfire session I assume)?

I think it was wayfire, the default.

Then I created a startx session which worked until next reboot.

Today with a 64k kernel I cannot reproduce the crash by running mcpelauncher-client from the cli. However my whole pi os frooze while in a world. (just after it slowed down to less than 1fps, typically running out of ram)

The mcpelauncher itself is buggy.

Didn't try kde wayland.

from pi-apps.

• Bookworm AppImage and deb cannot use qt6-webengine on 64k kernel

  • does chromium work on 16k? Because it crashed too, firefox works.
  • Fallback google login method can be used, xbox live has no fallback in the binary. Using a different page size works.

launcher login and xbox live login works fine in tested appimage on pi5 on 4K and 16K pagesize kernels

from pi-apps.