mosen

@steebThere is a fix now i tested to relabel the sensors folder in persist into the SELinux context. I updated the backup/restore/repair guide with instructions. Would be great if you flash a persist backup with working keys but broken sensors. And test the restorecon fix:

The EDL cable is just a USB cable with extra switch to short lines. It is only ment to set the phone into EDL mode more easily than using `adb reboot edl` or the manual "Both volume rockers pressed until droid flashes shortly" methods. An edl cable has no implications to the flash process other than that. stolen from https://wiki.bananahackers.net/development/edl/diy-edl-cable

Edited the first post with working repair instructions using restorecon. Ii just now successfully found that way to be working on my side. 🥳🎉

To clarify. I try to not suggest anything. Missing competence for that. I merely try to describe what happened to me, like usually in a user forum 😅 Reseting EDL by booting the device into EDL again worked for me to make the edl commands continue. But i never had to do that consequently many times and have no idea of the implications of doing so.

@Ivaylo HubanovYou should be able to set the device into EDL mode anytime by: - Hold both volume buttons when device turns on. (There was a suspicion that the pwr-key is needed too, but it works with only both vol rocker buttons held.) - Release them right when the droid logo flashes up for a split second. - If the screens stays black, thats EDL mode. You can confirm this with `lsusb` showing up a qualcomm gobi modem. Thats the Pro¹-X in EDL mode. - When it boots, goes to fastboot or recovery, just try again by holding the pwr-btn for 10 seconds to force reboot. Troubleshooting: -

Strictly EDL on the Pro¹-X. Its very convenient not having to unlock the bootloader to flash imo. Having much experience with fastboot from doing user support over at AsteroidOS. I am using and debugging Fastboot a lot and i really appreciate to now learn about EDL more. In AOS, we don't have rooting problems 😛 We even got our very own universal community bootloader with integrated adb server. So debugging a WearOS smartwatch and prepare it for porting is as easy as "fastboot --cmdline debug-ramdisk boot aos-bootimage.fastboot" to boot into the bootloader and have full adb. Where is the mag

Sorry, still traveling. Quick clarification, i did back up all mentioned partitions since i was advised so by someone that all of those are device specific and might help in the future. For now, i only played with restoring persist. That one always restored fine. I flashed like 20x back and fourth testing several broken states that lead into non-boot situations. But was always able to get back to the backup state.

Tadi and Bru AI on Telegram are proficient in rooting the Pro¹-X already. I'll try to compile some step-by-step instructions when they showed me how to.

Could you make a screenshot of where the "Rooted ADB" switch is in the Android 11 settings. I looked through all developer settings multiply times but can not find it. As expected, without that permission "adb root" fails with "adbd cannot run as root in production builds".

EDL works with locked bootloader. Fastboot does not. Might a locked bootlaoder be the issue?

Small clarification, you can just take any Pro¹ or Elephone U/Pro fitted protector since the display of our Pro¹-X is exactly the same. Protectionfilm24/Schutzfolien24 @Hooklinked above just reacted fastest to my information that the Pro¹ foil they cut fits. As i could try having a spare Brotec foil for the Pro¹ around and applied it to the Pro¹-X. Same perfect fit. The Elephone U/Pro search will likely even bring up tempered glass screensavers. Those have never been marketed for the Pro¹. But fit nicely, again due to exactly the same display unit. But i am not a fan of those, imo they br

Firstly, congratz! The backlight should auto switch on and off when you slide the keyboard from android build 2.1.0 on. Check in the bottom most settings item for the build number. it should say 2.1.2 since that's what the production run was flashed with. In that case, i'd advise to contact support@fxtec.com. If its a lower build number, you could try flashing a newer on. dd`

@VaZsogreat to see! Thanks for the longish first impressions! Can confirm, the built quality is excellent imo Kudos to @Erik btw for designing that awesome animated bootsplash logo. Care to share what format you used and where you pushed it to 😅 I could try make one for SailfishOS and UB.

And another thing i learned, F(x)tec should be able to reprovision the devices with new keys. It seems to be a standard support issue. Afaiu, they can assign new keys as trusted source in the chain.

No, as long as they remain in the data/ folder within the persist partition they are supposed to work. I saw in other devices that the data folder containes human readable codes. But in our case its encypted gibbrish names and folders. But generally, as long as the data folder with these keys exist. They should be recoverable. The SELinux hint makes much sense after having read the restorecon manpages. Looks like what ever we change in the partition needs to be updated in the SELinux security layer. Afaiu now. But its Pool time now. No idea if i return to a computer today 😄

I got a hint from TheKit just now that it might be related to SELinux context. He advised me to try restorecon on the sensor folder in a rooted adb environment. https://www.thegeekstuff.com/2017/05/restorecon-examples/ I have no means to try for the next hours so maybe someone else is quicker.

Latest update: Whatever i remove or add to the partition when mounted like described above, i get a non booting device. Even copying the known working backup sensor data into a copy of the working persist backup, leads to non boot Flashing back the unaltered backup always works. I highly suspect the mount method above leads to file permission problems when copying stuff. From my PoV, all permissions look exactly the same. But the problem must lay in permissions since i copy know working things together and get a complete non boot. I also now know a bit better how i jumped to concl

I removed the part with removing the sensor folder. Since when testing again now i got the same result like you had. I must be mixing up images or something stupid... But the good news, flashing back the unaltered backup worked to solve that. I will add a disclaimer to the Repair part above. Its obviously just for educational purpose to narrow in the solution in the current state. Maybe we just found the reason why it takes F(x)tec so long to get the official documentation out 🤪

I can not guarantee that above is already final since i feel a bit like a lonely tester on this. It worked for me. But no one is around me to save me from jumping to wrong conclusions and build on them 😅

Afaiu, its from booting into a flashed alternate OS. While installing those, you just flash boot and userdata. If you for some reason decide to abort right after flashing those and flash back only those two from the stock image set. Its like nothing happened.

Yupp, sorry for the salami tactic. I have written a guide. But that just worked for me. No guarantee that i did not mess up at some point while testing to come to the conclusions. Happy to get corrected.

It is highly advised to take a backup of your device specific partitions right after you receive the device. Update 20220829: tl:dr: Community has not found a safe way to restore backups as of yet. Making below described backups is still highly advised for a future where some wizard found a reliable way to restore those backups. For now, if you have broken sensors from flashing another OS, the restorecon method described in the "Repair sensors/ folder..." section does 100% work to fix those while retaining your attestation keys. While restoring any backup has a high chance to make the keys

I am writing instructions for a complete backup thread just now. Copying the data folder from the backup to the stock persist did not work. What worked for me however is to copy the sensors folder from the stock partition to the backup persist. EDIT:

Good news. It has been done. I am not at a computer currently but essentially what people in the Pro¹ Telegram group did is to copy the whole Data folder from the persist backup to the stock persist image. Will be able to test later today.

They are crypto keys that get checked against or contain the serial of the device or the IMEI. As far as i figured from diving into Android Developer Docs. I tried to "clone" a testing devices persist with keys to the production Pro¹ X with lost keys. But that did not work. But yes, the partitions being ext4 should mean we can copy the keys from a backup with broken sensor config. Afaiu, thats whats being tried currently. Maybe it will be a dd method where we merge the working parts into a new persist. Fingers crossed.