Elsewhere I read that someone said they would NEVER use flash and boot in the same command. Hence my questions:
Are there any reasons to actually flash the recovery image saying fastboot flash boot?
Could a failed fastboot flash boot indeed cause things to go wrong beyond repair?
Next I could imagine that one of the recovery images was simply broken:
lineage-19.1-20220802-microG-FP3-recovery.img - this worked on phone #1
lineage-19.1-20220820-microG-FP3-recovery.img - used on phone #2 this never let me boot into recovery
Lastly: One of the last steps in trying to work with phone #2 was go back to square one using FP3(+). Install Fairphone OS offline. Half-way during this process I got an error so the flashing aborted. I could still repeat it from a different computer from where it seemed to succeed, but only to enter a boot loop, that could only be terminated by pulling the USB cable, from whereon the device was dead as stone. Question here: Could a “weak” USB connection cause severe failure during flashing? Reasons I can think of:
problematic cable (mine was quite long)?
conflict between connection to phone and connection to external HD holding the image, where both are USB connections, i.e, could these two connections possibly conflict at the USB level?
If HW details of connections are critical, how can I find out in advance if my setup is safe?
Maybe some answers will help improving installation guides by alerting people to the various risks?
In general, yes. It depends on how the recovery in question works.
It could work by just booting it, it could work by flashing it.
The alternative TWRP recovery @yvmuell mentioned above on the Fairphone 3 works by just booting it, installing works via a script, flashing it to the boot partition doesn’t work.
The LineageOS instructions flash the LineageOS recovery to boot. I would suppose the LineageOS powers that be would know how to deal with their own recovery. (I don’t have experience with this recovery.)
I don’t think so.
Even if you flash the boot partition with something that doesn’t boot, you are still left with fastboot mode to repair the damage by flashing a working boot partition image e.g. from the stock Fairphone OS install files.
(The TWRP install instructions for instance say as much, also cited in the post above, so it’s a procedure which should still work.)
Same image, just flashed once more (stupid, for lack of other ideas). Obviously something broke right here, not having a partition table was the thing that made me want to go back to square one.
Does anyone have an idea, why the first command sent to ‘boot_b’ while subsequent commands sent to ‘boot’? I didn’t specify this on the command line.
Edit: Unfortunately my transcript doesn’t prove I used the same fastboot version in all commands. I do have an old version installed by Ubuntu, but I think I used this throughout that session: “fastboot version 33.0.3-8952118”.
I added at least a warning to the wiki, so that people always read the official instructions as well.
However I would say there is no normal process when you find errors you can correct when you have the trust level