ducksoup

Where you using fastboot or edl to flash it?

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 bac

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. 😉

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). Hehe, no worries,

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. 🙂

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.

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.

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.

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.

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.

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?

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!

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 c

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. 😆

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.

Okay! Got Debian Sid up and running in lxc, by fumbling my way through @matf's guide. It works! 😄

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.

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?

It's actually 32 MB. But it does compress very well, since it's mostly empty space, down to 177 kB with gzip. 🙂

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.

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.

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.

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 alrea