mosen
-
Content Count
90 -
Joined
-
Last visited
-
Days Won
7
Posts posted by mosen
-
-
@CraigActually, i never bothered to check without root rights. Agreed, the official EDL.py instructions on Bkerlers git do not mention sudo or root. I only now see.
But the EDL instructions i followed (the ones you qouted) showed them executed by root, with leading #. So i just did that as of yet while not feeling adventurous and trying differently.
Did you try? Does it work? -
@maridavAre your sure to not mix up Pro¹ and Pro¹-X intructions and even images?
Those are two completely different devices due to different SoC and the Firmware is not interchangeable.
For the Pro¹, the unlock command is `fastboot oem unlock` for example.
Also, there is no LineageOS for Pro¹-X yet. so i figure you tried to flash the Pro¹ LOS files?
LineageOS for Pro¹-X has just now been booted up first time by a dev as reported on Telegram.
-
1
-
2
-
-
@EskeRahn @eorg
The recovery is the dead droid. To activate its menu, press the power button and the volume up button. Still, the limitation is that ADB is not fully available in recovery. We can only sideload patches. In the beta group its used to manual sideload local updates from "OTA" packages that are contained in the releases.
We even got an alternate fastbootd that can write logical partitions. You can reach that by either `fastboot reboot fastboot` or from the recovery menu item fastboot.
@eorg Don't let yourself confuse too much from the evolving threads here. Most things have been corrected over time and its easy to get sidetracked by now obsolete posts.
Summary is:
- As long as you remain in android world, your persist and thus attestation keys are always fine. Root/unroot, re/lock bootloader, full flash using the official scripts or instructions as often as you wish.
- Only when you boot SailfishOS or Ubuntu touch, they write into the sensors folder while not being in SE Linux context. Which breaks it for android. The fix for that, when flashing back to android is documented here and reliably working.
- The only thing that one can do wrong, is manually flash a stock or sadly even backuped persist. flashing persist is also completely unnecessary now, since "broken" persists can be repaired on device. Restore persist backups was only tried for completeness to know if restore works. It does NOT reliably. And some users lost their attestation keys unnecessarily during the time while it was not know. The reason is yet unknown.
- It is still generally advised to make a backup of your device specific partitions. For the case some bright person figures out how to restore them in the future.
EDL.py has just the same protocol (QFIL/Firehose) implemented as the official Qualcomm QPST flash tool uses. If you, unlike me, can handle GUIs in windows, you might be able to figure out how to backup using QPST. Its what F(x)tec uses in their official flashing instructions. And it should absolutely be able to read/dump partitions to a local image file.
But when you have the device rooted using the official guide, Eskes ADB backup method posted at the beginning of this thread will also work.-
2
-
-
@zaptastici used that second one you linked. But since the method is called Key Attestation, i guess all of those tester apps should do quite the same.
You can observe using those, that key attestation is a feature that does not depend on Safetynet/Play Api integrity. But the other way around.
Using this Play API integrity checker, you can observe that unlocking the bootloader breaks "Device integrity". Rooting the device breaks "Basic integrity" and missing keys break "Strong integrity".
But the pure Key Attestation checker apps you linked above, are happy as soon as they see keys. Not minding root state or unlocked BL.
Most banking apps are working when basic and device integrity are met. Strong trusted environment key attestation is not much used by any apps currently.-
1
-
-
Updated the first post with warnings regarding the restore of backups.
Sadly, i could not identify a pattern in which case restoring a backup works reliably. Even after days of trying and countless reflashes/lock/unlock BL...
I managed to put a device in the perilous state where a restored backup with contained keys does not make those usable in Android. And was not able to recover from that state by any means.
I documented the way i reached that. But the unsettling thing is, i did nothing different than during the successful restores.
Until someone else with deeper knowledge solves the restore issue, the only, but 100% working way to repair a persist partition that has broken sensors is the restorecon fix.
Just do not attempt to restore the persist, but repair the existing persist on device using restorcon. And you are fine.
For those that are in the same "No keys visible in Andy but physically existing in persist" boat.
Testers have exercised the reprovison of a device successfully. Devices with lost keys can receive new ones. But that involves a send in to F(x) service for now.-
4
-
-
-
@fxnoma Like Kabouik mentioned, Android sync apps will not work since the SailfishOS android layers do not support to relay bluetooth to the system.
On the native sync client side we have Adams Amazfish, originally written to support Amazfit products. But adam maded it nicely modular and now the PineTime and bangle.js are supported as well.
https://github.com/piggz/harbour-amazfish
Then there is rockpool, providing support for all pebbles. I used that on the Pro¹ for some time.
You might have heard of AsteroidOS, a full linux replacement to WearOS on 19 supported watches. The pitty, tho being extremely similar to SailfishOS, a sync client has not been succesfully developed. Its ongoing since 3 years now but Jolla put some sticks between devs legs. At some point AOS watches might just be supported by Adams Amazfish before a dedicated ASO sfos client is ready.
Anyway, no hope for all those WearOS watches that rely on the WearOS sync app.
-
2
-
-
@marmistrzAdmitted, i am not after the google free experience on this device.
I have my privacy sensitive things on the Pro¹-X with SailfishOS. But since the gps reception is miserable on sfos, i thought i'd prepare the Pro¹ as a secondary Navigation and Messenger machine.
Thanks for the discussion!-
1
-
-
Now activated the google location service that was offered in settings -> location -> location services. And deleted the AGPS cache using gpstest from F-Droid. Lets see what that does.
-
1
-
-
1 minute ago, marmistrz said:
For me the "next fix" usually works. But sometimes it doesn't and getting a fix takes tens of minutes. This is why I carry my old OnePlus 3 whenever GPS is crucial... 😞
It's been that way ever since, I guess it's yet another bug that will never get resolved.
Ah, ok, that sounds VERY familiar to the situation on SailfishOS.
The problem on SailfishOS lies in the AGPS support. Mozilla at some point 3 years ago changed the license model for its MLS. Which ment that SailfishOS users lost celltower based location assitance via Mozilla Location Services.
A work around attempt on SialfishOS that never really worked was to manually feed the offline availabe MLS files.
But since we are on Android, maybe there is a way to enable the google location service or whatever makes stock android get gps fix instantly?-
1
-
-
1 hour ago, Kaali said:
Answering here too, Magisk has a good guide that if you follow you shouldn't really have any problems with the rooting.
https://topjohnwu.github.io/Magisk/install.htmlREMEMBER ALWAYS DOWNLOAD MAGISK ONLY FROM THE OFFICIAL TOPJOHNWU GITHUB!!!
Magisk has two methods of rooting which the easier one is to just rename the magisk apk to .zip and sideload update it like you do with gapps, idk why the maintainer does not recommend this method. It also has the perk of persisting through OTA's so you don't have to install it again every week after lineage updates.
The boot image patching method means you need the lineage recovery file patched with magisk following their instructions. Note here with this method you need to patch the new boot image after every OTA because LOS updates the recovery always and you can't turn it off for pro1.
With the read only device error you need to remount it when rooted soadb root adb remount adb push gps.conf /vendor/etc/ adb enable-verity
Should do the trick even without magisk root.Thank you @Kaali, much appreciated! I now successfully applied the "sideload magisk.apk renamed as zip" method.
I was put off by following the Pro¹-X stock rooting procedure.-
1
-
-
@marmistrzI don't think it is necessary even. I was just not expecting that the first fix would take 30 minutes.
I tried multiple times around 15 and 20 minutes, then starting to look for a possible solution -> gps.conf.
But as soon i got a "first time ever fix" after like 30 minutes and then rebooted, after reboot i had instant fix.
This behavior now persists, i get a fix within 30 seconds constantly and i think the issue is explained and solved.
Thank you!-
1
-
-
Hey all!
Trying LOS 19.1 as my first LOS ever on Pro¹. Install went fine including MindTheGapps-12.1.0-arm64-20220605_112439. Flashed to stock android beforehand to start from a clean state.Two problems i am facing:
1.[SOLVED, after some reboots i suddenly got fix without updating gps.conf]
I read "GPS fix taking a long time" is due to /vendor/etc/gps.conf. I downloaded a gps.conf that is fitting for my region and should speed up sat-fix. But pushing the file using adb root and adb push gps.conf /vendor/etc/ results in "read only device".
I figure adb root is not enough and i need magisk root for that?
2. [SOLVED, the adb sideload method was the way to go, wrongly abbreviated form the Pro¹-X boot.img patch rooting method]
Trying to root via magisk went like following:
Magisk patched the stock boot.img which was flashed before installing LOS. The one contained in ext4_QX1000_user_20200825231445_dd49dd0dd1.7z.
But trying to flash the magisk_patched-25200_ceLFW.img back using fastboot flash boot magisk_patched-25200_ceLFW.img always results in
fastboot: error: boot partition is smaller than boot image on second try, after fb complains about the slot on first try. Also tried to assign boot_b since that is active according to fastboot getvar all.
RE 1. The GPS fix now came on right after a reboot so i figure no need anymore for the gps.conf copy to /vendor/etc/. But 2. is still a mystery to me 😛 -
1 hour ago, toast said:
Also, where can one get a legal copy of windows (like an .iso, I suppose) to run in the mentioned VM setup? What VM software is recommended (I am on Debian Sid)?
As a fellow linux user, i advise to use the edl.py method explained here.
Testers are using this method since month intensly. The windows QFIL instructions are a recent thing to make full reflash possible for windows users. Never tried the QFIL method myself. Always used edl.py as of yet and had no problems.
But mind to make backups before flashing anything.-
3
-
-
@EskeRahnbut do you see that dead droid logo at any point when doing different volume buttons on reboot?
When seeing that, its vol up and pwr to activate the actual recovery menu.
Ok, but since you said you sideloaded OTAs you sure have been in there 😛
Just not fully understanding what you mean.
Since i figure from what you say you can only reach fastboot bootloader menu and flash the OTA via fastboot?
Btw, why are you not in the TG beta channel? 😅 Its ment for both, pre production units and retail units just to test the latest OTAs. -
@Ivaylo Hubanov That is an indicator for the sideload mode not being started in recovery.
There should be an option in the recovery menu that says along the lines "sideload using/via adb".
If you select that, the screen will change to black and only show some white text saying something like push .zip now and showing the command how to do so. (the adb sideload image.file one)
When you start sideloading from your computer using this command, it will show progress on the device screen. -
Wow, you seem to have a very early version then!? On the testing device i had delivered with 2.0.8, the recovery is reached by holding any volume button during the first seconds of boot.
I can not reliably reach fastboot with the volume method, neither on the retail Pro¹-X, not on the testing device.
But i always end up at the dead droid recovery start page. To activate the menu of recovery, one has to then press power button and volume up. The menu appears over the dead droid and there we have the option to boot to bootloader and the adb sideload among others.
-
@Ivaylo HubanovAnother idea. Since your device boots into the F(x) logo and gets stuck there, it is in a state already where OTA changes can influence the boot process.
Can you try sideloading an OTA update via adb in the recovery mode?
Download a beta OTA from here (not GMS certified) Please note the beta disclaimer.
Set device into recovery mode by holding vol down button on reboot.
At the dead droid, push pwr btn and vol buttons to activate the menu.
Choose sideload via adb.
Push the downloaded .zip file using:adb sideload merged-qssi_bengal-ota.zipAnd reboot.
-
1
-
-
Thanks already for the confirmation that you found your keys. That's cool and you can pat yourself on the shoulder for not deleting them by chance 😄
However, i understand correctly that you did alterations to all of your backups by copying into all of them at some point?
Then it would make much sense that restorecon can also fix all other folders.
When you have your device rooted and moved to /mnt/vendor/. Just try therestorecon -nvRF persiston the whole persist. The verbose output will show every file restorecon can relabel and thus put back to context.
The -n option is to not do changes. If you like what the command offers, remove the -n and execute it with -vRF-
2
-
-
5 minutes ago, steeb said:
@mosen Oddly, this did fix the sensors, but not attestation. I feel quite certain it was working when I backed up the image, but unfortunately I dont have time to try re-flashing again this afternoon.
Check here for a method to search for the keys in any partition or image:
-
10 minutes ago, sspiff said:
Does this also give you working attestation?
That is 100% a matter of having a (backup?) persit partition with keys contained in the data folder.
User Ducksoup had a question that also involves identifying whether a partition or image of a partition contains keys at all.
To not double post too much, i invite you to read how to check for keys here: -
Ok, i am frankly out of ideas to blind diagnose. And the backlog got so long that i would favour to spend time in starting a fresh attempt. My fear is franceso or casey over at the official support tickets will have a lot of work to disentangle what happened anyway and you will likely have to explain every thing over and over.
At this point, imo we should compile a sort of issue tracker or support request form/matrix where the most important questions are answered. I have not seen an official F(x) one. So i guess we could help them a lot with such.
A good way to achieve a complete list of current necessary questions is by just starting with a batch of obvious ones and then extend post wise. I invite you all to do so. I will update this post and compile the final version into a pdf or plaintext doc to copy here or a like.
Maybe we even find a solution while doing so.
- Testing device or final production unit?
- 8/265 or 6/128 GB model?
- Device was working correctly with stock android on delivery?
- Was a possible hardware fault present/obvious after delivery?
- Which alternate OS was flashed?
- Which method was used to flash initially?
- Which guide/instructions did you follow?
- Was a backup of persist made, and at which point?
- Did you flash the stock persist images (NOT advised)?
- Did you manually flash partitions using edl, QFIL or fastboot? Which ones?
- Did you locally mount and/or edit partition images and flash them back? Which ones? What was edited?
- Was an attempt made to fully flash back to stock android using the official QFIL instructions? Or the inofficial EDL instructions?
- Did you participate in the beta firmware program?
- Which latest build version did you sideload via adb in revovery mode?
....
....
- Does the device show up as "Qualcomm Gobi Modem" when you do `lsusb` while connected to a linux computer?
- Do the flashing procedures finish successfully or do they get blocked by a warning at some point?
- Can you reach the fastboot bootloader menu or recovery by initially holding a volume button on reboot?
(From the dead droid you can go to fastboot by pushing pwr and vol up, then reboot to bootloader from the appearing menu)
....
....
Describe your current state:-
3
-
-
8 hours ago, ducksoup said:
Okay, I've now tried this, with no luck. I QFIL flashed the whole device to stock Android, then used the edl Python script to write out my persist backup, and I've got the same place as I get with fastboot, i.e. broken sensors and no attestation.
Bit of a mystery. Would be good to get more data from others, in case I've somehow just broken the keys in my persist backup and don't know it.
I must admit to not having full understood. Imo your case is isolated due to the instructions having been unclear over the last days. And you where possibly lead into some action i can not really follow.
First of all, it has never happened to me that flashing a persist that actually contained keys, did lead to the Key Attestation demo app to not show/use them.
There is a fix for the sensors folder now (updated in the backup, restore and repair partitions guide). Hopefully this will help everyone with broken sensors only.
To debug your case, lets start all over. I would first of all make sure you still have any keys remaining, after what ever happened.
The keys are visible in a mounted persist partition.
For the one that is currently flashed, look into /mnt/vendor/persist/data after rooting the Pro¹-X using magisk.
For the hopefully many copies of your backup persist you took at any point in time:
Mount the local persist.img. In linux its just `mount persist.img <folder to mount to>`. For windows there are programs that can mount ext4 partition images, like DiskInternals Linux Reader.
When you explore the mounted partition, it looks like so when your keys are fine
If there is only two folders, sensors and a lost+found present, we are looking at a stock persist image without device specific data.
In case you got that data folder filled in any of your backups. But flashing it result in no visible keys for the Key Attestation demo app. I would try to apply the sensor fix method also to this folder, just by chance.-
2
-
1
-
-
5 hours ago, Ivaylo Hubanov said:
Was also wondering if there's a way to recognize if it is memory read mode or firehouse without running the flashing process and check for errors everytime 🤔
Sure! Its just
lsusband the Pro¹-X will show up as qualcomm gobi modem when in edl mode.
Pro¹ X - backup, restore and repair device specific partitions
in How Tos
Posted
Indeed, for edl it might be worth to try a usb 2.0 connection. This can be done by using an old cheap usb 2.0 hub if your computers do not offer any @thilo
`fastboot fetch` is just not available, sadly.
Regarding your backup attempts using adb, its necessary to root android using magisk to be permitted to access those partitions. Its an easy process documented here officially:
https://docs.google.com/document/d/1sBS-Taw-3MXrG4lETA6dfuwda8K-9uVlzLhGk46ctzg/edit
Or in short,
- install magisk from the official source https://github.com/topjohnwu/Magisk
- grab the boot.img fitting to your build number (contained in the same system image package used to fully flash the device)
- patch this boot image using magisk
- Download the patched boot.image using adb
- flash the patched boot.img using fastboot
- Boot into android to see working root in the magisk app
- `adb root` to grant root rights for next command
- grant permission for the adb root in the pop-up or when missed in the magisk apps section for the shell app.
- `adb pull /dev/block/sda2 persist_20221101.img`
- `adb unroot` not really necessary since it does not persist reboot or adb on/off
But as @claude0001correctly noted, there is no know way to restore the persist partition currently.
But it might be worth having it for the point in time when a working way has been found.