Maintained list of all remaining issues. Call to help.


Yay! I got logged in too (had forgotten if I'd ever even logged in there before, but had an account) - will need to start making myself familiar with the wiki... over the next two months...
 
We can close the uboot issue.
If that is because you are using my uboot and it is making a lot more boot, I still need to get in there and turn memory refresh on. Short term we might be fine but long term it is not ideal.
Hopefully I can get back to tinkering by the end of the year.

But awesome to hear.
 
If that is because you are using my uboot and it is making a lot more boot, I still need to get in there and turn memory refresh on. Short term we might be fine but long term it is not ideal.
Hopefully I can get back to tinkering by the end of the year.

But awesome to hear.

I am using the bootloader from here: https://packages.pyra-handheld.com/images/bookworm/

I did not know that you made the latest one. Nice job,thanks :)

I am totally not the uboot stuff and have plenty of other stuff to handle. So I totally trust you and aTc to handle that subject.
As long as the more and more Pyras become stable, that is all we need :)
Feel free to update and send patches directly to aTc. No need to wait for any confirmation by me or ED :)
would be totally awesome if you could give it an other shot :)
 
I did a real quick check, and what's interesting about the HDMI issue is that it works fine during the beginning of the boot process, and when it fails it seems to kill the entire boot process.

Plugging in HDMI after login lets me still switch to tty1 and see this at the end of journalctl:
20240915_155300.jpg

but it basically kills the whole system for me, and I don't know how to recover from it.
 
I have not tried recently, but last year cryptsetup was not working on Pyra due to a missing kernel module. I documented my findings here, but sadly did not get any help:

I really think a mobile device should support filesystem encryption, ideally full system encryption. Can we add it to the list? With a little help, i can work on that.
 
I have not tried recently, but last year cryptsetup was not working on Pyra due to a missing kernel module. I documented my findings here, but sadly did not get any help:

I really think a mobile device should support filesystem encryption, ideally full system encryption. Can we add it to the list? With a little help, i can work on that.
Done :)

Did you test this on Debian 10 or 12?

Are you on Discord/IRC? This is something that @aTc might need to add to the Kernel.
 
Done :)

Did you test this on Debian 10 or 12?

Are you on Discord/IRC? This is something that @aTc might need to add to the Kernel.
The one that came with the Pyra. Idk ;) Can't look it up either, because i just reflashed it. But i will test it again in the next days if it still persists.
I think i have an Discord-Account lying around somewhere (vague memories of having been in the pyra channel before). I'll come around when i have time.
 
The one that came with the Pyra. Idk ;) Can't look it up either, because i just reflashed it. But i will test it again in the next days if it still persists.
I think i have an Discord-Account lying around somewhere (vague memories of having been in the pyra channel before). I'll come around when i have time.
Test it on Debian 12. We are transitioning to that one :)
 
Good news everyone! Don't know why it did not work before, but I successfully ran a little test today:
Bash:
dd if=/dev/zero of=block.img bs=1M count=50
echo -n "badpassword" | cryptsetup luksFormat block.img
echo -n "badpassword" | cryptsetup open block.img cryptoblock
mkfs.ext4 /dev/mapper/cryptoblock
mkdir block_mount
mount /dev/mapper/cryptoblock block_mount/
echo "Treasures" > block_mount/chest
umount block_mount
cryptsetup close /dev/mapper/cryptoblock
cryptsetup luksDump block.img
rm -r block_mount/*
echo -n "badpassword" | cryptsetup open block.img cryptoblock
mount /dev/mapper/cryptoblock block_mount/
cat block_mount/chest
umount block_mount
cryptsetup close /dev/mapper/cryptoblock
rm -r block_mount
rm block.img
(If anyone wants to try out as well: Install cryptsetup beforehand. Run as root. This creates a 50MB file "block.img" in the current directory, encrypts it, puts an ext4 filesystem on it, mounts it to a folder called "block_mount", writes a file onto it, umounts, closes & reopens it, prints the content of the created file and then cleans up everything. In the middle it dumps info about the encryption used, which should state "Version: 2" at the beginning)

I will try to encrypt an sd card next and after that experiment with encrypting root and booting from that.

--
Edit: Looking at this it seems that the (newer) cryptsetup in bookworm propably just defaults to another hashing function (aes-xts-plain64) which is not disabled: https://gitlab.com/cryptsetup/cryptsetup/-/issues/499
Running cryptsetup benchmark fails with missing kernel module "algif_skcipher".
But at least it appears to be usable.
 
Last edited:
I got a bit lost with along the thread. So summarizing which of the listed fixes are already in the bookworm image?

Keyboard and exfat are the key items for me.

Is the image ready for daily use? What about the test3 image?

I'm talking abou this repo by the way:
 
I got a bit lost with along the thread. So summarizing which of the listed fixes are already in the bookworm image?

Keyboard and exfat are the key items for me.

Is the image ready for daily use? What about the test3 image?

I'm talking abou this repo by the way:

The test image has the fixes you want.
It has some private links to aTc's repos but you can use it.
aTc did not push the updates to the main package yet.
there is no harm in using the test image I guess.
 
Back
Top