[Porting] Call for Testers
@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?
@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 last edited by
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 last edited by
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.
@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?
@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