[Porting] Call for Testers

khimaros

@flohack -- i'm referring to the documentation at https://docs.halium.org/en/latest/porting/debug-build/early-init.html#forcing-debug-mode:

If the device simply reboots when trying to boot and does not bring up telnet, you may build and use the hybris-recovery.img file to attempt to force a shell to come up.

this is the circumstance I'm bumping up against. maybe there is a new way to troubleshoot this?

flohack

@khimaros Well here is the problem: While we claim to be a Halium distro, we are only sharing some of the codebase, and you need to know when to break off from the Halium docs and return to UBports

If you have reboot issues best bet is to wipe data, then flash halium-boot and see if it still crashing. If yes, your kernel is screwed, if not it should give you telnet. Also adding break=bottom to kernel cmdline will stop before the real init to inspect the device and mounts etc.

woodenLion

Help please, as I am getting "chroot: failed to run command ‘chpasswd’: No such file or directory" and don't know what to do.

AppLee

@woodenlion
I suggest you start a new thread for your problem as right now I have no idea what you're trying to achieve there.
And please give some context about what you're trying to do what you did before the error, specify the versions, etc.

dovla-ri

@flohack Hi. I found my old Google Pixel phone (sailfish) and I would like to try your port. Where can I find some instructions how to remove android and install ubports on it?

Thnx.

flohack

@dovla-ri I will try to refresh them a bit and link here again

dovla-ri

@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...

nixcamic

@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.

vs4vijay

Hi, I have spare Google Pixel. I am willing to test the build.

flohack

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

khimaros

@flohack looking at the nextcloud instance, the newest images are from 4 months back. are those the latest ones?

flohack

@khimaros No, will provide newer ones ^^

khimaros

@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.

khimaros

@flohack actually, would you be willing to teach us how to fish? is there a way we can build or extract these vendor.img and system.img ourselves?

is the halium-boot.img the same as from https://ci.ubports.com/job/UBportsCommunityPortsJenkinsCI/job/ubports%252Fcommunity-ports%252Fjenkins-ci%252Fmarlin-sailfish/job/main/ ? is the vendor.img in halium_sailfish.tar.xz the correct one?

flohack

@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.

khimaros

This post is deleted!

khimaros

@flohack thank you. the system.img doesn'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?

also the boot.img provided there doesn't seem to honor break= or bootmode= kernel command line args. does it need to be built with special flags to enable that?

khimaros

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 halium-boot.img and vendor.img produced by that build, everything continues working.

if i push the latest android-rootfs.img from Jenkins-CI to /data/, the system also continues working.

if i push the latest vendor.img from 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.img to 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 false: https://gitlab.com/ubports/community-ports/jenkins-ci/marlin-sailfish/-/blob/main/Jenkinsfile#L2

i'm still not totally clear on how you are producing the system.imgthat you have in your nextcloud.

flohack

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 mka bootimage
For a traditional device we build it with mka halium-boot
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 dtboimage and 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.img to disable verity.
Now comes finally system image: We just build mka systemimage and 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 := true and 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

Keneda

@flohack
All in the details, wow