[Porting] Call for Testers
@dovla-ri I will try to refresh them a bit and link here again
@flohack thnx, because it is very difficult to track which binaries and what is the whole procedure of making install. If this can be somehow sum up in one document or even placed on your "original topic - first post", people can focus on that instead of bugging you with it every time...
@flohack I'd also be interested, I tried following the generic instructions from the wiki using the files provided in your link and it didn't work so I'm guessing there was something more to your original instructions.
Hi, I have spare Google Pixel. I am willing to test the build.
Alright guys I am working on the new instructions, this time in a pastebin, since the pad was destroyed over time: https://pastebin.com/EFLhqfLv
And this is my upload folders for marlin and sailfish: http://twoot.bin.org.in/nextcloud/index.php/s/iAZDDkRYYAiN6Kk
I wil refresh the images there tonight hopefully
@flohack looking at the nextcloud instance, the newest images are from 4 months back. are those the latest ones?
@khimaros No, will provide newer ones ^^
@flohack thank you! i was also able to produce a working droidian install on sailfish using your work as a base. really grateful for your efforts here.
@flohack actually, would you be willing to teach us how to fish? is there a way we can build or extract these
halium-boot.imgthe same as from https://ci.ubports.com/job/UBportsCommunityPortsJenkinsCI/job/ubports%252Fcommunity-ports%252Fjenkins-ci%252Fmarlin-sailfish/job/main/ ? is the
halium_sailfish.tar.xzthe correct one?
@khimaros yes our CI builds already all the necessary parts in this job. vendor.img and system.img are Androis sparse files. So you need to convert them first, then you can mount them as an ext4 image.
This post is deleted!
@flohack thank you. the
system.imgdoesn't seem to be present, but there is a
system/directory. is it as simple as creating an ext4 filesystem from that tree of files?
boot.imgprovided there doesn't seem to honor
bootmode=kernel command line args. does it need to be built with special flags to enable that?
i can produce a working ubtouch install by using the images you have linked from your nextcloud.
i was able to build halium-9.0 from source by emulating some steps in https://gitlab.com/ubports/community-ports/jenkins-ci/halium-build-tools/-/tree/main/ -- if i push the
vendor.imgproduced by that build, everything continues working.
if i push the latest
android-rootfs.imgfrom Jenkins-CI to
/data/, the system also continues working.
if i push the latest
vendor.imgfrom Jenkins-CI, with or without the latest
android-rootfs.img, the WiFi and Bluetooth break but the system otherwise continues working, including mobile data.
if i flash the latest Jenkins-CI
boot.imgto that installation, the device will then only boot into the recovery mode. i believe there is a compatibility issue with the "combined" boot image produced here and it might be worth changing the 4th parameter in the Jenkinsfile here to
i'm still not totally clear on how you are producing the
system.imgthat you have in your nextcloud.
Ok so here are the usual steps that we are doing for UT to boot and be installable later with a) our installer b) with the OTA system-image upgrader inside the device:
- First, we need to decide:
-- Is the device an slotted device (with A/B partitions and bootloader able to change slots)
-- Or does it use only the traditional partition layout? slotted devices were only around I thin for Android between 8 and 9. Whats important is the factory version that the device came with. If, for example, a device is later upgraded to Android 9, but was shipped with 7.1, it will not be slotted.
- For a slotted device, we build the kernel with
- For a traditional device we build it with
- But: Both ways just produce a boot.img file in the $OUT directory of the Android build
- Next: Some devices need a DTBO image, too. You can always try to
mka dtboimageand see if that yields an image file called dtbo.img. If so, this needs to be flashed together with the corresponding boot.img from the same build. They need to match, and failure to do so can create bootloops or stuck devices.
- Next: Some devices using verity have signed partitions, and any attempt to mount them will fail if the kernel detects that the partition has been tampered with. So, try to build
mka vbmetaimage- if that yields a vbmeta.img file in the $OUT folder, this needs to be flashed one time with
fastboot --disable-verification flash vbmeta vbmeta.imgto disable verity.
- Now comes finally system image: We just build
mka systemimageand this is the usual make target for what LineageOS is doing, with some changes by Halium and some patches. Nothing special here.
- The created system.img file from $OUT folder is an Android sparse partition image, not ext4, and so it cannot be mounted directly. This will be converted by installer and OTA updater, but for development purposes this is not usable directly
- Rather we use halium-install script or replace-android-image script to make a conversion to an ext4 image.
- Our CI builds all of those targets, tars the results up and publishes the artifacts as you already found out
- Our system-image server combines that tarball with the rootfs tarball to form another archive which can be downloaded and extracted for installation
- Now, for installation, 2 ways are possible:
-- Halium install method: rootfs.img and either system.img or android-rootfs.img live as image files side-by-side in the userdata partition (usually /data)
-- rootfs.img is extracted into system partition /usually /system or /system_root) and the system.img or android-rootfs.img is placed inside this partition into /var/lib/lxc/android
- Both boot.img or halium-boot.img will determine the layout and mount the images accordingly (some devices will need a datapart= kernel cmdline parameter to find data partition)
- If the Android system requires a system-as-root layout (And also Halium 9 requires this currently), you need to build your system image with
BOARD_BUILD_SYSTEM_ROOT_IMAGE := trueand then name it android-rootfs.img to indicate its system-as-root.
TLDR; I produced the system.img like described above, on my local PC
- First, we need to decide:
Keneda last edited by
All in the details, wow
Currently attempting to use other distros/OS on Marlin, it's been tricky through fastboot & twrp but despite me messing around with both a/b partitions... I managed to just flash the original image again
It's a treble compliant device with latest update being Android 10, is there anything that can simply be flashed from twrp? I don't mind wiping the system partition from both slots. My phone has a faulty battery anyway and im pretty much fine with the risks
@dasein No unfortunately the last situation is still that our rootfs + system image combo does not fit onto 2.5GB system partition and that prevents further porting of the device. Unless we invent a kind of split boot mode this is a severe blocker.
It might be therefore that this port never reaches installer and stable state.
Hello everyone! Am new to the forum, my current phone is the Pixel Xl (marlin) since my primary phone was damaged, am using the pixel XL with lineage OS but I really want to try out ubuntu touch! I don't use my phone much so I will not have a problem with some things not working, Am going to install ubuntu touch this evening, and I'll let you know how it goes! Let me know if I can help with something.
Keneda last edited by Keneda
Please do not post links like that if not relative to the topic.
If you have a personnal website to share, use your profile settings, there is a specific field for that.
And by the way, welcome on the ubports forums
sansgaming last edited by sansgaming
hey i have a pixel xl and i would like to help