Move to latest Debian release 'buster' #19
Comments
|
Can I help? CS background, getting into building a better OS for devices, interested in this project. Previously ran an XFCE desktop on a chromebook via chroot and have been interested in getting a running version of chroot (not Proot, though it works) on my droid 4 (sliding keyboard and HDMI port are very nice) In short, what can I do to help? |
|
@nbbm26 Thanks for getting in touch. I believe that we are already in a position to build buster containers, but there are probably things we need to migrate over to buster to have Maru run properly (check whether there were any package dependencies that changed that we may need to explicitly depend on, changes to default security policies on the desktop that we have to handle, etc.). I would suggest first getting Maru running on your hardware so you can get familiar with the system (if you own one of our supported devices that's easy, otherwise you can learn a lot by doing a port). Do you have Maru running yet? I am planning to make the move to buster as one of my next tasks in the next few weeks. Perhaps once you have Maru running, you can help test the buster images on your device to help me make sure all is well. |
|
Yeah, getting the standard devices would be easier, but doing the port would be better. I need to get an extra SSD at some point for the storage and then do the build. Gonna be a little bit before it's going. Quick question: would it be possible to add an extra mod like in XPosed GravityBox that would allow a hardware switch between the running OS? Also, putting the not-used OS to sleep would be great, WITH running RADIO off the android system because that's really the easiest workaround for proot/chroot. Also, have you tried forking essential parts of the OS into a Boot option like toram for linux? Would be great to speed things up.
Sincerely,
Nbbm26
nbbm26@protonmail.com
(347)389-5385
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
…On Thursday, September 26, 2019 2:32 PM, pdsouza ***@***.***> wrote:
***@***.***(https://github.com/nbbm26) Thanks for getting in touch. I believe that we are already in a position to build buster containers, but there are probably things we need to migrate over to buster to have Maru run properly (check whether there were any package dependencies that changed that we may need to explicitly depend on, changes to default security policies on the desktop that we have to handle, etc.).
I would suggest first getting Maru running on your hardware so you can get familiar with the system (if you own one of our supported devices that's easy, otherwise you can learn a lot by doing a port). Do you have Maru running yet?
I am planning to make the move to buster as one of my next tasks in the next few weeks. Perhaps once you have Maru running, you can help test the buster images on your device to help me make sure all is well.
—
You are receiving this because you were mentioned.
Reply to this email directly, [view it on GitHub](#19?email_source=notifications&email_token=AGHBU2TZM7J2L5BDQOGEJ23QLTBYXA5CNFSM4IMKMSVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7VY7PQ#issuecomment-535531454), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AGHBU2R3QIIWQOZRIGSF3N3QLTBYXANCNFSM4IMKMSVA).
|
|
@pdsouza The Chrome OS 80 will start using Debian 10 Buster on new Linux installations. And I have found that we can build |
|
@utzcoz Oh, that's great to hear we can easily switch to buster! Have you tried using |
|
@pdsouza I have built it manually to debug problem in pixel. And it looks fine. You can just replace |
|
OK great, I will test it out.
…On Fri, Nov 15, 2019 at 12:56 AM utzcoz ***@***.***> wrote:
@pdsouza <https://github.com/pdsouza> I have built it manually to debug
problem in pixel. And it looks fine. You can just replace stretch to
buster in build command to build and test it manually.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19?email_source=notifications&email_token=AACMM4RLXAEM5GV6MDCH7RLQTY2YRA5CNFSM4IMKMSVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEEMU7Y#issuecomment-554224255>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACMM4TLAITC2B6JBKMG3CTQTY2YRANCNFSM4IMKMSVA>
.
|
|
Ran into an issue building a buster container for armhf: This issue happens when curl'ing the Maru gpg key to install the Looks like there is an issue with the buster In order to support our armhf devices (Nexus 5, Nexus 7) on buster we will need to work around this. I tried installing the older With this patch, the build succeeds! So I pushed the container to my Nexus 5 and tried starting it and hit some early errors: These are errors thrown by For arm64, I was able to build an arm64 buster container successfully without any changes. But sadly, both (!) of my Nexus 5Xs have died (very likely it was the common hardware failures reported for 5X) so I don't have an arm64 device for actually running the container until my new phone arrives later this month. |
|
I tried downgrading systemd on armhf buster using stretch's APT repository but I ran into issues installing XFCE dependencies for the desktop. That's a no-go. |
|
In order to confirm my hypothesis that this is indeed due to some change in And what do you know... This confirms the issue is with |
|
So I cloned Fortunately, I happened to stumble upon this very helpful error documented in the Halium project. Apparently, there was a change in v233 that switched from using It works!! |
|
One more issue: I ran my container in graphical mode with an external monitor and noticed that all the icons on the desktop are missing. With some searching, it looks like building armhf buster containers on a 64-bit host with QEMU causes subtle errors due to This manifests in errors like the following during building: Fortunately, it appears that this should be fixed if using a later version of QEMU that's available on buster. I am going to try upgrading our build Docker images to buster, which I was planning to do anyways since we are upgrading Maru Desktop to buster as well (similar to how we transitioned from jessie to stretch). The tricky thing is that we will by moving from LXC 2 in stretch to LXC 3 in buster, which brings some major changes to |
|
@utzcoz I have pushed up patches to support building Buster containers on branch |
|
@pdsouza I got below error when building blueprints: |
|
I used custom lxc image server, so I will remove cache and rebuild the blueprints to test again. |
|
Hi @pdsouza, |
|
@pdsouza I have tried to use travis to build buster online, and it failed too, see https://travis-ci.org/utzcoz/blueprints/builds/626511647. |
|
@PifPof73 hammerhead needs a kernel patch to run buster containers due to the new version of But in the future if you'd like to test, you just need to: You should then be able to boot into the new container. |
|
@utzcoz Hmm, ok. Thanks for testing. I thought I was able to successfully build an arm64 image on my machine... I will try again to reproduce this error. |
|
@utzcoz I just ran the same build command as in the Travis CI test and I was able to successfully build an arm64 container! Strange. Maybe it is related to the host kernel? I am running on Arch Linux with a very recent kernel (5.4.3-arch1-1 x86_64). |
|
Here is my log of the successful build on my machine: https://pastebin.com/b5CVkNjw It gets past the shared-mime-info error on Travis CI without any QEMU errors. |
Thanks. Do you have a boot.img available for Nexus 5? |
|
@PifPof73 I have a debug boot.img I used for development but not sure if it will work with your older system partition. I can upload it if you really want to test though — let me know. |
@pdsouza Look like Travic CI doesn't build buster, and it only builds strecth. |
|
In the docker buildx issue Building for ARM causes error often, docker tools developer say the QEMU 4.0.0 fix the problem. |
|
Buster uses QEMU 3.1. Maybe we can try installing QEMU 4.1 from bullseye to test it out. |
|
I tested QEMU 4.x with bullseye, and it failed too. And I found QEMU crashed when running |
|
Ok thanks for testing @utzcoz. Maybe we will have to selectively use
qemu-i386 for armhf only, and use normal amd64 qemu for arm64.
…On Sun, Jan 5, 2020, 10:38 AM utzcoz ***@***.***> wrote:
I tested QEMU 4.x with bullseye, and it failed too. And I found QEMU
crashed when running update-mime-database.rel, what is executed by
shared-mime-info posinst.
The script can build armhf buster, succeed, but failed for arm64.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19?email_source=notifications&email_token=AACMM4VABDVBVF5TGMAD2UDQ4H5FRA5CNFSM4IMKMSVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDZN5Y#issuecomment-570922743>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACMM4SVYHTTGVYD6FADJD3Q4H5FRANCNFSM4IMKMSVA>
.
|
|
@pdsouza In travis CI, I remove the |
|
@pdsouza I clean up the blueprints out, and my machine builds |
|
Hmm. I will test your commit on my machine to check. I can send you the
arm64 image I build to test too.
…On Fri, Jan 10, 2020, 10:54 AM utzcoz ***@***.***> wrote:
@pdsouza <https://github.com/pdsouza> I clean up the blueprints out, and
my machine builds arm64 succeed. But when I push the modification to use
two dockerfiles to support different architecture, the travis build failed.
The commit is docker: Add dockerfile for aarch64 and armhf
<utzcoz@4ccfb4a>.
And unfortunately, the built arm64 buster rootfs show the black screen to
me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19?email_source=notifications&email_token=AACMM4TDSXNUABOYBOIXUGLQ5CK45A5CNFSM4IMKMSVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIULFTA#issuecomment-573092556>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACMM4S3XSOAFHG4ZOOPDPTQ5CK45ANCNFSM4IMKMSVA>
.
|
|
@utzcoz I sent you an email with a link to an arm64 build I did with your commit for testing. Let me know how it goes. |
|
@pdsouza Your generated rootfs has the same problem, and I use |
|
And I install |
|
@utzcoz Thanks for testing! I recently picked up an HTC10 so I finally have an arm64 device for debugging. I will look into what's going on when I get some time. |
|
@pdsouza I found a very interesting problem. I have said I can change |
|
@utzcoz Oh wow, interesting. Yes, probably some library related to Xorg has changed. I haven't had time to debug this issue yet, but hope to do so soon on my HTC10. |
|
Hi guys! |
|
@pdsouza The |
|
The modification is in /*
* The key control system call
*/
SYSCALL_DEFINE5(keyctl, int, option, unsigned long, arg2, unsigned long, arg3,
unsigned long, arg4, unsigned long, arg5)
{
kdebug("keyctl option %d", option);
switch (option) {
case KEYCTL_GET_KEYRING_ID:
return keyctl_get_keyring_ID((key_serial_t) arg2,
(int) arg3);
case KEYCTL_JOIN_SESSION_KEYRING:
return -1;
// return keyctl_join_session_keyring((const char __user *) arg2); |
|
And there is my operation log: |
|
@utzcoz Wow, nice debugging man! I have been busy and haven't been able to follow up on this so thanks so much. Maybe we can merge this kernel hack in for now? This should let us merge in the two Dockerfile approach you are using in your fork right now? |
|
ok guy soon will test building los 16 |
Hm facing this problem |
|
@luka177 Do you use the |
|
yes |
|
@luka177 Maybe you can install |
|
Hi there. Little update. Any idea on where I should focus on this power button issue? |
|
I found some other weird issues like the maru desktop being displayed on the screen phone |
|
@pintaf Thanks for the feedback! As @utzcoz mentioned, I will be merging this to master soon. And thanks everyone for your patience on this taking forever, I have been swamped with other work lately. But I should be able to get everything fixed up this weekend. |
|
Alright I've merged in @utzcoz's dual Dockerfile approach to master. I just built and ran an armhf buster container on my Nexus 5 and it appears that things are still working normally like when I tested it last time. The next official release will include buster containers by default. We can always revert back to stretch if needed. If there are no other concerns I will close this issue in a few days. |
|
Looks like Travis CI still fails to build arm64 buster containers: https://travis-ci.org/github/maruos/blueprints/jobs/725457381#L4377. They build fine on my desktop though. |
|
A very strange phenomenon, if I run arm64 building firstly, it will success. But armhf building will fail. @pdsouza I create a new pr to fix it with splitting building with two travis instances. |
|
@utzcoz Thank you for looking into this so quickly! I also noticed that if I build the other way, i.e. arm64 first and then armhf, that if I first mount Either way, using separate travis instances is a good solution! |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Buster has been released and we should upgrade from stretch ASAP.
Press release: https://lists.debian.org/debian-announce/2019/msg00003.html
Overview of new stuff: https://wiki.debian.org/NewInBuster
Complete release notes: https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html
The text was updated successfully, but these errors were encountered: