the zip is currently not downloadable (the mirror it had been uploaded currently seems to be offline and it apparently didn’t propagate to other mirrors)
but from the one I downloaded yesterday, the images are identical except for missing zero bytes at the end of the smaller images - as you wrote below i get an exact match if i fill with zero bytes up to the partition size. this might cause a checksum mismatch if a larger image was flashed into the same partition previously.
Thank you, @k4y0z that worked!
But now when I try to flash a gsi again with fastboot flash system <system-image> I get the following error:
Invalid sparse file format at header magic error: write_sparse_skip_chunk: don't care size 183539441 is not a multiple of the block size 4096 fastboot: core/libsparse/sparse.cpp:131: int write_all_blocks(struct sparse_file *, struct output_file *): Assertionpad >= 0’ failed.`
Yes. I checked the MD5 … and the new file is *key.zip instead of *keys.zip.
Yes, but that doesn’t help much afterwards, or does it? Couldn’t the phone have changed slots because booting didn’t work out? (I noticed an automatic rapid reboot or two yesterday from the “Fairphone” screen when stuff didn’t work.) (Edit: Ok, such a reboot doesn’t seem to change the slot. At least not now when I had one and checked the slot.)
That’s why I made sure I knew the active slot with the second try.
I installed the new Fairphone_FP3_8901.2.A.0105.20191217_12171325_user_release-keys.zip (checked the MD5) with twrp-3.3.1-0_k4y0z-20200131-01-fp3.img on slot a.
The phone shows the “Fairphone” screen and then reboots … shows the “Fairphone” screen again, and then reboots into the recovery with the “Can’t load Android system. Your data may be corrupt. […] Try again / Factory data reset” screen.
The active slot is still a.
Once I “Factory data reset” there, the phone reboots straight into Fastboot Mode, and the slot is invalid.
By the way … that the TWRP script supposedly should install all the partitions, but only ever mentions system, vendor and product is ok?
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.