Hi
Little update of the week end…
First, i tried to flash some other images (vbmeta_system vbmeta init_boot pvmfw recovery vendor_boot) according to the order followed by the eos factory script. i didn’t try further because i must read more carefully what is done on the next step.
Due to that, i am now able to reach fastbotD and recovery (murena ???).
in fastbootd, i was able to get some more informations, fastboot getvar all gives me the confirmation that dtbo_a and dtbo_b are not logical :
@aibd i’m pretty sure fairphone support won’t want to help me since the phone is second hand with no bill and no informations about where it was bought.
For now the phone only boot in fastboot or fastbootD or recovery (with adb sideload available) but I’m pretty sure that with some help (which you are currently providing and I thank you a lot for that) i will be able to make my phone work again.
Are you aware the source of “sideload” images for FP6 is https://ota.ecloud.global/api/v1/FP6/official/
I have been wondering what sort of event in the device’s past could have caused the apparent corruption of dtbo_a (and I guess dtbo_b) ?? Would I be right that you took the phone for a satisfactory test run before you started and it was running Fairphone’s regular Android?
If you have e-Recovery and fastbootd running perhaps you have satisfactory content in dtbo already ?? I wonder if there is still the possibility maybe that some variant of “buggy USB fastboot” means that Volume Full should maybe not be taken in quite the literal way we have been seeing it ??
@aibd
not sure about what could have happened to the phone before i get it but it was running fairphone android os. I used it for some days without errors except it was not able to self update. That was one of the reason I wanted to switch to /e/os.
The recovery I can acces is similar to yours (i just found surprising th murena splash screen appearing before)
Do you think flashing image from your link could be a solution ?
What do you mean by buggy usb fastboot ?
Maybe flashing after removing the dtbo from flash script could help if the current content of dtbo is “satisfactory” ?
@mihi
If you could provide the result of fastboot getvar all i could check the differences in partitions sizes
Thanks @mihi I can see that everything is the same except dtbo_a and dtbo_b sizes
and like @piero points, your dtbo’s partitions size are the same as the file dtbo.img
Do you think flashing image from your link could be a solution ?
the Android Updater was failing to use the OTA_PACKAGE offered so you would get similar if you were to try adb sideload.
What do you mean by buggy usb fastboot ?
Now that you have more forensic evidence the comment is probably not pertinent but if one checks the Platform-tools release notes bugs within Fastboot, especially for a new device, are not uncommon. The comment was really about certainty of evidence, now seems more clear.
It is possible that Fairphone forum readers can be more useful than my uninformed
have a go ideas.
If you felt you are able to see how Parted works and how to avoid accidental changes, the thing I would be looking for is “empty space” adjoining dtbo which might indicate and validate the theory that the partitions “got shrunk” somehow … then is there potentially space to restore them without messing with the whole partition table.
fairphone support won’t want to help me
I do believe that Fairphone aim to support their devices is a correct commercial way. I would expect them to respond if this error is recognised by their engineers as requiring reimage.
Hi
I finally tested flashing /e/os after removing dtbo from script… and it worked.
I had an issue with screen lock code and like it was suggested in another thread, i reflashed stock fairphone rom (after removing dtbo from flash script), deactivated screen lock code, reflashed /e/os, and now it is fully functional.
I’m pretty sure that there will still be errors on updating via OTA so i will now open a thread on fairphone forum since it appears to be mostly related to firphone instead of /e/os.
I will update this thread as soon as I have an answer.
Thanks a lot for your help, everyone.
Going forward you may find it interesting to learn more about https://source.android.com/docs/core/architecture/dto/partitions. Very loosely speaking dtb provides a “map” for bootloader / recovery. Once you had Recovery running correctly it gave the hint that the existing dtbo was useful and / or accurate (to an extent).
The next update or manual sideload will then I guess test whether this dtbo is acceptable to the sideloaded image. A log of that event might be useful. You could consider moving to the testing channel to run this test sooner rather than later.
Maybe before you get too committed to stuff on your phone you could also experiment with your own Fastboot updater script where you would alternately flash slots a and b (ofc no format data) in the event sideload fails. I haven’t actually checked but within the OTA_PACKAGE I expect the sideload updater script hidden perhaps in /meta which will give a clue which partitions are written by an update.
