I installed the new A.0105 ZIP with the old TWRP, immediately formatted data before rebooting because the old TWRP complained about FBE (the new TWRP didn’t), which is strange because I formatted data long ago and had no working OS in the meantime to encrypt it again.
The phone rebooted into the “Fairphone” screen, then into the “Try again / Factory data reset” screen again.
Instead of choosing anything there, I booted the old TWRP again and restored my A.0105 backup … and A.0105 boots again!
This would kind of correlate, with what I am currently thinking.
Please go into TWRP adb and get me the output of ls -l /dev/block/bootdevice/by-name/
I might have to build a new TWRP to get this fixed once and for all.
You probably won’t be able to update to 110 when you installed 105 with the old TWRP.
If you’re restoring via TWRP, you can connect via ADB while it’s doing that.
But no hurries, I won’t be able to build the new TWRP for another few hours.
BTW, if you want to be able to update from your 105 now after restoring data, you probably have to flash the product partition from the original stock dump with fastboot.
I also faced similar issues as @AnotherElk updating from 105 to 110. Fairphone logo kept showing up, deployed 110 with different TWRP versions, 105 with both versions.
This is what I did:
on a stock 105 I installed the old TWRP.
installed magisk over TWRP
OTA 110 failed -> restored boot.img from magisk -> to no avail
I flashed the @k4y0z 105 dump using adbfastboot flash -> again the OTA fails (due to dsp.img?)
sideloaded the 110 version with the new TWRP -> did not get beyond the FAIRPHONE greeting. Factory reset in stock firmware not possible. This is also the point where the corruption message started to show up.
flashed the 105 dump again with adb fastboot, this time replacing the dsp.img.
now I got the screen with the four rotating dots, but nothing happens.
tried to restore a backup via TWRP, failed with E:extractTarFork() process ended with ERROR=255 -> now I get only to the bootloader.
Thanks for your output, it confirms what I was suspecting, though it doesn’t explain why the old TWRP worked for you.
About sbl1 not matching that would also be explained by what I was thinking.
System could only be mismatched if it was mounted RW in TWRP.
@corvuscorax I have a very good idea now, what was wrong, though it will need to be tested, once I have built a new TWRP.
When you look at @AnotherElk’s ls output, you will see, that some partitions are missing a symlink to the current slot (i.e. sbl1 and vbmeta).
This would mean, these partitions with missing slots where not flashed during the TWRP install.
Which would also explain the corrupted system message.
Woah, I got the update finally working, too.
I flashed the TWRP flashable A.0105 -> ota update error
Then I flashed from the Stock dump with fastboot the dsp.img, system.img, boot.img, product.img and sbl1.img -> ota update error
And finally, I flashed the above image to the other slot (B) -> update to A.0110 worked!
I had this, too.
Before I could restore the data partition from my backup I had to set up my screenlock access method (PIN in my case) again in Android, only then was TWRP able to access the data partition again, and only then I was able to restore the data partition from my backup again.
To avoid confusion for people perhaps reading along never having used these … this flashing is done with fastboot.
adb and fastboot are different tools for different tasks in different situations.
fastboot is being used in Fastboot Mode (in this topic here e.g. to flash partition images to the phone, to boot TWRP without installing it, to check or activate the A/B partition slots of the phone), adb will not work in Fastboot Mode.
adb can be used for some other tasks when TWRP is running, or for even more other tasks when Android is running with USB debugging enabled. In these situations fastboot will not work.
New TWRP release is up.
This one finally fixes installing the full stock ZIPs.
Make sure you have the option “Mount system partition read-only” checked in TWRP if you want to be able to OTA.
I am preparing a stock image for version 8901.2.A.0096.20191001 (September 2019, v. A.0096). I am following k4y0z instructions:
Right now I have generated sparse images and corresponding dat-files for the system partition (nothing is produced by img2sdat for the other partitions). The truth is that I don’t even understand what are and why dat-files are required, it was my impression that sparse images alone were enough…
So of course I could also mimic k4y0z’s images for META-INF/com/google/android/updater-script, but I don’t know what to put in META-INF/com/android/metadata. Some fields are obvious, but what should be written exactly in post-build and post-build-incremental? I assume the other fields can be taken to be the same as in the other images.
I suspect on the one hand that all this is intended for diff-images, but on the other hand my understanding was that k4y0z was publishing full stock images… the image I am preparing comes from the initial ROM of my FP3, that was even pre-ordered before it was on ther market, so it will probably be the eldest ROM available, and therefore a full stock image (not a patch).
Could someone clarify these missing elements so that I can finalize this image?
I’m not sure if it really is required to make your dump into a TWRP-installable version.
It will likely mostly be used by developers and researchers and to use @corvuscorax payload_dumper to generate the intermediate versions using the official OTAs.
So it would likely suffice if you just upload the dump, as I have done initially for the 105 Firmware.
As for your other questions:
To create the dat files for product and vendor you have to pass the-p or --prefix option to img2sdat so it doesn’t overwrite the system images.
The conversion is mostly done for compressing the large filesystem-images (and possibly for error-correction) and this is the way ROM-Zips typically do it.
The info in metadata is from the /system/build.prop file (If you decide to mount the image, make sure you mount ro or use a copy, as for not to modify the original image):
Okay, I get it now, that is specifically useful for TWRP. Well, nothing is lost in doing it, then it is quicker to flash, and it can still be flashed manually file by file through fastboot.
Perfect, that was a silly mistake. What about the dsp partition? It is an ext4, but in your images you did not create corresponding dat-files and brotli-files I think.
You’d have to convert the product, vendor and system images again for flashing with fastboot, but yes that’s possible.
I did that initially, but given the size of it and the fact that it is mostly treated as an image like the modem partition I didn’t do that in the recent versions.
Also if you look at the output of the file command it would actually tell you, that system, vendor and product are ext2 while dsp is identified as ext4.
@k4y0z: I just saw in your images that you also flash a partition sbltest. Well, I don’t find such a partition on my device, what is that supposed to be? Everything else looks fine.
.
.