mosen
-
Content Count
90 -
Joined
-
Last visited
-
Days Won
7
Posts posted by mosen
-
-
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-
2
-
-
Edited the first post with working repair instructions using restorecon.
Ii just now successfully found that way to be working on my side. 🥳🎉-
1
-
5
-
-
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.-
1
-
1
-
-
@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:
- Do NOT move or touch the device during the flash. Connection interrupts will cause edl.py to hang. Redo the process in this case.
- When a EDL command hangs, from my experience it is enough to force reboot the device again and enter EDL mode again. The commands continued as soon as the EDL mode was entered again. In my case.
- Ignore the red warnings edl.py throws. Those are non blocking. edl.py will stop at any blocking error. As long as it finishes a process, that one went well.-
1
-
-
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 magician building such for the Pro¹-X 😅 But i guess thats reinventing TWRP when it comes to phones.-
2
-
-
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.-
2
-
1
-
-
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.
-
2
-
-
On 8/13/2022 at 12:34 AM, EskeRahn said:
Make sure that your phone is in developer mode [*], and allows adb to connect as root (the phone does NOT need to be rooted)
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?
-
2
-
-
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 break to fast and need replacement. Yeah, its the point of that system. But i dropped my Pro¹ multiple times hard with only a protection film applied. I was lucky.-
2
-
-
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 [email protected].
If its a lower build number, you could try flashing a newer on. dd`-
1
-
1
-
-
-
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.
-
1
-
-
30 minutes ago, sspiff said:
Question: is it possible for my tests to have caused my keys to be revoked by whatever authority hands these out?
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 tryrestoreconon 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.-
1
-
-
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 conclusions it might be working.
I only copied the stock sensor folder onto a working backup. That continued to boot and work.
But turns out i did not fix anything since the sensors where working all along in that backup.
All i did was not destroy things further... But the conclusion is, overwriting same files seems fine and did not lead into non-boot.
Also, i can flash mounted working backup images just fine, indicating the mount alone is not the problem.-
1
-
-
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 🤪-
3
-
-
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 😅-
1
-
2
-
-
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. -
1 hour ago, sspiff said:
Copying the sensor data from the downloaded ROM and then flashing (using `edl w persist persist_backup.img`) did not fix the keyboard & rotation for me.
I did not remove the directory before copying the stock sensor files into it - so it still contains more files from my backup, not just the files from the stock ROM. Should I remove the directory and replace it with the stock ROM files only?
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.-
1
-
-
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 inaccessible in Android and can make your situation worse currently.
Ideally, backup before flashing an alternate operating system to your Pro¹ X. This has nothing to do with a data backup (e.g. using adb backup or backup apps) you might not mind too loose since you got no daily driver data on a device yet. We are about to backup all the partitions that can be needed to restore a fully working stock android. E.g. for the case you want to resell the device. Or just re decide and want to use stock android again after having tested an alternate OS.
Problemscape:
- When flashing and using SailfishOS or Ubuntu Touch (no info for LineageOS yet), the sensors folder in the persist partition gets altered. Since both OS are not in SELinux context when writting, causing the security context to break.
- This will lead to non working sensors in stock Android like described in this thread.
- The persist partition additionally contains device specific hardware attestation keys and EFS values generated during first setup of stock android.
- To be able to use Key Attestation and working sensors after a flash back to stock android, we can NOT just flash the stock persist.img since it misses our keys.
- We need a backup of persist with our keys and the correct sensor data. Ideally taken when you receive the device.
WARNING: Do not flash the stock persist manually like advised in deprecated XDA posts. You will loose your keys and a method to re-provision them is not yet found.
If you have no backup but your persist partition is broken already from booting UT or SFOS.
Check with the android app "Key Attestation" if your keys are still visible to android. It will show "Not supported by this device" to indicate your keys are not present and are sadly not restore able with the offered method. If however the app indicates a trusted environment (TEE), just follow from here on, do a backup now, saving your keys.
Then head to the last section "Repair sensors/ folder in persist.img".
This guide assumes you are using linux and have edl.py installed.
I will not be able to test this on windows. Someone else might translate the tasks to windows applications like QFIL for the flashing. The official QFIL full reflash guide does not contain this backup method yet.
@EskeRahnshows how to Backup using ADB in a comment below. Note tht this only works after rooting the device following this guide.
Details of the EDL installation and the 2.1.2 EDL image links are to be found in this "How to flash to stock" post.
You can anytime use the EDL full flash method to switch back to stock android from any soft-bricked state.
It will retain your keys since it does not flash the persist partition when it contains keys.
A full flash will however not solve the android sensor problems.
Backup of partitions
Be sure to not work in the folder you extracted the stock images too. To avoid mixing them up with your backups.
We are interested in all partitions that have potential to need a restore later, so lets grab all of these:
fsg, fsc, modemst1, modemst2 and persist.The EDL commands to dump the partitions into image files are executed as root/sudo as following
edl r persist persist_backup.img edl r modemst2 modemst2_backup.img edl r modemst1 modemst1_backup.img edl r fsc fsc_backup.img edl r fsg fsg_backup.imgRestore a partition
WARNING: This method does not reliably work to restore. Only for educational purpose for now.
To fix the stock android sensor problems, we only need to flash the persist partition back.
If your persist has broken sensor config, obviously skip this step for now and do it after repairing the sensors folder.edl w persist persist_backup.img
Repair sensors/ folder in persist.img
Root the Pro¹-X following this guide.
adb shell into the device and become root via su.adb shell suRestore the SELinux security context for the sensors folder using restorecon.
First using the -n option if you just want to see what restorecon would do, but not alter anything yet.restorecon -nvRF /mnt/vendor/persist/sensors/And apply those changes by omitting the -n option, -v verbosity should generate the same output like when using the -n option.
restorecon -vRF /mnt/vendor/persist/sensors/You are all set for
reboot
You should notice the fixed sensor after reboot by just folding out the keyboard and see it force landscape.-
1
-
12
-
-
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:-
3
-
-
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.-
1
-
-
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.
Pro-1x in Android does not go into landscape mode, ever
in Support
Posted
@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: