Yes missed that Oops!
1 Like
Your topic reminded me of the following one:
In this case only the tilt sensor did not work and it refers to a FP2.
But the interesting thing (and probably relation) is that installing UT changed it (in that case it solved it).
So it’s another hint that UT does something with the sensors which other OS don’t and even a factory reset doesn’t…
2 Likes
@mhv Thanks to that hint from Luca Weiss on your issue I have indeed been able to get things working again. It requires getting root using magisk and then as root running restorecon -FR /mnt/vendor/persist which restores the SELinux attributes. After a reboot everything should work again! 
5 Likes
Oh, that’s great, will have to try it tomorrow, I’ll report back as soon as I do!
In Linux systems that have SELinux enabled as well it’s often recommended to relabel the whole filesystem if SELinux was disabled at some point. I’m not sure if Android has support for that. The command fixfiles onboot sets a file in the root (/.autorelabel) and then at boot the whole is relabeled. Just my 2 cents in the context of Fedora/Red Hat systems.
As I don’t have magisk set up I was wondering if you know if I can run this from a recovery image like twrp? I see that /mnt/vendor/persist is /dev/block/sda3 on my phone, but I’m not sure if running restorecon from recovery will do the same as when the OS is running (I need to read up on SELinux one of these days…)
Just tried this and it didn’t help. Guessing the “SELinux attributes” needs to be set by the running OS, so I’ll give Magisk a go.
You don’t need a proper Magisk setup for this, just install the app and use fastboot boot patched_boot.img, make your adjustments, reboot.
I have uploaded some prepatched boot.imgs in this folder, if you want to skip patching the image.
1 Like
I wouldn’t do that as you need the correct file_contexts. You can relabel everything manually, but it will be a lot easier when file_contexts is known, because else you will have to specify everything by hand
Will your prepatched boot.img work if I’m running DivestOS, or would I have to go back to the Stock OS?
In that case I would suggest extracting and patching the boot.img that’s shipped with DivestOS, just to be safe.
Edit: I had an extracted one lying around already, here you go 
3 Likes
Thank you, but I just did it myself, a great learning experience. Downloaded yours and it has the exact same md5sum as mine even, so I think I did it right 
2 Likes
AND IT WORKED!
So in summary:
- You need to get a root shell in your currently installed Android flavour, either via permanent or one-time booting to a magisk image
- Run restorecon -FR /mnt/vendor/persist
- Reboot
As people have mentioned here and elsewhere MESSING WITH THE PERSIST IMAGE CAN BRICK YOUR DEVICE, so do this at your own risk!
I’m not sure if or how I could get into contact with the right people, but maybe this is something the default OS package should fix automatically? I won’t make a very hard argument for this, as it will probably only affect people who should be able to fix it themself now that this thread exist.
Thank you very much everyone in this thread!
8 Likes
If there’s any interest from fairphone developers or others, I extracted an image of my persist partition before and after the restorecon operation, so one could see exactly what changed to make it work again. (This is after a DivestOS install, but from my understanding “persist” should be the same for all Android installations?)
1 Like
Even if I probably won’t know what to do with that information, I would love to have a look and see the difference 
Not sure if there’s privacy-sensitive data in there 
(somebody knowledgeable should answer that)
If there isn’t, please upload it somewhere 
2 Likes
That is exactly what I would like to know as well, if not I could just upload the files. I have to go out for a few hours, but I’ll look into it.
A quick diff shows me the only differences are in these (binary) files:
/hvdcp_opti/soh_info.txt
/time/ats_1
/time/ats_12
/time/ats_13
/time/ats_15
/time/ats_16
/time/ats_2
(yes the .txt also contain both text and binary data)
A low hanging fruit method would be to run the command strings on those files and see if you notice anything personal there. But this is just a very basic check.
2 Likes
Be aware that the persist partition is unique per device and using someone others persist will result in wrong sensor calibration and you will also have wrong DRM keys and MAC-addresses as those are stored in persist as well.
Its not the content of the files itself that has changed but just the labeling that is wrong… you could check those with ls -Z
1 Like