On 2/12/22 13:25, Peter Robinson wrote:
Hi,
> I've been using Fedora on my Pinephone for like 9 months or so and my Pinephone
Pro Explorer Edition just arrived the other day. The original Pinephone's boot order
had the microSD card before the eMMC which made it really easy to try different OSes. By
contrast, on the Pinephone Pro, the boot order in hardware is:
>
> 1. SPI flash
> 2. eMMC
> 3. microSD
Does the PPP have SPI flash? I've not seen any documentation that says
it does and of late Pine64 has sadly been dropping it on devices, I
would love to be proved wrong on that.
Yes it does. I have Tow Boot on my Pinephone Pro's SPI flash and it works.
Also You miss 0) USB recovery,
I addressed this at the start of the thread:
Simply pressing the volume up button on boot will expose the eMMC
drive as a USB mass storage device, refer to
https://github.com/Tow-Boot/Tow-Boot/pull/67 for details about the UX
design.
The points you make here are completely orthogonal to tow-boot or
upstream U-Boot, we make generic images for all our deliverables and
while there's separate scripts at the moment there will not be once
the Mobility initiative is fully upstreamed into Fedora.
Well yes, that's the reason I started this discussion. Let's use the
same tooling Fedora is using upstream to build Pinephone Pro images, so
when the kernel patches are upstreamed it can Just Work with Fedora.
Fedora doesn't use livemedia-creator for it's arm images currently so
Neal (AKA Conan Kudo) is wrong. It currently uses image-factory and
will be migrating to ImageBuilder before the Mobility images become
official so yes, you've misunderstood due to the incorrect information
provided to you.
Thanks for correcting that. I'm unclear what ImageBuilder is capable of
currently. This Fedora Magazine article says it can make raw images:
https://fedoramagazine.org/introduction-to-image-builder/
but I don't see that option on my machine:
$ sudo composer-cli compose types
ami
fedora-iot-commit
openstack
qcow2
vhd
vmdk
using osbuild-composer 43-1.fc35
> Thanks to the efforts getting Fedora on the original Pinephone, good progress has
been made getting Plasma Mobile and Phosh packaged in upstream Fedora. There are still a
handful of packages in
thehttps://copr.fedorainfracloud.org/coprs/njha/mobile/ COPR
repository that aren't upstream. I think enough has been upstreamed at this point that
we can start working on base Plasma Mobile and Phosh Kickstart files to use with
livemedia-creator that could eventually make it upstream. For now, we'll still need
device-specific Kickstarts for the downstream kernel packages which could %include the
base Plasma Mobile or Phosh Kickstart. Fortunately for the Pinephone Pro, distros are
coordinating to avoid the fragmentation that has happened with kernels for the original
Pinephone and development effort is being coordinated on
thehttps://gitlab.com/pine64-org/linux/-/tree/pine64-kernel-ppp-5.16.y/ repository.
This point is irrelevant in the context of specific device support and
there's already work afoot here anyway. We won't be producing PPP
specific images, we will be producing a single image for each Mobility
UX, or possibly one with all of them. There's no need for device
specific images and Fedora has never gone that route.
You misunderstood. I am not
suggesting Fedora make PPP specific images.
I am suggesting that we make PPP specific images using the same tooling
Fedora does, so when all the required packages and kernel patches are
upstreamed, generic Fedora images will work on the PPP.
> One important feature that we haven't gotten working on the Pinephone is full
disk encryption. One issue blocking this is that Plymouth (the software in the initrd that
asks for the LUKS password) does not have an on screen
keyboard:https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/144 Also, the Anaconda
GUI wasn't designed for small touchscreen devices without a keyboard. Fortunately this
could change with the recently announced rewrite of the Anaconda
GUI:https://discussion.fedoraproject.org/t/anaconda-is-getting-a-new-suit...
Someone will have to do the work to add a plymouth OSK of some sort,
with the work my team is doing for Edge/IoT the encryption problem is
solved when we move to ImageBuilder, we expect the first pieces of
that to land for Fedora IoT in F-37 and I'll be working to move all
Fedora deliverables over to that so Mobility will be able to just
consume that work,
Neat! Could you elaborate on how this will work? Will
arm-image-installer ask for an password to encrypt the root filesystem?