Google Pixel XL 2 porting thread

[bootlessxfly]

Im saving this post for any future device specific instructions and links. 

[bootlessxfly]

@utzcoz wang, 

thanks for the suggestion, I am going to go ahead and start a seperate thread for this so we dont hijack the 6p thread.

On Tuesday, April 23, 2019 at 7:20:37 AM UTC-5, utzcoz wang wrote:

@bootlessxfly When I port MaruOS to Pixel, I have found the Pixel's prebuild vendor.img has the fstab file to configure data partition. If I use prebuild vendor.img, my modification for data partition to support MaruOS's root will effect nothing. So I use vendor built from code, which supports Project Treble also. Maybe it will help for your porting to pixel 2 XL.

On Tue, Apr 23, 2019 at 11:54 AM Preetam D'Souza <preetam...@gmail.com> wrote:

Excellent, I am looking forward to seeing Maru running on the Pixel 2 XL!

Once you get vanilla Lineage 15.1 built and booting on your device, go ahead and just repo init our official maru-0.6 manifest branch (which is also based on Lineage 15.1) and includes all the Maru patches so you do not need to manually add the Maru repos. You'll just need to add some device-specific stuff to your device repo (essentially the same as you did for the 6P previously) and update the kernel config, and you should have a build up and running with all the Maru bits on top of Lineage 15.1. We can discuss more specifics in your porting thread as needed.

On Monday, April 22, 2019 at 6:35:39 PM UTC-4, bootlessxfly wrote:

Sorry for the silence on this, I do have an update though.

I am going to hold off buying a 6p. I can still set up a build server for this and maintain the builds, but as far as having a device to test with, I will be holding off.

Today I took advantage of the 50 percent off Google Pixel 3 and purchased myself a new phone(I just couldn't pass up on that deal).

So, with a new phone, I can officially move my pixel 2 XL into Dev status and fully commit it as a Dev device. This weekend, I plan on setting up a dev VM on my desktop and building cynogenmod 15.1 for my pixel 2 XL. Once I have this baseline build booting, I will move to add the Maruos framework and kernel patches. At this point I'll start a Google pixel 2 XL device porting thread. My next update will go there.

Next month, if we still do not have a maintainer, I can look back into purchasing a Nexus 6p, but for now I am going to focus on the pixel 2 XL.

[bootlessxfly]

@utzocz wang,

Thanks for the suggestion. Ive heard that pixel phones have the ability to switch between different systems by leveraging project treble's dual partition schema. Let me know if I misunderstand what you are trying to say: Are you saying you have leveraged the double data partitions to have one partition with maruos system,kernel, ect. and one partition with stock everything. Creating a dual boot of sorts?

Wouldn't this setup share the user partition? And does sharing this cause problems between the two? 

If I misunderstood you and your trying to point me into a different direction, please let me know.

[utzcoz wang]

Hi @bootlessxfly, I mean when we port MaruOS to a device, we must modify the data partition mount option to allow Linux can root in data partition, but if we use prebuild vendor.img of Pixel, our modification of data partition mount options in code device directory is not useful because prebuild vendor.img also has the fstab to define the data partition mount options, which will be used finally, instead of our modification version in code device directory.

--
You received this message because you are subscribed to the Google Groups "Maru OS dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maru-os-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/maru-os-dev/9c2f97b7-92bf-4f49-86a8-bcb886ab483b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bootlessxfly]

@utzcoz, thanks for the advice. When I get around to booting the first time, Ill circle back around to this post to modify the fstab.

I built the patched wahoo (unified kernel for pixel 2/XL) kernel last night. I am about to start building maru now, and Ill post with updates as they come.

To unsubscribe from this group and stop receiving emails from it, send an email to maru-...@googlegroups.com.

[bootlessxfly]

I started a build last weekend, making it halfway through before getting an error:

system/libhidl/transport/include/hidl/HidlTransportSupport.h:84:6: note: candidate function not viable: requires 2 arguments, but 1 was provided

bool setRequestingSid(const sp<::android::hidl::base::V1_0::IBase>& service, bool requesting);

I haven't had to much of a chance to look since I ran into it. But figured Id post it on here in case someone had any suggestions. Ill attach my log too.

This seems to be some kind of library mismatch? Which makes me wonder if there is an issue with my project structure(Using wrong library files). I am using ccache. I would think ccache could possibly cause something like this also? I was thinking about running a lineageOS build when I get a chance to see if it also fails for that build. Maybe this weekend Ill be able to attempt another build. 

[bootlessxfly]

Finally got some free time to start playing around with this project again last week.

I was able to compile maru0.6 for the pixel 2 XL. Unfortunately, I wont have a device to test it out on until I get my pixel 2 XL back at the end of the month, so this is very much so untested.

I wanted to post this here in case any one wanted to try it out. If so, I can upload an image.

Here is the source:

# Kernel

https://github.com/bootlessxfly/android_kernel_google_wahoo

# Taimen Device

https://github.com/bootlessxfly/android_device_google_taimen

# Wahoo Device

https://github.com/bootlessxfly/android_device_google_wahoo

[Preetam D'Souza]

Nice to have you back @bootlessxfly! Looking forward to a Pixel 2 XL port!

[bootlessxfly]

Thanks Preetam. Excited to back working with the project. Im pretty rusty, so learning as I go. :)

Before I go into details, wanted to send a quick thanks to @utzcoz for pointing out I needed to manually modify the fstab in the extracted vendor folder before packaging it to remove "nosuid" from the data partition.

Also, wanted to thank Georgian for putting together a patch set for maru on lineage16!

While this is slightly off topic, I attempted to do a build for my Pixel 3XL running on lineageos 16. I unfortunately was not able to get it to boot. This included a stock lineageos ROM I built, an unofficial lineage16 ROM, and a lineageOS ROM with Georgian's patchset plus my device specific changes. Upon further research, neither the Pixel 2 series or the Pixel 3 series are supported before Lineage17.1. My understanding is that a recovery did properly work with the devices until LineageOS recovery 17.1 (Although I did not dig much into that claim).


So as it is, I have doubts that my builds will boot on the Pixel XL 2. I will still try of course.

I did test LineageOS on my pixel 3 and it works pretty much out of the box. No surprise there though since it is officially supported.

Right now, I think I am going to spend time exploring getting Maru on lineage 17.1. I've seen a little uhh chatter on this matter, but nothing concrete.

Anyways, Ill keep this post updated as I go along.

[bootlessxfly]

Okay. So I figured out the issue. It was with my kernel. For some reason the lineageOS kernel(Even without the LXC patches) for 16.0 will not boot for me. Ill installed a different kernel and the system booted fine. Ill continue to look into this. I have a hunch that there is something wrong with the kernel config from the crosshatch 16.0 lineageos repo. So I may find a different source tree and see if that boots.

[Preetam D'Souza]

On Saturday, September 12, 2020 at 7:37:51 PM UTC-4, bootlessxfly wrote:

Okay. So I figured out the issue. It was with my kernel. For some reason the lineageOS kernel(Even without the LXC patches) for 16.0 will not boot for me. Ill installed a different kernel and the system booted fine. Ill continue to look into this. I have a hunch that there is something wrong with the kernel config from the crosshatch 16.0 lineageos repo. So I may find a different source tree and see if that boots.

Nice, thanks for sharing your work here as your progress - I'm sure it'll be useful for anyone else doing a similar port.

[bootlessxfly]

I have not gotten around on testing a new kernel for the Pixel 3XL. But I do have an update for the Pixel 2XL.

I was able to successfully boot maru running both lineageos15.1(Although I have a vendor mismatch I need to fix) and lineageos16. I am running into an issue with starting the LXC container. This issue is two fold:
1) The desktop tarball is not extracting properly, this is fixed by removing the maru container folder and running mcprepare. I will have to look into this.

2) The second issue is I am unable to start LXC as a nonroot user. The error message I get is:

Now I noticed that one other person had this issue from the following post:
https://groups.google.com/g/maru-os-dev/c/WZB-oWXDFiE/m/0kkOyf4YBwAJ

I wonder if anyone in the community can point me to the solution for this?

But I was unable to see what the resolution was in the thread.

LXC starts just fine as root.

[bootlessxfly]

For whatever reason, my screenshot was not sent in the last message:

lxc-start: external/lxc/src/lxc/utils.c: mkdir_p: 203 Read-only file system - failed to create directory '//.cache/'
failed to create lock
lxc-start: external/lxc/src/lxc/lxc_start.c: main: 268 Failed to create lxc_container

[bootlessxfly]

Based on these two commits by pintaf, I am thinking that this is an SELinux issue. I am going to patch the sepolicy based on the following commits:

https://github.com/pintaf/android_device_motorola_nash/commit/ac580130dc9c3cc8c019f7cf773a61d8a1fc6b29

https://github.com/pintaf/android_system_sepolicy/commit/ffcf3df7ed9fd9ff86e46c549d90f102d984a693

[bootlessxfly]

Okay, good news. I got pintaf's maru0.7(lineage16) working on my Pixel 2XL. The init issue with maru was resolved, I fixed the invalid vendor, and applied the SELinux change to my device change. I tested that the container started and coneccting to a wireless display earlier today. I am going to try this on maru0.6 later. I can upload images in the next couple days.

I wonder if this is a way to add sepolicies to allow the container to launch rather than disabling it system wide?

[loicp...@gmail.com]

Hey.

Great that you could get a port working with my los16 version.

Normally if we add all sepolicies correctly, we should be able to launch the container and enable again selinux.

I remember I tried to solve some SE policies in the past when proting to HTC 10, and ended up in disabling it system wide...

https://github.com/pintaf/android_device_htc_pme/commit/876e40c8573383a07dc2b3bf6b6338e1b031ac13

Tell me if you get to something. On my side, I did not give up, I'm working on BQ Aquaris X2 to bring it to maru 0.7. I'm lacking time lately unfortunately. A little confinment would help me hahahaha.

[bootlessxfly]

I don't blame you, SE policies can be a bit of a pain in my experience. I may take a look at it in the future, and if I do find anything I will certainly let you know.

Thanks again for your work!

As promised, here is a link to the Download:
https://drive.google.com/drive/folders/1GSjn0W6_C3zzH9dt1z5G_ES8LjmJ1ReN?usp=sharing

The link includes both the ota update and full image. I prefer flashing the full image myself,  however the ota image is the official method. Regardless of which you choose, make sure you do a factory wipe before flashing.

For the Pixel 2, I do not have a device to test on and I would have to downport most of the lineage config from lineage17.1. If someone is interested in offering to test, I can attempt to build it.

I am going to do a new build with an updated kernel for the Pixel 3XL now.

[loicp...@gmail.com]

When you're happy with stability and/or finished testing with other kernels, tell me, and I can integrate your device sources in maru-0.7 manifest so that anyone checking out the repo can build Pixel 2XL out of the box.

[bootlessxfly]

You can feel free to add the sources. I've tested it and it works pretty good with casting.

With Displaylink. it's a different story. But given Display link's proprietary nature, this may not bother people. With displaylink, two issues occur:
The virtual framebuffer is hardcoded to 720p(The maximum supported resolution of casting). Unfortunately with displaylink, it will not signal the monitor to also change to 720p and instead displays 1280x720 pixels on a 1080p(In other words roughly 60 percent of the screen shows maru and the other bits are black)

I created a build where I modified mflinger to default to 1080p instead of 720p. This breaks casting, but allows for displaylink to work. We may be able to leverage a config file to give us the ability to switch between 720p and 1`080p, and not have this hardcoded. But I am going to leave it alone unless someone wants both displaylink and casting support.

The other issue is an occasional kernel panic when watching a full screen 1080p video from the LXC container. I am wondering if this is due to graphics being accelerated by software(CPU). I did not see this issue when casting at 720p.

Another note, I was able to boot using a hallium patched kernel. For those unfamiliar, halium is a implementation of libhybris that is supposed to provide an framework for different projects to load libhybris. When time permits, I may try to get the rest of this build ported over to halium. One big difference is the approach would be that the android userspace would be loaded in LXC, and not linux. But, in my opinion, this may be to Maru's advantage. When trying to run docker or KVM out of a LXC container, you start needing to provide root permissions to the container. Switch android into a LXC container and assigning the container the phone screen's framebuffer should allow android to perform as a rootless container as normal. Running the linux userspace outside of a container allows us native access to docker and other virtualization software.

The biggest advantage of course, would be hardware acceleration through libhybris.

Anyways, when/if time permits, I'll continue to work on porting maruos over to halium.

[loicp...@gmail.com]

Hey, Yes, perfect, I'll add this into the maru 0.7 repo when I'll get the time.

Good work ! You lost me in your tech talks, I'm a front end dev trying to survive in the Android dev porting environment.

Great to have you supporting maru !

[Loaf]

Do you have any updates on the Pixel 2? (Sorry this is 5 years later but I have a Pixel 2 myself and was curious to where you have gotten)

[Loïc Poisot]

Hello. No progress at all! 

Now my focus is rather on Ubuntu touch, sailfish os, post market os...

They are real Linux distributions for phone and dispite some limitations they are more in line with the privacy I expect from my phone. 

I had the project once to merge Mari OS with /e/os, but time is a previous resource I currently lack quite a lot

--
You received this message because you are subscribed to a topic in the Google Groups "Maru OS dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/maru-os-dev/zNB94U6IPaY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to maru-os-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/maru-os-dev/a0ad39c1-6df1-449b-b169-032e3cd58b60n%40googlegroups.com.

[Loaf]

dang it, okay! thank you for getting back tho :)

[luka...@gmail.com]

Hi, as Maru OS isn't active maintained anymore, you might be more interested in Lindroid, https://github.com/Linux-on-droid We are doing similar thing to Maru, but with some noticeable extras. Hope its ok to post this here. Anyway thanks a lot to Loïc Poisot. We still have some Maru legacy, like perspectived :)

неділя, 21 вересня 2025 р. о 10:56:13 UTC+2 Loaf пише:

[Loaf]

thanks man, I'll be glad to be part of this :) see ya on the otherside brother

[chris white]

Hi!

A couple of things I’ll add on: I had working Pixel 2 and 3 trees, though I can’t remember if I actually submitted the MR to bring in mainline. Since the project is no longer maintained, that’s probably a moot point.

For anyone looking for a non-root way to do this, I used to run Linux (Fedora/Ubuntu) inside a proot container. Proot translates userspace syscalls into kernel calls, which can mean up to ~30% CPU performance loss. That said, I run my laptop as a thin client into a homelab these days, and nothing I do is CPU-bound. On Qualcomm devices you also get Freedreno, so no syscall translation is needed for graphics, which gives you a fully functioning Linux laptop without modifying the base OS. I actually ran this setup as my daily dev environment (including kernel work) for about a year with a NexDock XL and ultrawide monitor, and it worked well.

On the security side, I created a custom work profile: personal profile had frozen Google services and only F-Droid apps; work profile had Aurora Store + minimal Play Services for the apps I had to run. I bridged anything else with AdGuard locally. It’s basically a Graphene-inspired model, but without root.

I’ve since moved away from converged setups due to time constraints, but I think the best path forward is still non-root if you want mainstream adoption. There’s not really a fully functional self-installing proot distro out there for laypeople right now, but it’s definitely possible. Just sharing in case that’s useful.

---

Chris

To view this discussion visit https://groups.google.com/d/msgid/maru-os-dev/9e8f1e43-ee99-48d8-9af7-4ee892710898n%40googlegroups.com.

[chris white]

Hi,

I should add a quick note. :)

Proot overhead is often quoted as “up to 30%,” but that really only applies to very CPU-bound tasks that rely heavily on kernel context switches or hardware acceleration. For most everyday workloads, I measured the performance hit to be negligible. Anything primarily userspace-bound doesn’t incur extra overhead, since no syscalls are being made.

For example, if you set up GNOME and strip out dbus, you end up with a UI that adds very little Proot overhead. XFCE also works well, as it makes relatively few syscalls. In both cases, you still get access to the full Linux application ecosystem. The heavier hit comes with tasks that require lots of kernel-space context switching. But the nice part is that you don’t need to modify the system at all — you can bind your Proot distro directly to Android desktop mode (or DeX) and even automate launching Linux via Tasker whenever you plug into desktop mode.

Now, if you’re working on a rooted device (whether Graphene or stock Android), there isn’t really a need to lean on LXC. Yes, LXC gives you a security-focused, “out of the box” way to run system containers — but it’s not out of the box on Android. Looking at projects like Lindroid, you still need to enable kernel bits to make LXC usable. As of Android 15 and 16, I see no indication that the required namespaces have been enabled in stock kernels. That leaves only two options today:

• Run Linux in Proot or an unhardened chroot, which preserves Android’s stock security but gives you no meaningful isolation inside Linux.
• Or, build a custom kernel tree with namespaces enabled, which provides isolation but means giving up the security and support of the stock Android build.

This is the core scalability problem: you either give up security around Linux, or you give up the Android-provided security model of your device.

Because of that, I’d encourage people to look seriously at pKVM as a backend. I know, Qualcomm doesn’t support it yet — but they won’t have much choice long-term. Reports indicate Android 16 will package pKVM with hardware acceleration, which would eliminate the need for custom hybris builds per device. Right now, you still need root to use pKVM, and Pixels are the only devices that fully support it. But Google seems to be pushing Android 17 to bring official Linux app support using pKVM, which could finally give us a standardized path forward.

Also worth noting: there is a native X server implementation for Android, and with Wayland you can use tools like waypipe to pipe output directly to an Android client without needing a full Wayland port. That gives you another clean option for running graphical Linux apps in a non-root setup.

Lastly, I realized I never shared this with the community, and I should have. A while back I co-authored and published an IEEE white paper that uses this project as an example to map out different operating system convergence techniques. It’s titled “Operating System Convergence: An Example via the Maru OS Project.” The paper credits Preetam and the community as a whole. I’d be happy to share a pre-publication PDF if anyone is interested. It looks like the Lindroid folks have independently worked through many of the same ideas, which is great to see. :)

I only played a small part as a maintainer and occasional contributor, but I have nothing but fond memories of working with this community. I still believe strongly in the potential of OS convergence in the mobile space. While I don’t have the bandwidth to contribute code here these days, I’m always open to exchanging ideas. And I wanted to share these concepts here in case anyone wants to explore a different architecture.

Cheers,

Chris

[luka...@gmail.com]

Hi,

I did briefly look at pKVM and proot and even chroot, and still continued to work on Lindroid. Main reason to rebuild kernel and make it "worth" is mainly not even lxc, but a thing called lindroiud-drm https://github.com/Linux-on-droid/lindroid-drm-loopback, point beeing implementing zero-copy hw acceleration with low latency, as that is the only way to allow smooth performance in even heavy worloads, animations and other asspects that are hard or impossible to solve with poor proot, without changing compositor. As for pKVM hw acceleration, its virgl with noticeable latency and performance penalty. Also hybris dont have to be patched in any way for device. And as for piping wyalnd out, its all fun, till you figure major compositors like kwin hevaily rely on drm subsystem for ANY backend, including headless, as well as gbm/dma buffers.  I'd be happy to see the IEEE paper.
Thanks,
Luka

неділя, 21 вересня 2025 р. о 21:24:23 UTC+2 chris white пише:

[chris white]

Hi Luka,

Great to meet you — I watched your presentation at Volla Community Days last year and really enjoyed it.

Your work on lindroid-drm is especially cool. I hadn’t come across it before and I’ll definitely look through it when I get a chance. From what I’ve seen, virgl can get close to peak performance on a clean Linux host, but the Android implementations I’ve tested haven’t been great. I assumed Google would be pushing optimizations toward Imagination DXT going forward, though that wouldn’t apply broadly. By contrast, your DRM loopback with hybris looks like the most effective path to real performance, even if it requires root and kernel changes.

I’ve also been following how Google is approaching this under pKVM. My impression is that a lot of the DRM problems are sidestepped there, but at the expense of latency and raw performance — two different designs serving two different purposes. That’s also why Linux apps under ChromeOS feel a bit laggy, even though they still run reasonably well. Their new Linux Terminal feature on Pixel devices (Android Authority) seems aimed at Linux app support within an Android-based desktop mode. GrapheneOS is also adding user-facing virtualization with GPU acceleration on the roadmap (GrapheneOS forum). And I’ve been keeping an eye on the Venus project too, since it looks like it could help with some (though not all) of the performance issues you mentioned.

I thought I remembered you experimenting with waypipe at some point — though I might be misremembering, since I can’t find the repo now. For context, I ran into similar issues when I tried launching Wayland from a proot environment in headless mode. At the time I assumed it was just permissions and lack of root access, but your explanation makes it clear there’s a bigger dependency on compositor/DRM that I hadn’t accounted for.

I really like the direction you’re taking with Lindroid. It feels like the clear answer for anyone who needs native performance. The challenge, at least here in the US, is that rooting has become much harder: locked bootloaders, disabled features, broken banking/pay apps, and voided warranties. That’s one reason I stepped back for a while — it became more about fighting hardware restrictions than testing ideas. In that sense, I still think pKVM (or even proot, hacky as it is) has a role: more for Linux as a thin client with app support versus running heavier Linux apps natively.

I’m also attaching the IEEE paper. Much of what it covers you’ve already addressed(Plus more), and since it was written about four years ago, some of it is a bit dated.

Best regards,

Chris

To view this discussion visit https://groups.google.com/d/msgid/maru-os-dev/c9996a6f-c286-40d8-8036-00480378ff4cn%40googlegroups.com.