sspiff
-
Content Count
37 -
Joined
-
Last visited
-
Days Won
1
Posts posted by sspiff
-
-
On 1/29/2024 at 11:33 AM, zstas said:
@sspiff I found (by username) these repos [0][1]. The 1st one is mainline kernel, the 2nd one is "ports" repo for postmarketos with scenarios for building images. I suggest using this instruction[2] to combine all this stuff - of course you'd need to replace kernel repo and ports repo with custom ones.
I started looking into these but sadly the kernel seems to be for the Pro1 with Snapdragon 835, not the Pro1-XNevermind, 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.
-
3
-
-
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 work like a charm in both apps.
However, I can't seem to get the camera button to launch any other camera app. I kind of liked having quick access to the camera when I just mashed the button at any point, including when the phone was locked. It was great for getting a quick shot, and it allowed me to capture situations which I'd otherwise miss by fumpling around with the finger print sensor and finding and launching the camera app.
Is there any way to configure the app that gets launched when you press the hardware camera / shutter button?
-
10 hours ago, mosen said:
However, i understand correctly that you did alterations to all of your backups by copying into all of them at some point?
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 🤞
-
1
-
1
-
-
3 hours ago, mosen said:
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.
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.
-
1
-
1
-
-
5 minutes ago, mosen said:
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.I read this shortly after asking here. I'll continue the discussion there.
-
6 hours ago, mosen said:
Ii just now successfully found that way to be working on my side. 🥳🎉
Does this also give you working attestation?
-
31 minutes ago, Ivaylo Hubanov said:
There should be an explanation behind all this... I don't believe it happens on random.
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?
-
12 hours ago, Ivaylo Hubanov said:
Tried only reset without reboot... And now it's stuck on F(x)tec logo...
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).
-
1
-
-
32 minutes ago, ducksoup said:
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).
This is the same thing I observed with my device.
-
2 hours ago, 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?
That does seem to be the case here 😞
-
2 hours ago, ducksoup said:
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.
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.
-
1 minute ago, mattock said:
I guess my backup persist partition has become useless somehow. I'll investigate by mounting it on loopback when I have time.
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.
-
1
-
-
3 minutes ago, mattock said:
Unfortunately my prawn is not allowing flash to the persist partition.
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)
2 hours ago, mattock said:Is this an error which will make the overall edl process invalid? edl does not stop at these errors but continues with the flashing for about 30 minutes.
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.
-
1
-
1
-
-
29 minutes ago, claude0001 said:
You are obviously very skilled with Linux and embedded systems. Sorry for spamming you with technical details on chroots and LXCs that must be completely clear to you. 😄
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.
31 minutes ago, claude0001 said:This. I came to the Pro1 from an N900. Loved everything about it, but in 2020, we were still camping on 2.6.28 as some driver modules had never been open-sourced by Nokia ...
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.
33 minutes ago, claude0001 said:Unfortunately, the mobile phone world being what it is, this often means that the hardware reaches obsolescence before it is supported in a way to be practically useful.
I hear you - but I don't need it to be really fast or anything (though native, accelerated graphics is something I do desire, ruling out solutions like VNC / qemu / ...) Since these phones have 6-8GB of memory, they will be good enough for a lot of basic things even in 5 or 10 years time, provided we can still get batteries for them at that point. CPU speeds will have changed significantly, but I'm not planning on using the phone for doing very compute intensive tasks, and I don't mind waiting on the CPU to catch up (as long as the device UI remains responsive in the mean time).
-
2
-
2
-
-
19 hours ago, VaZso said:
It is a good idea but I would not think it is an easy job hunting for a used Pro1.
There is one that's been for sale forever locally. They were willing to sell for cheap. Maybe I'll try lowballing them...
-
10 hours ago, claude0001 said:
If you want to run mainline Linux out of principle, I totally respect that. 👍
But, on the practical side: what do you think you would miss if you ran your favourite GNU distro in a container of Android, Sailfish or UBTouch, as proposed by @matf-kabouik or @Rob. S.?
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 your kernel.
I've also been an embedded Linux developer in a past life, and I remember the pain of having hardware, compilers and kernels frozen in time forever (remember how long some platforms and distros stuck with Linux 2.6.32?)
So certainly, as a toy for today, containers on Android or whatever works fine. But I would like to have a good experience in 5 years time as well. Because let's be honest, for all the flaws with the QA and timeline of the Pro1-X, new handheld devices that appeal to hackers etc like these don't come along every 18 months.
-
7
-
-
16 hours ago, brunoais said:
To make it clear, the drivers and whatnot of PRO¹-x are still not in mainline linux
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.
-
1
-
-
17 minutes ago, mosen said:
No, as long as they remain in the data/ folder within the persist partition they are supposed to work.
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 testing anymore now that I have no way of getting working attestation back. Sorry guys.
-
1
-
-
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 check if attestation remains broken.
Question: is it possible for my tests to have caused my keys to be revoked by whatever authority hands these out?
-
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.
-
1
-
-
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 the partition, or maybe in blocks marked as bad blocks so they can`t accidentally be overwritten.
-
1
-
1
-
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, but for now it's late and I'm calling it for tonight.
Pro1-X with Linux
in General Discussion
Posted
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 🙂