sspiff

I've been searching for the firmware blobs for the Pro1X elsewhere but haven't found any. I hope @Danct12 returns us with more info on how he built his image 🙂

I started looking into these but sadly the kernel seems to be for the Pro1 with Snapdragon 835, not the Pro1-X Nevermind, the kernel is for the Pro1-X, but the pmaports branch is for Pro1.

Is there a repo we can build an image for the Pro1X for? I use mine mostly as a pocket computer with Termux, but working Linux distro would be awesome! I tried droidian for a while but without GPU acceleration and power management it was not the greatest experience.

was running mine as a pocket linux PC with Droidian until my daily android phone developed issues. Currently using the Pro1X with stock android as a phone, using termux for doing some light coding (Helix/Rust/Go/Git are all I need), and occasional SSHing.

Hi all. After running Droidian on my Pro1-X for a while and using it as a pocket Linux PC, I've decided to give it a shot as a daily with the stock Android. One of the biggest limitations so far, has been the Snapdragon camera app. It's just... not good. I've been trying both Open Camera and Camera FV-5, and they both considerably improve the camera experience. When pushing the camera button, the phone launches the Snapdragon Camera app, even when in another camera app already. This was easy enough to fix, simply disabling the SD camera app entirely makes the hardware camera button w

No, I always made a copy and modified that copy. One of the originals was only ever copied, while the other was mounted read only at some point to copy from the backup into the stock image in an attempt to put the keys on the stock image. Regardless, I will try restorecon and see what happens 🤞

This is my situation, I have two backups of my persist partition, from when the phone had broken sensors but working attestation keys. They contain a data folder (with files similar to yours) and have only been copied (so I could modify the copy) or mounted read-only (to copy files from). restoring any of my persist backups with the data folder does not restore the attestation. I'm not at my PC until tomorrow night, but I will try out the restorecon method on the data folder when I get back.

I read this shortly after asking here. I'll continue the discussion there.

Does this also give you working attestation?

I'm sure there is, but I've only seen it once so it's hard to figure out a pattern from that. I believe it was "unique" for my personal flashing attempts in that it was one of the only times I rebooted into EDL mode through adb rather than using the volume keys at startup method. So basically a reboot and not a cold boot. But most people use `adb reboot edl` all the time without issue so I doubt that's the reason?

I've had this happen once as well. Boot back into EDL mode (turn of the phone, then hold both volume keys and turn on the phone, it should show a logo very briefly, then go to a black screen) and run the flashing procedure again. This resolved my issue. It might take a few times to get into EDL mode correctly (I've had it boot into EDL but only memory dump mode and no firehose a couple of times first).

This is the same thing I observed with my device.

That does seem to be the case here 😞

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.

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.

The persist partition is locked in fastboot mode. Rebooting into EDL mode and flashing it with the EDL python scripts does work (at least on Mac and Linux) I see some of these errors while flashing as well, does not seem to affect the process at all - I've checked a couple of those partitions and I can read them back and the checksums match those of the images I've flashed. I've restored to stock a couple of times over the past week and I've had these error messages from the start.

I'm not very skilled, just been around long enough 🙂 No harm in trying to explain things, I don't mind or take offense to things like that pretending to be above learning things. There is no way for you to know what I understand or know or not, and you're trying to help. I still have my Nokia N810 and there is no modern kernel that supports its LCD or graphics chip, unfortunately. I used to have a ton of Sharp Zaurus (these used to be the gold standard) and a couple of HP Jornada & NEC MobilePro handheld PCs where we used Windows CE as a sort of bootloader for Linux/BSD.

There is one that's been for sale forever locally. They were willing to sell for cheap. Maybe I'll try lowballing them...

I 100% agree that running inside a chroot or LXC container is 98% of what people would need. But one thing I would gain from using a mainline kernel, is kernel updates almost in perpetuity, rather than running a container on a fork of a 4 year old kernel. Additionally, it provides a path forward in de-blobbing many of the drivers and features inside our phones, which is a security improvement. I understand that right now this is mostly philosophical and problems for future sspiff, but I've been into handheld Linux devices for long enough to have felt the pain of not being able to upgrade

What is the status for the original Pro1 and mainline Linux? Are there guides for setting up a classic Linux (any distribution, I don't care) on the old devices? I received my Pro1-X last week but would kill for a real pocket Linux experience on a keyboard phone (rather than containers on Ubuntu Touch or Sailfish, or Termux or whatever on Android), and I might buy a used Pro1 if I know it can run something like Debian or Ubuntu or Arch.

Welp. I just went through the whole reflash stock procedure and restored my oldest persist backup, and attestation no longer works. It worked yesterday, which was AFTER I backed up that persist partition. Guess I'm sh*t out of luck now... I'm not sure when the unmodified backups stopped working, I'm 90% sure I got back working attestation after flashing the backup over the stock image at least once. But I think it does invalidate my findings above, perhaps one of those operations would work. Or perhaps one of them nuked my keys. Hard to know at this point , but I guess I can't do any test

Just tried reflashing my original backup and it's also failing attestation now. Not sure if I messed up somewhere and accidentally modified the file somehow (though I only mounted it read only...) Edit: Just reflashed an older backup and it still fails attestation. Not sure what broke attestation but it seems to be outside of the persist partition? The older backup definitely predates me breaking attestation and is certainly not accidentally modified (since I keep it on removable storage and only work with copies of that file). I will reflash the stock ROM + my persist backup to chec

Prior to getting your ddrescue and restorecon tips, I tried taking the backed up image, delete all files, and then copy over the data from the stock persist image (hoping it would retain any hidden data but copy the stock sensor data). This produced a non booting system. I'll try out restorecon and ddrescue when I get back to my PC.

I tried a couple of things: Copying each individual directory from the backup into the stock persist partition using `cp -a` Copying all of the directories apart from the `sensors` directory into the stock persist partition All of these gave me a working phone, with rotate and keyboard backlight, but no device attestation. `cp -a` is meant for archival backups and copies all standard properties and permissions to the destination I'm beginning to think these device keys are either embedded in ext4 metadata not supported by standard tools, or hidden in unused data on th

Thanks for all your research @mosen! Unfortunately, I tried this and now my device is no longer booting into Android at all now. I haven't been able to get into recovery or fastboot mode since, only EDL mode. When I try running EDL, it says the device is in memory dump mode and starts dumping memory from the phone. I am able to get back into the EDL flashing mode some of the time. Behavior when booting is first showing the Powered by Android logo, then black screen. Sometimes the logo is there for quite a while. I have an unaltered copy of my persist partition on my work PC