Ping me in a week if I didn´t

And by the way, welcome on the ubports forums

• Crazyc4t

It might be therefore that this port never reaches installer and stable state.

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

• 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

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.

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?

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?

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