no, and i don’t think you can actually use it for direct sideloading - I just duplicated the format @k4y0z used in his images. Only content are the partitions (format <partition_name>.img ) that are included in every OTA update, which are dumped from the phone. I dumped them like this (example for slot A):
for each partition name in slot a, then i got the images down with adb pull
the metadata I added by analogy by copying info from the one in the differential update for the same version, I don’t know if that’s good for anything.
then just zip it all together with maximum compression
the list of partitions I simply used the same set that the FP OTA update updates (payload_updater in fakediff mode will list them)
as in flashing it on the phone again? no, not yet. since it’d be a downgrade, that likely wouldn’t boot without erasing userdata, which is something i want to avoid right now since funny enough I actually need the phone for everyday use right now that’s also why i haven’t rooted or installed LOS yet.
I don’t know any better way to re-install those partitions than you described in TWRP for Fairphone 3 which would be one by one, using fastboot.
I know I was previously able to boot from that slot (which got overwritten in the latest update) but only if I erased userdata (mentioned upthread)
edit: as I understand it, if you installed the latest version using OTA, you can always go back to the previous version (if the phone is unlocked) by simply switching slots and erasing userdata. the OTA update will install the new version in the currently unused slot, then switch slots, but it doesn’t erase or alter the old one (if it did, my images would have failed checksum tests)
Actually, the flashable zip is a really good way to re install the partitions :). For the fastboot cmds, you can do a little .sh
I understand, that’s my daily phone too ^^. I have done too many times the erase userdata haha ! And the backup of the data with TWRP works pretty well. You can loose your documents, your photos and you have to re-set your password but everything else works. But I’m not sure, and I won’t test, that it works with different ROMs.
As far as I understand it, the zip in the format we have it is not directly flashable because the system partition is too large. @k4y0z overcame that to create a “sparse” image, but while that might install via sideloading I don’t know how to create, unpack or verify that. (I looked into the zip, but couldn’t figure out the file formats)
I can’t make one of those without further documentation, but most likely anyone can make a sparse image from the full image, later.
I am using img2simg first to create a sparse image from the ext4 (that’s available as a package in my debian).
Then I use img2sdat to create the dat-files.
and then i pass it through brotli -q 6 (also available in debian) to create the brotli-files.
I do this for system, vendor and product.
The rest of the partitions are straight dd-images.
You can do the reverse process for confirming they result in the same images.
Then update META-INF/com/android/metadata and META-INF/com/google/android/updater-script with the ROM-information.
Should probably create a sript that does all this automatically.
Do you have the source for that update-binary that is used to unpack it all? all other packages I found so far seem to use a shell script in its place.
the FP3’s chipset is supposed to include a radio chip. The driver is in the kernel, but doesn’t show up in dmesg, so it might be a device tree / configuration issue. Since the “chip” is actually an integral part of the system-on-a-chip it might be possible to copy paste the config from another device with the same hardware (linked in linked thread)
if (vbmeta_header.flags & AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED) {
AvbSlotVerifyResult sub_ret;
avb_debugv(
full_partition_name, ": VERIFICATION_DISABLED bit is set.\n", NULL);
/* If load_requested_partitions() fail it is always a fatal
* failure (e.g. ERROR_INVALID_ARGUMENT, ERROR_OOM, etc.) rather
* than recoverable (e.g. one where result_should_continue()
* returns true) and we want to convey that error.
*/
sub_ret = load_requested_partitions(
ops, requested_partitions, ab_suffix, slot_data);
if (sub_ret != AVB_SLOT_VERIFY_RESULT_OK) {
ret = sub_ret;
}
goto out;
}
I guess that’s load_requested_partitions which is broken
instead of compiling the kernel using the kernel build scripts, they used an android-build-environment which assembles and packages the kernel, dtb and dtbo containers using the scripts in
in combo with @k4y0z own kernel modifications which in turn are based on @z3ntu kernel modifications of the fairphone released kernel sources which were needed to get the kernel to actually compile, boot in general and with TWRP in particular.
But a big factor was probably using the android build environment instead of kernel make files to package the image with device tree in the way aboot wanted it.
for more details you have to ask the lords of chaos
Actually using the android build environment ist just way more convenient, when building TWRP.
Im quite certain with my modifications and config it would also work using the build-scripts.
The main things to get it working where enabling (probably only needed for fastboot boot, not when flashing the kernel) CONFIG_BUILD_ARM64_DT_OVERLAY=y
Which got rid of the “dtb not found” error, but requires using an external device tree compiler (DTC_EXT).
And patching the kernel to ignore the skip_initramfs flag the bootloader sets. (So it actually loads the TWRP initramfs instead of booting straight into the OS)
My config also enables the serial console (UART) which was usefull for debugging, but not required for it to work now.
I actually had tried that ( building the overlay with system installed dtb compiler ) but I still had eun into dtb not found, must have been how the dtbo was included unto the boot .img . There is aprox 5 different ways
I tried with @z3ntu a while ago with just that option enabled and built without android environment, and that made the error disappear.
Are you sure you used the Image.gz-dtb?
image.gz-dtb (which is the image.gz with dtb’s concatenated)
image.gz with manually concatenated dtb database created with dtbtool
image.gz with separate dtb in .img - as created with fastboot with --dtb option
image.gz with separate dtbo in .img - as created with fastboot with --dtbo option
the same as 3 and 4 but with dtb database created with dtbtool
and a few combos with both dtb and dtbo in various combos. i never got past the dtb not found, but its possible i somehow missed the one working solution.
Since we didn’t know in which form arima aboot expects the dtb(o) we were looking into the serial uart debug outputs, to get some pointers, but you got it working before I could get a 1.8V uart converter put together
that’s also why i haven’t rooted or installed LOS yet.