You could try another factory reset and format data before booting again.
You could also try to install Android 10 Fairphone OS available here (choose Fairphone 3(+) - Flashing with fastboot - Android 10), and then try to install /e/OS 1.4 (Q) again after that to see whether it makes a difference.
As @Januario has a TWRP backup of the /e/OS 1.4 (Q) data partition, the sensible thing to do to restore this data is to install the matching /e/OS 1.4 (Q) beforehand, @Januario is correct in trying this. The Easy Installer will not help with this, as it will install a current version (and stable only, but this is less important for this case), and a current /e/OS version will most probably demand a factory reset for booting when confronted with a restored /e/OS 1.4 (Q) data partition.
done. Result fine, when there is no SDcard inserted. Else, the device deadlocks.
done; outcome the same as above. I then went back to FPOS10, shut it off after installation and inserted the SDcard (it’s the SDcard that has worked okay on /e/1.8). Here I was prompted with “How will you use this SDcard?” I left the phone untouched so far lest any decision would lead to erasure of all data on the SDcard.
Is this conjecture accurate?
If yes, what would be the steps to use the SDcard and the data on it (especially the TWRP backup) on /e/1.4?
There is a slight chance in case the SD card is formatted and was used as external/portable that if you choose to use it as external/portable the phone would just leave it be. But I surely wouldn’t bet the data on the card on it.
Copy the data off the card to a computer, let Fairphone OS format the card, try to install /e/OS again, let /e/OS format the card again perhaps … and with the card hopefully working with /e/OS, copy the data back to the card and proceed?
Or get /e/OS running without the card first, just insert the card for using TWRP to restore data, remove the card before booting /e/OS, see that /e/OS works with the restored data, then figure something out with the card at the end?
I have followed your advice barring “restore data” when I restored “boot”, “sytem” and “data”. Unfortunately this hasn’t worked either. On slot “A” I ended up in TWRP, and after switching to “B”, an error message appeared in TWRP “rescue party triggered” and I ended up in /e/recovery.
I am at a loss.
Could it be that the backup is faulty?
Or that there is something wrong with the card? After all, this card has worked properly before something happened to magisk, the device got unrooted and I tried to restore root; all of this actions which IMO do not have anything to do with the SDcard.
In my experience you can’t restore any system partitions successfully (meaning you can boot the OS afterwards) via TWRP, just the data partition.
So just install the OS version fitting to the data backup in the normal way, boot the OS, setup your screen lock (= data encryption/decryption method) in the same way it was for the backup data, then restore only the data partition via TWRP.
That’s interesting… actually, I have restored “boot, system and data” a couple of times successfully in the past. Anyway, I’ll give your advice a try, of course.
Interesting indeed, this never worked out for me when I setup my backup regime. But it was quite some time ago when I tried, and I didn’t root my phone.
Whatever works, I guess … Good luck!
/e/1.4 keeps having problems with my SDcard (the OS outright crashes/hangs). That SDcard has been approved by a higher version, /e/1.5 and then 1.8. I think the problem is related to this problem I had 2 years ago with my SDcards.
I chose “data” and “boot” only in TWRP. But I used an older version of TWRP which did the trick: 3.7.0_09 instead of 3.7.0_12. I think the older one is the one I made the backup with. Outcome: restore successful, apps, settings and Magisk/root there, but still hassle because of the SDcard. The phone gets warm and hangs.
The important finding here is that it apparently matters which version of TWRP is used to do the restore. I had assumed that using the most recent version of a software would cover all and any cases, but that conjecture seems to be wrong.