Minecraft Bedrock Launcher - Bookworm - 64-bit system #2463
Comments
|
|
|
@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 |
|
@theofficialgman doesn't work, same error |
|
@ChristopherHX thoughts on this issue? ^ |
Append the |
BTW no this doesn't work anymore, I got the edit as mail |
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. |
|
@ChristopherHX can confirm the issue on the arm64 appimage myself. passing 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. |
|
@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!! |
|
@theofficialgman Can you do My arm appimages are an old experiment... |
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 |
@ChristopherHX the warnings/errors go away but it still segfaults on |
|
Like I thought, I have no clue, why the AppImage is binary incompatible with your OS. So |
correct, it does not work |
I'm asking because, I never heard from the Your linux used a pagesize other than 4K? 16K requires hacks to fake a 4K alignment, so libminecraftpe.so can be loaded. |
|
The macOS m1 port uses such a hack, but the m1 macs never have 4K pages. |
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. |
|
@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 () |
theofficialgman
added
Upstream Bug
|
@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 |
|
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?
…On Tue, 7 Nov 2023, 14:48 theofficialgman, ***@***.***> wrote:
@ChristopherHX <https://github.com/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
—
Reply to this email directly, view it on GitHub
<#2463 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALOW2N4224LBJJKES6EKFDYDI33ZAVCNFSM6AAAAAA57HO7YOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGU2TKNZQGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@bagong 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 |
|
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 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
I understand, it would be for both of us a xxxl time consuming project to fix this issue. 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). |
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. |
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.) |
|
@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. |
no, it was not "older builds" that were snappy. orange pi 5 has a non mesa supported gpu in it (valhall II mali gpu). 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 |
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://exitYou can also try, and log in QT_QUICK_BACKEND=software mcpelauncher-ui-qtYou 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... |
|
Thanks both of your for tips and explanations. Everything happens as you predicted:
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! |
|
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). |
|
rpi4 with 64k pagesize (latest nightly of 0.12.0) loading so is ok. 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. |
|
@theofficialgman All bugs mentioned here are fixed, but you are required to install a bookworm AppImage. Notice only arm64 is tested with 4k and 64k pagesize. You should use a
This is no longer considered an upstream bug for me. |
does this happen in the x11 openbox based session? which session crashes (piOS wayfire session I assume)? what about kde wayland session?
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
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)
on Pi5 chromium does work on 4K and 16K kernels |
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. |
launcher login and xbox live login works fine in tested appimage on pi5 on 4K and 16K pagesize kernels |
Confirmations
What happened?
App won't start after install
Description
Well, after starting the program "the normal way" (clicking desktop-launcher in application menu) nothing happens.
I copied the exec-entry from the launcher into the terminal and got this error:
(apart from this I was a bit surprised that the install installed all the xyzhf-libraries. I thought that wasn't necessary with AppImages...)
What are your system specs (run the following command in your terminal)?
(Recommended) Error log? Terminal output? Debug messages?
The text was updated successfully, but these errors were encountered: