ducksoup
-
Content Count
79 -
Joined
-
Last visited
Posts posted by ducksoup
-
-
48 minutes ago, EskeRahn said:
Maybe what Ducksoup did 'damaged' more than what Mosen did?
FWIW, I did not back up persist until after it was "damaged" to break the sensors. However, when I flashed back everything stock except persist, using the edl Python tool and the process described here (I edited the xml to skip persist), I did still pass attestation in Android.
Then, I used fastboot to flash the stock persist.img, thus fixing sensors and breaking attestation. Finally, I used fastboot to flash back my saved persist, and did not regain attestation.
I performed additional tests using QFIL to flash full stock image back, and then fastboot to replace persist with my backup, which again does not regain attestation.
One thing I did notice when testing with QFIL is that if I have broken sensors before a QFIL flash, I also have broken sensors after it, so I suspect QFIL is not messing with a persist partition if it already exists. I have just noticed this once, however, and have not verified.
One thing I have not tried is using edl to flash my persist backup. I can give that a try later today.
-
2
-
-
36 minutes ago, matf-kabouik said:
I can share with you the kernel 1.6.1 from Adam (later versions that can be downloaded from his repo break the keyboard mapping so I don't advise them), but if you're not too much in a hurry, it might be best to just wait until he comes back from holidays and updates it with working mapping improvements.
No hurry here. This is all just for fun at this stage (although eventually, once the dust settles, I do think SFOS as host OS with containers for Linux and Android would be an ideal setup).
I'm pretty busy today anyway, although perhaps later I'll try out some Adam's kernels and at least see if I can get them to boot. Bad keymaps may be the least of my worries. 😉
-
1
-
-
13 hours ago, EskeRahn said:
Just to be sure, did you restore on top of a freshly reflashed stock image (following casey's guide) - before booting it? Or did you do something else?
I have freshly reflashed using QFIL in Windows just be sure, then flashed my persist backup on top, and it does not pass key attestation.
I know this persist "should" be good, because I backed it up a while ago, before successfully testing key attestation. In my earlier testing, after seeing successful key attestation, I flashed stock persist on top in order to fix my sensors (which worked), then flashed my backup persist back on top of that, expecting to lose sensors and regain attestation, and I did not regain attestation (but did lose sensors as anticipated).
11 hours ago, sspiff said:I'm sorry for your loss. But it seems like there is more going on than we currently understand with the attestation keys. Thank you for confirming this.
Hehe, no worries, this device won't be running Android in the long run anyway, so I don't mind taking one for the team as it were. 😉
-
2
-
-
Just now, EskeRahn said:
So does this mean that you have proved that restoring a saved persist image is NOT enough to keep key-attestation, as we thought?
I wouldn't claim to have proven anything, since I don't claim to know much about attestation (this is my first device that even supports it). Just reporting what I did and what I got. 🙂
-
4 hours ago, sspiff said:
Before you do, can you try flashing it back (it will break the sensors again), and try if device attestation still works for you? I backed up my persist partition when device attestation still worked (but rotation etc did not), and reflashing the original backup did not restore attestation. I'm just curious if this is just me having messed up somewhere, or if there is more going on here.
Same situation here. I had broken sensors, but working attestation, but then when I reflashed my persist backup, which ostensibly valid keys, I lost attestation.
-
1
-
1
-
2
-
-
19 hours ago, matf-kabouik said:
Check here: https://github.com/UbuntuTouch-vayu/waydroid_11/releases
Sorry I missed your previous message asking for that when I was away. Would be interesting to see if that works for you with the UT boot.img.
Thanks for the link. I made a little bit of progress following your process, but step 8 fails with 'ERROR: Binder node "binder" for waydroid not found', which I suspect is due to running the Ubuntu kernel.
I am still unable to get my device to boot either Ubuntu Touch or Sailfish with any UT kernel newer than 2807435728, even after I do a complete stock Android reflash, even using the official QFIL tool. So of course I have concerns that it also won't boot with the kernel you've been testing out.
-
I talked to a friend with a lot more experience in these subjects than I, and he suggested using something like a HackRF One to look at the radio transmissions themselves to see what's going on. That's a little out of my pay grade (and I don't own a HackRF One), but perhaps someone else has those skills.
Unfortunately this isn't a local friend, so I can't easily bring him over to have a look himself.
-
1
-
-
After a couple of days of playing around with mostly Ubuntu Touch, but also a little bit of stock Android. I've just flashed Sailfish OS back onto the Pro1-X, and sure enough, immediately my AP is dropping packets on the ethernet side again. Will do further investigation.
-
1
-
2
-
-
7 hours ago, matf said:
See how to get Waydroid to run on SFOS and what doesn't work: https://github.com/sailfish-on-fxtecpro1/droid-config-halium-qx1050/issues/1#issuecomment-1215734546
Great progress, @matf! Is there any way to acquire the Android image linked in that post without using Telegram? I don't have a Telegram account.
-
1
-
-
4 hours ago, ducksoup said:
Is it possible that the official software can properly add the attestation keys into persist, and the python scripts we've all be using do not? Anyone want to try it out?
Okay, I've tried this out, and no, the process outlined by @Casey does not restore key attestation functionality. I don't need key attestation working on my device anyway, but hopefully there's a solution out there that will provide both working sensors and working key attestation.
-
3
-
-
I can confirm that on my device, running Ubuntu Touch and Sailfish has killed the sensors in Android. I didn't make my backup of persist until after booting both UT and SFOS unfortunately.
@Casey has just posted the Windows-based instructions for reflashing the factory image. Is it possible that the official software can properly add the attestation keys into persist, and the python scripts we've all be using do not? Anyone want to try it out?
-
2
-
-
Okay, it looks like this problem actually does not appear after I flash Ubuntu Touch. (I do, however, now have the problem that the screen goes black on UT whenever I close the keyboard, but that's unrelated!)
Not sure at this point why I saw such variability on my AP going back to the day I got the Pro1-X. But it does appear that at least the worst examples of the problem are exclusive to Sailfish. I have updated the topic on this post appropriately, and will continue to investigate!
-
1
-
-
I am in the early stages of tracking something very strange indeed. I've been getting alerts for a few days from my own internal network monitoring (Nagios) that my primary wifi AP is often dropping packets on its ethernet interface. Since I've been busy with other things (not the least of which is the Pro1-X itself), and the packet loss isn't enough to cause problems, I didn't look into the situation carefully until last night.
Once I pulled up my reachability graphs, I realised that the issues seem to have started at exactly the same time I received the Pro1-X:
There are a couple of immediately very unusual things about this correlation. First of all, the Pro1-X was connected to my guest wifi for the first day, which is a physically distinct AP (and showed no problems), and second, the observed packet loss is on the ethernet side of my primary AP, not the wireless side (which is not to say there isn't any loss on the wireless side; I'm not testing this side, and perhaps should be).
But I have tested repeatedly, and found that any time I turn the Pro1-X off, the problem disappears:
(powered down at 15:40)
(booted into EDL mode at 14:15)
Further, I noticed that there were a couple of long periods when the problem seemed to go away, but times that I knew I was using the Pro1-X, on wifi. Further testing has revealed that I'm seeing this problem only when the Pro1-X is either charging or discharging its battery, and not when it is sitting on the charger with a fully charged battery. Also, this is happening only with the OS booted, not when the device is in fastboot or EDL mode (where I imagine the wifi radio is powered off?).
Now, theoretically no matter what the Pro1-X is doing on the wifi end of things, my AP shouldn't be dropping packets on the ethernet end of things, but it's not a particularly good AP, so this has got me wondering if the Pro1-X is doing something with its wifi radio that is upsetting my AP enough that it gets too busy to respond to every ICMP request on the ethernet side. And, for whatever reason, this something seems to be happening only when the battery is charging or discharging, not when it's steady.
At the moment I'm making a backup of my Sailfish setup, and I plan to install Ubuntu Touch and perform some further tests and see if the problem follows. I expect that it will, because I do have packet loss in my reachability history going back to when I first received the device, and I had it running the factory Android build for most of the first day. I do note, however, that it looks like the problem has been worse more recently, so Sailfish may be a factor.
There seems to be nothing unusual on the ethernet layer or higher coming off the Pro1-X, but I do not have the equipment or expertise to investigate this further down into the 802.11 and radio layers. But perhaps someone else does?
I'll add more findings once I get some experimentation done with Ubuntu Touch.
-
1
-
2
-
-
94% battery when I went to bed, 52% when I woke up. And this was with the Debian container frozen. Probably need to work on that. 😆
-
2
-
-
6 minutes ago, brunoais said:
Would it pass Google's attestation? I don't think it would...
I'm not talking about NFC payment apps, just my bank's mobile app and authenticator app. Both of those work fine without attestation, and with enough poking and prodding, even on a rooted device.
-
1
-
-
-
Guess that means I already toasted mine, too, since I didn't do my persist backup until after running Sailfish for a while. 😄
Thanks for documenting the process. I'll make sure to get that persist_backup saved right away.
-
28 minutes ago, mosen said:
When flashing and using SailfishOS or Ubuntu Touch (no info for LineageOS yet), the sensor config in the persist partition get altered.
Is the sensor config altered merely by flashing these alternative firmwares, or is it altered only if one flashes back to Android via the full stock firmware archive?
-
22 minutes ago, EskeRahn said:
As the backup image is said to be only 32K
It's actually 32 MB. But it does compress very well, since it's mostly empty space, down to 177 kB with gzip. 🙂
-
2
-
-
On 8/7/2022 at 5:23 AM, matf said:
Still no luck with Waydroid despite my attempts, but theoretically this should be possible because there are unofficial images for Halium 11
Am I missing something here? I followed the link to the image from your github issue, and it brings up a telegram page showing the zip file, and clicking on that zip seems to do nothing but open up a new tab to the same page. How does one actually download the experimental image?
Unfortunately there doesn't seem to be any other source for it.
-
I'm not arguing against your position that you didn't get what you paid for. You do have a valid complaint, and as someone who wants to see solid non-Android options on the Pro1-X, I do hope the situation gets resolved. I just think that if the hardware is ready, but the alternative software is not, then it's better to get the hardware in the hands of the users, rather than shelve it all and make everybody wait.
-
1
-
-
2 minutes ago, mattock said:
I'm going through the torture of updating windows fastboot drivers, as I discovered the generic google driver is not working with the Pro1X.
Presume I'm looking for a qualcomm usb driver of some sort...
Ah okay, can't help you much there. I'm only using macOS and Linux here, and both have worked without needing drivers.
Perhaps you should start a new thread if you don't solve your problem quickly, since this isn't on topic to Spargeltim's non-booting device.
-
2 minutes ago, mattock said:
ADB works when booted into android, and when in the recovery mode.
Either direct from power on, or using 'adb reboot bootloader', I get no fastboot connection.
Although not with this device, I have seen this exact thing happen when a device for some reason didn't like my USB3/TB4 port in fastboot mode. (Yet it was fine in adb, go figure.)
I resolved the problem by plugging the device in question into one of my keyboard USB ports, which are plain old USB 2.0.
That being said, the Pro1-X has no trouble with my USB3/TB4 ports, so this may be a red herring.
-
1
-
-
13 hours ago, mosen said:
If you got EDL set up, its
edl r persist persist_backup.img
Okay, I've successfully backed up my persist partition using the linked tool. The edl tool produced a number of error-looking things on its output, but they seem to be non-fatal, and I eventually got...
Reading from physical partition 0, sector 8, sectors 8192 Progress: |██████████████████████████████████████████████████| 100.0% Read (Sector 0x2000 of 0x2000, ) 33.83 MB/s Dumped sector 8 with sector count 8192 as persist_backup.img....which produced a 32 MB file containing an ext4 filesystem, the contents of which do appear to be the correct things.
A tip for anyone who has already removed Android from their device and thus can't use adb to boot into edl mode (gotta make this relevant to this thread!): Disconnect USB and power the phone completely off. Hold down both volume up and volume down, and then while still holding volume up and down, plug in USB. Keep holding volume up/down until you see a quick flash of the boot splash, followed by a black screen. Finally release the volume rocker. Your device should be in edl mode, although the screen will remain black.
-
2
-
2
-
Pro1X - Stock Android OS (Build Number: v2.1.2_20220707)
in Support
Posted
Where you using fastboot or edl to flash it?