On Sat, Feb 12, 2022 at 11:19 PM Be <be.0@xxxxxxx> wrote: > > > On 2/12/22 17:08, Peter Robinson wrote: > > reencrypt > > > > On Sat, Feb 12, 2022 at 10:55 PM Be <be.0@xxxxxxx> wrote: > >> > >> 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: > > Really? I don't see where you addressed and I replied to the first > > message in the thread. > > I just quoted it so I don't know how you missed it, so here it is again: > > > 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. > > Unless you mean something else by "USB recovery". Yes, I do, the rockchip recovery doesn't expose mass storage, that must be a tow-boot thing, hence why I discounted that. The rockchip recovery isn't dependent on software. > >>> 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 the https://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 the https://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/35916/15 > >> > >> 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? > > arm-image-installer doesn't work on a running image so it's unrelated > > to this. When the feature is available the documentation and details > > will be available but the underlying functionality is part of > > cryptsetup and detailed in the man page, search for reencrypt, the > > basics is that the generic image would be setup for encryption with a > > null cypher, on first boot you can specify a new pin and it will > > encrypt the storage with the provided PIN/passphrase and if there's a > > TPM2 available also make use of it's functionality. > > Oh that's really cool. If I understand correctly, that preserves the > simplicity of dd'ing an image while still allowing encryption. Correct, from an IoT/Edge perspective it allows a guaranteed way of provisioning things with repeatable provisioning of images when used in conjunction with other provisioning/on-boarding technologies. > What will be the UI for that? It will need an on screen keyboard to be > usable for mobile devices. Maybe an OSK for Plymouth could be reused? Out of scope for the work we're doing for IoT/Edge, the OSK is specific for Mobility so it's something the mobility project will need to deal with as IoT doesn't have that requirement so it's not something we've got the resources to deal with. _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
