change to ubuntu bionic for arm64 build #9
Conversation
Update main.yml for CI build
|
Does it still run on the Raspberry Pi? |
|
Yes, I tested this change on a raspberry pi3 running ubuntu 20.04 arm64, google login worked. |
|
No, I was just wondering. Haven't tried it yet, will do so tomorrow. I am on a (actually multiple) 64-bit systems running debian buster. Thanks, I am glad this is an ongoing thing! |
|
So I tried this on an X64 machine running Ubuntu Studio 21.04: I updated using the button in the launcher (didn't try to reinstall yet). There is trouble: the updated launcher tried to download the latest Minecraft BE-version (1.17.10.04 (X86_64) and my login is not recognized. I have logged out and in again, according to the launcher, I am logged in to Google Playstore (Google thought so to, it accepted my credentials and made me sign the TOS, though it warned me this login would only work on something Samsung S8 related), but when the download of the latest Minecraft binary was attempted again, I got an error message: "Minecraft BE has to be purchased on the GPS [which it is - I can play with the respective account on mobiles, and have been doing so with previous versions of this launcher]. If you are trying to download a beta version [I am not]..." (I am the same guy that enquired about the RPI earlier, but by coincidence I am running this on a X86_64 machine now). Note that the authentication problem only becomes apparent on an attempt to update the MC_BE-binaries. Before that you appear to be logged in just fine.... |
|
I'm unable to reproduce this without using a google play account not owning the game.
You can be logged in with an account not allowed to download the game, then google play doesn't provide download links to apks. also this PR changes 0% of the launcher from v0.2.3 if you aren't on arm. Also this works for some other people There was versions of the launcher which allowed to run illegal apks, this was removed. The versionscode is correct for germany so isn't causing issues either. |
|
Ah no, sorry, this is more complicated (I just reinstalled the old version and found this): after I had updated to this launcher via the button in the launcher, the launcher actually tried to download the x64-version of the binary, while it had been using the x86 (i386) version before. I hadn't even noticed that the launcher was previously using a 32-bit binary. The download of the 64-bit version failed with that (maybe?) misleading error-message I quoted above. So when using the 32-bit binary things work as expected. So I guess the only question would be, why the launcher attempted to download a 64-bit binary now, while it used 32-bit binaries in the past. Another question might be, if there is any chance of getting actual 64-bit binaries run on 64-bit systems ;-) |
Because the launcher is 64bit since 1 year. macOS Catalina cannot even run the 32bit launcher anymore. Are you shure you are on v0.2.4?? In Settings>about |
|
Yes, I am on v0.2.4-AppImage-x86_64 .... (build 670) But when I referred to the "binary" I meant the Minecraft binary that is downloaded when you press the green start button (if there is an update). I wasn't clear on that, sorry... So after I had updated the AppImage from the launcher, the launcher tried to download a 64-bit-minecraft binary (X68_64), while it always/automatically downloaded X86 binaries in the past. I would be happy to use a 64-bit MC-binary, but I guess that is not possible on a system with 64-bit Intel processor (Core 2 Duo P8600)? PS: I don't want to overuse your time, but another thing is unclear for me: the install reco's I followed suggested for both amd64 (Ubuntu) and arm64 (RPI) systems to install 32-bit versions of graphics related libraries (armhf and i386). Is that actually still necessary, or would the recent system also work with 64-bit libraries? (I have an add-architecture armhf block for the arm64 system, and i386 for the Ubuntu system, but I'd rather use 64-bit libraries if possible...) |
|
I updated on two RPI4s using the 64-bit Debian Buster and everything went fine. On that OS the launcher actually downloads a ARM64-V8A release of the Minecraft binary, and it did so in the past already. I still wonder - do I still need the 32-bit graphics libraries that I installed on the system following somewhat older install-descriptions, or could the current app-image also work with the 64-bit versions of the same libraries (libx11-6, libxext6, libegl1-mesa and more)? Same question for an x86_64/amd64 system - if I had the full set of of required libraries in their 64-bit versions installed, might a 64-bit Minecraft binary work (actually, do x86_64-binaries of MC_BE-edition from the playstore exist? I thought Google Play/Android was all ARM? I still wonder why the launcher suddenly tried to download "1.17.10.04 (X86_64)" when the "1.17.10.04 (X86)"-binary of the same version was already locally available. Is that architecture reference maybe created by the launcher, rather than retrieved from the Play-Store. Was the authentication error-message maybe triggered by an attemt to download a non-existent MC-binary)? Btw, all the MC-binaries I am referring to are straight from the Google Play store, I am not trying to install anything fishy, I do have three proper Google Play licenses for Minecraft BE, and no apk's that I want to "experiment" with ;-) |
|
Your core due is to old for Minecraft x86_64, it will not launch. Open the troubleshooter for a detailed report.
No, you can uninstall all 32bit stuff, you can still open Minecraft 64bit after doing that. BTW: As far as I tested the arm32 minecraft has better performance on my raspberry Pi 3/4.
You might found a bug, but you shouldn't see 64bit versions on a core duo device. (I have no such old 64bit device). You might get that message, because the launcher removed x86_64 as valid architecture for your device during login but somehow you was able to select an 64bit entry which shouldn't be visible.
No, the amazon store/Android is all ARM.
64bit is always prefered on 64bit devices, but it is a bug for your device. |
|
Ah, it gradually clears up, this all makes sense now. A corner case, probably not many core 2 duo's left... Thanks for answering the 32-bit libraries questions!
Unfortunately I don't remember precisely. I was used to automatic login, so I only manually logged in and out after I got the misleading error-message. I must have updated the AppImage by clicking the pane you provided, then restarted as advised, after restart hit the green start button, thereby triggered the MC-binary download (without noticing that it was now 64-bit), got the error and then manually tried to renew the log in. |
|
@bagong, Please check launcher v0.2.5 and report back if it now stop providing any x86_64 versions as latest for your core duo. I haven't checked the architecture in one function, x86_64 was on top so you saw a strange bug. (you wouldn't have seen it on last Monday) |
|
Thanks Christopher, update on Core 2 duo machine went well, using x86 consistently as expected now! Thanks again! |
|
Christofer, you seem to have disabled issue reporting, so I drop here an observation with the x86 MCBe-binary on my Core 2 duo using Ubuntu Studio. Unfortunately it's not a proper bug report, as I cannot trigger the error on purpose, but I think it's better you get this feedback in case you bump into something similar, where my experience might be helpful as an additional input. This happens: if I play with this client on a dedicated server (happened both on a private server on my home-lan, and on a Nitrado MCBe-server I set up), and during play get submerged by water (could be a small channel, a pool or a river) there is a considerable risk of a crash, and unfortunately a crash that makes the server unuseable for that particular user henceforth (trying to reenter the server either ends with a crash, or - on an phone using official Android client - ends stuck in some image-less location like 0,55,0 from which I cannot teleport to an existing location. I have had this happen 4 times now over a period of about a month, and had to use an backup of the world to make the server useable for that particular user again. Other users of the same server are not affected. The problem seems not to occur on Minecraft Windows 10 proper (with the same user), and it also does not seem to occur with with your clients that I use on the RPI (as described above: 64-bit Debian using the official 64-bit arm MCBe client.). As the crash is unforeseeable, it is hard for me to set up a test-environment, and as the consequences are so dire, I kind of shy away of an attempt to create the crash in an observed environment. When it happened today the only thing close to technical feedback is this log in the console of the Nitrado server:
In this case the server actually crashed as a result of my attempt to join the server after the crash had occurred. This was not usually the case on my private (official Windows) Server. Sorry for not being able to be more precise, but I thought this might be helpful, because the one stable occurence in all my crashes with this client was the fact that they happened when I got submerged by water. Thanks for your consideration |
|
PS: this problem is not related to this particular release, I've had it with older versions as well as the subsequent one as well, I just drop my observation here, because you also know my environment from the preceding reports. |
|
@bagong issues should go on the manifest page https://github.com/minecraft-linux/mcpelauncher-manifest/issues as you are aware, this is a PR which has long been merged |
|
@theofficialgman , of course, I just didn't know where to place the issue. Thanks for the link. |
Update main.yml for CI build
this will allow nvidia jetsons and nintendo switch on bionic (which is what nvidia still ships) to play the game. Tested and all working for me.
let me know if you want anything changed here