Results:
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.
At which point I’m wondering … How can I determine afterwards to which slot I installed the ZIP?
Edit:
I had a look beforehand now and installed to slot a.
I rebooted into Fastboot Mode and
fastboot getvar current-slot
current-slot: a
Finished. Total time: 0.001s
So it seems it’s not the installing that makes the slot invalid.
Tried to boot the OS … freezes at “Fairphone”.
Rebooted into Fastboot Mode … slot is still a.
Is there anything I could check with fastboot or TWRP now?
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.`
Can you confirm you used the new file I uploaded today?
md5sum: 428bdfe207aab70fad51fe4da33e8d6c
In my opinion that doesn’t make sense at all, fastboot boot should work regardless of the current slot being bootable or not.
However the workaround for this is to set the slot active using fastboot, which will reset the retry-counts: fastboot -set_active=<slot>
The ZIP will be installed to the current slot.
You can see in the TWRP reboot page which slot is currently active (and switch slots)
I am unsure, what could now be the issue.
Please make sure you used the new upload from today.
Also @corvuscorax If you could also double-check again, that the new version has the correct images?
I have also reuploaded the 105, because it wasn’t finding mirrors:
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?
That’s strange, when it showed that “Try again” message, Factory reset has always worked in my tests to bring it back.
The other partitions are flashed in a different format, and there is just no output in the script.
You can check META-INF/com/google/android/updater-script in the ZIP-file.
I’m not sure what is going on at this point, maybe @corvuscorax has an idea.
It should restore all the partitions to the original ones and boot without issues.
EDIT:
OK, I have another idea what might be going on, can you please go into adb shell in TWRP and do ls -l /dev/block/bootdevice/by-name
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.
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.
.
.