Hello, 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
From the factory, there is a u-boot image on the eMMC drive which will boot an OS from the SD card before the eMMC and there is nothing on the SPI flash. This is problematic because it's really easy to accidentally get the device into an unbootable state when installing an OS to the eMMC drive if the factory uboot build is erased. There is a way to temporarily disable the eMMC drive in hardware to make it boot from SD, but that's not obvious or convenient. So, currently, the Pine wiki (https://wiki.pine64.org/wiki/PinePhone_Pro) advises against replacing the stock Manjaro OS on the eMMC drive and few distros are providing prebuilt images.
People working on different distros have been coordinating how to deal with this. The plan is to use a fairly new project, Tow Boot, and flash it to the SPI flash: https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html Putting the platform firmware on the SPI flash chip separate from the eMMC drive will make the process of installing OSes easier and more foolproof. Support for the Pinephone Pro in Tow Boot is almost ready with support for the Pinephone Pro's SPI flash just added today, albeit it needs a little polishing. Tow Boot on the SPI flash will make the process of installing an OS similar to x86; distros just need to create a UEFI bootable system and do not need to worry about shipping platform firmware. Tow Boot also obviates the need for JumpDrive. 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. Hopefully future Pinephon e Pro batches will ship with Tow Boot on the SPI flash from the factory, but for now users will need to install it by booting a Linux system from an SD card. A Tow Boot installer image like that has already been made for the Pinebook Pro, so I think one for the Pinephone Pro will be ready to test soon.
This is great new for Fedora because I think it means we can use the normal Fedora tools for building ARM images to create UEFI bootable images without needing the scripts in https://github.com/nikhiljha/pp-fedora-sdsetup that were made for the Pinephone. Using Fedora tooling to build the Pinephone Pro images opens up the path to smartphone support in upstream Fedora. I've been digging around in scattered documentation and talking to Conan Kudo on Matrix and IIUC, the way the upstream images are built is that Punji calls `koji image-build` which calls livemedia-creator. Please correct me if I've misunderstood this. I've tried to figure out how to build aarch64 images locally on my x86-64 laptop and made a bit of progress using Mock with livemedia-creator as documented at https://weldr.io/lorax/livemedia-creator.html#using-mock-and-no-virt-to-crea...
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.
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/...
Does this seem like a reasonable plan? Is there anything I've overlooked?
On Mon, Jan 31, 2022 at 05:49:14AM -0000, Be wrote:
Hello, 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:
- SPI flash
- eMMC
- microSD
From the factory, there is a u-boot image on the eMMC drive which will boot an OS from the SD card before the eMMC and there is nothing on the SPI flash. This is problematic because it's really easy to accidentally get the device into an unbootable state when installing an OS to the eMMC drive if the factory uboot build is erased. There is a way to temporarily disable the eMMC drive in hardware to make it boot from SD, but that's not obvious or convenient. So, currently, the Pine wiki (https://wiki.pine64.org/wiki/PinePhone_Pro) advises against replacing the stock Manjaro OS on the eMMC drive and few distros are providing prebuilt images.
People working on different distros have been coordinating how to deal with this. The plan is to use a fairly new project, Tow Boot, and flash it to the SPI flash: https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html Putting the platform firmware on the SPI flash chip separate from the eMMC drive will make the process of installing OSes easier and more foolproof. Support for the Pinephone Pro in Tow Boot is almost ready with support for the Pinephone Pro's SPI flash just added today, albeit it needs a little polishing. Tow Boot on the SPI flash will make the process of installing an OS similar to x86; distros just need to create a UEFI bootable system and do not need to worry about shipping platform firmware. Tow Boot also obviates the need for JumpDrive. 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. Hopefully future Pinephon e Pro batches will ship with Tow Boot on the SPI flash from the factory, but for now users will need to install it by booting a Linux system from an SD card. A Tow Boot installer image like that has already been made for the Pinebook Pro, so I think one for the Pinephone Pro will be ready to test soon.
So, sadly, I still don't quite understand the boot process on arm devices, but why is tow-boot suggested here instead of just using uboot?
ie, whats the advantage of tow-boot here?
This is great new for Fedora because I think it means we can use the normal Fedora tools for building ARM images to create UEFI bootable images without needing the scripts in https://github.com/nikhiljha/pp-fedora-sdsetup that were made for the Pinephone. Using Fedora tooling to build the Pinephone Pro images opens up the path to smartphone support in upstream Fedora. I've been digging around in scattered documentation and talking to Conan Kudo on Matrix and IIUC, the way the upstream images are built is that Punji calls `koji image-build` which calls livemedia-creator. Please correct me if I've misunderstood this. I've tried to figure out how to build aarch64 images locally on my x86-64 laptop and made a bit of progress using Mock with livemedia-creator as documented at https://weldr.io/lorax/livemedia-creator.html#using-mock-and-no-virt-to-crea...
arm images are made via imagefactory/oz, depending on what image you are talking about here? There is also work to move imagefactory/oz built images over to ImageBuilder (a image as a service type thing run by Red Hat).
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.
Right. I would think next think we want is to upstream uboot support, then get kernel support in. I have no idea if Fedora kernel maintainers would be willing to carry some/any/all of the patches there, but I think that has a much better chance than the pinephone kernel patches had. ;)
Packages are good to get going, but without kernel support we will be doing them as part of a remix like we are now. ;(
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/...
Yeah, this is kind of hard as we don't typically do full normal installs on arm devices. We do need some way to do the disk encryption however.
Does this seem like a reasonable plan? Is there anything I've overlooked?
I think it sounds fine to me (except I don't get the towboot advantage), but I think it's going to be a lot of work, so don't expect something tomorrow. ;)
kevin
Whether Tow Boot or uboot is on the SPI flash isn't really relevant to distros. The point is that distros shouldn't have to worry about shipping uboot, just like Fedora doesn't ship UEFI firmware for x86-64. Tow Boot has some UX advantages for mobile devices that may or may not be wanted in upstream uboot. Please read Samuel's blog post if you haven't already: https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html
Regarding imagefactory and oz, it looks like those are for cloud images? I'm confused what that has to do with mobile phones. I'm talking about the Workstation/Plasma/XFCE images on https://alt.fedoraproject.org/alt/
As for encryption, we could encrypt the filesystem in a loopback image or with Tow Boot's USB Mass Storage mode if Plymouth could show an on screen keyboard to decrypt it.
Hello,
On Fri, Feb 11, 2022 at 2:51 AM Be be0@fedoraproject.org wrote:
I agree that having a firmware in the SPI flash that makes devices comply with the SystemReady IR spec is the way to go. This is also aligned with the Fedora IoT folks vision in general since it is better to have standard images than device specific ones.
Whether Tow Boot or uboot is on the SPI flash isn't really relevant to distros. The point is that distros shouldn't have to worry about shipping uboot, just like Fedora doesn't ship UEFI firmware for x86-64. Tow Boot has some UX advantages for mobile
devices that may or may not be wanted in upstream uboot. Please read Samuel's blog post if you haven't already: https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html
While Tow Boot seems to be a cool project, it is a Nix u-boot package with tons of downstream patches. The author mentions that does this to experiment and that the goal is to eventually propose all those patches to u-boot for upstreaming.
My opinion is that Fedora should target upstream u-boot instead of what is in practice a downstream u-boot fork. As you say, what u-boot flavour is used isn't really that relevant as long as it follows the u-boot distro commands and is able to find an EFI binary that can be booted using u-boot's EFI support.
So if the Pine64 folks chose to ship Tow Boot and that allows Fedora users to write a generic image on the uSD card and boot, that's great but we should probably document how to flash a u-boot image from the Fedora u-boot package in the SPI flash. At least if they expect Fedora developers to help with bugs reported for the firmware and firmware -> bootloader interaction.
Regarding imagefactory and oz, it looks like those are for cloud images? I'm confused what that has to do with mobile phones. I'm talking about the Workstation/Plasma/XFCE images on https://alt.fedoraproject.org/alt/
Are you talking about Image Factory or Image Builder ? My understanding is that the future is the latter, which uses underneath osbuild (which btw you can use to build aarch64 images as well): https://www.osbuild.org/
As for encryption, we could encrypt the filesystem in a loopback image or with Tow Boot's USB Mass Storage mode if Plymouth could show an on screen keyboard to decrypt it.
I see that there's an issue filed for this already https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/144
Best regards, Javier
Firstly please use a valid email address.
Whether Tow Boot or uboot is on the SPI flash isn't really relevant to distros. The point is that distros shouldn't have to worry about shipping uboot, just like Fedora doesn't ship UEFI firmware for x86-64. Tow Boot has some UX advantages for mobile devices that may or may not be wanted in upstream uboot. Please read Samuel's blog post if you haven't already: https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html
We don't ship UEFI firmware for x86 devices but those vendors actively support there devices and firmware in the case of Pine64 they don't and I'd prefer to have something that I can verify rather than random stuff thrown at a wall from someone else. In 12+ years of working on Fedora arm its a lot less stress, but if Pine64 shipped their firmware that was signed and verifyable to LVFS and I could verify the signature etc and updatable with fwupd using UEFI capsule updates which is what we're working on with a number of vendors I would not build those firmwares in Fedora at all. We have a number of vendors where it's just like x86 already.
Regarding imagefactory and oz, it looks like those are for cloud images? I'm confused what that has to do with mobile phones. I'm talking about the Workstation/Plasma/XFCE images on https://alt.fedoraproject.org/alt/
They're not just for cloud images, they are a means of generating a image whether it be virtual or real hardware. All the images you reference are generated with ImageFactory. Believe me I set it up.
As for encryption, we could encrypt the filesystem in a loopback image or with Tow Boot's USB Mass Storage mode if Plymouth could show an on screen keyboard to decrypt it.
We will have solved this problem with ImageBuilder very shortly. Watch F-37 features for IoT Edition as that will be the first adopter of that, as for OSK for plymouth, someone will need to do that work.
On Fri, Feb 11, 2022 at 01:42:39AM -0000, Be wrote:
Whether Tow Boot or uboot is on the SPI flash isn't really relevant to distros. The point is that distros shouldn't have to worry about shipping uboot, just like Fedora doesn't ship UEFI firmware for x86-64. Tow Boot has some UX advantages for mobile devices that may or may not be wanted in upstream uboot. Please read Samuel's blog post if you haven't already: https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html
Sure. Although if we are asking them to ship with something perhaps our pleas will influence what they decide to do.
Regarding imagefactory and oz, it looks like those are for cloud images? I'm confused what that has to do with mobile phones. I'm talking about the Workstation/Plasma/XFCE images on https://alt.fedoraproject.org/alt/
So, yeah, fedora makes tons of different kinds of images. We have dvd isos, we make live images that expect to be booted to a live env (which you can then later install from), qcow2's for virt/cloud, raw disk images (where you expect to dd or use arm-image-installer to transfer to a usd card and run it), etc.
We use a bunch of different tools for this currently, depending on the image:
If it's a install dvd (like the server install dvd), it's made by pungi. If it's a live media (expecting to copy to a usb or the like and run live, later optional install) it's made by livemedia-creator. If it's a raw image (like current single board arm things we support) it's made by imagefactory.
Our existing arm supported devices have followed the 'run arm-image-installer' to install a raw image to a usd and run from there. It might make sense to do something different for the pp and ppp...
As for encryption, we could encrypt the filesystem in a loopback image or with Tow Boot's USB Mass Storage mode if Plymouth could show an on screen keyboard to decrypt it.
Yeah. Lots to work out.
kevin
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:
- SPI flash
- eMMC
- 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. Also You miss 0) USB recovery, I'm hoping the PPP has a means of putting it into this mode with the external HW buttons similar to how you can do so with all Android phones.
From the factory, there is a u-boot image on the eMMC drive which will boot an OS from the SD card before the eMMC and there is nothing on the SPI flash. This is problematic because it's really easy to accidentally get the device into an unbootable state when installing an OS to the eMMC drive if the factory uboot build is erased. There is a way to temporarily disable the eMMC drive in hardware to make it boot from SD, but that's not obvious or convenient. So, currently, the Pine wiki (https://wiki.pine64.org/wiki/PinePhone_Pro) advises against replacing the stock Manjaro OS on the eMMC drive and few distros are providing prebuilt images.
See point above about USB recovery.
People working on different distros have been coordinating how to deal with this. The plan is to use a fairly new project, Tow Boot, and flash it to the SPI flash: https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html Putting the platform firmware on the SPI flash chip separate from the eMMC drive will make the process of installing OSes easier and more foolproof. Support for the Pinephone Pro in Tow Boot is almost ready with support for the Pinephone Pro's SPI flash just added today, albeit it needs a little polishing. Tow Boot on the SPI flash will make the process of installing an OS similar to x86; distros just need to create a UEFI bootable system and do not need to worry about shipping platform firmware. Tow Boot also obviates the need for JumpDrive. 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. Hopefully future Pinephon e Pro batches will ship with Tow Boot on the SPI flash from the factory, but for now users will need to install it by booting a Linux system from an SD card. A Tow Boot installer image like that has already been made for the Pinebook Pro, so I think one for the Pinephone Pro will be ready to test soon.
I see a number of problems with tow-boot. 1) I don't see any reference in that post to the PPP 2) The whole "incubator for my long shot ideas" just says to me "throw any shit over the fence" which means if it doesn't work with Fedora we're shit out of luck and can't fix stuff ourselves 3) I don't see the project having independent code review for security and related bits. 4) support. 5) without a SPI flash there's a bunch of other possible issues
This is great new for Fedora because I think it means we can use the normal Fedora tools for building ARM images to create UEFI bootable images without needing the scripts in https://github.com/nikhiljha/pp-fedora-sdsetup that were made for the Pinephone. Using Fedora tooling to build the Pinephone Pro images opens up the path to smartphone support in upstream Fedora. I've been digging around in scattered documentation and talking to Conan Kudo on Matrix and IIUC, the way the upstream images are built is that Punji calls `koji image-build` which calls livemedia-creator. Please correct me if I've misunderstood this. I've tried to figure out how to build aarch64 images locally on my x86-64 laptop and made a bit of progress using Mock with livemedia-creator as documented at https://weldr.io/lorax/livemedia-creator.html#using-mock-and-no-virt-to-crea...
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.
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 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.
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/...
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,
Does this seem like a reasonable plan? Is there anything I've overlooked?
No, TBH not really.
Bringing this subthread to devel@ since apparently this has a wide impact...
On Sat, Feb 12, 2022 at 2:26 PM Peter Robinson pbrobinson@gmail.com wrote:
This is great new for Fedora because I think it means we can use the normal Fedora tools for building ARM images to create UEFI bootable images without needing the scripts in https://github.com/nikhiljha/pp-fedora-sdsetup that were made for the Pinephone. Using Fedora tooling to build the Pinephone Pro images opens up the path to smartphone support in upstream Fedora. I've been digging around in scattered documentation and talking to Conan Kudo on Matrix and IIUC, the way the upstream images are built is that Punji calls `koji image-build` which calls livemedia-creator. Please correct me if I've misunderstood this. I've tried to figure out how to build aarch64 images locally on my x86-64 laptop and made a bit of progress using Mock with livemedia-creator as documented at https://weldr.io/lorax/livemedia-creator.html#using-mock-and-no-virt-to-crea...
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.
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.
Say *what*?!?
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,
Okay, this whole idea of moving everything to Image Builder is news to me. There's been *zero* discussion, preparation, or consultation with literally *anyone* over this. You *do* know that people other than you have to work with this stuff too, right? Did you (or whoever decided we're doing this) talk to any of the WGs or SIGs about this plan? What about feature parity? And what about teaching people to be able to work with it?
I'm involved in two desktop SIGs/WGs and the Cloud SIG/WG, and I had *no* idea you were planning this. I would expect at *least* a heads up and some reference of how things are going to work so we can get familiar with it.
In principle, I welcome having better image build tooling if it means that it's easier for us to work with it, but such changes are not done unilaterally, especially if you want others to be able to help and work with these.
I know you've complained about being the only person working on stuff, but I can say that one aspect of why you are the only one is because the tooling is a royal pain to use now.
I personally don't use ImageFactory with the ARM kickstarts, even though ImageFactory is what we use to produce the images. That's because ImageFactory crashes on my computer and is basically unusable.
Anyway, since I know now... I'm looking forward to your Change proposal and accompanying documentation.
Bringing this subthread to devel@ since apparently this has a wide impact...
On Sat, Feb 12, 2022 at 2:26 PM Peter Robinson pbrobinson@gmail.com wrote:
This is great new for Fedora because I think it means we can use the normal Fedora tools for building ARM images to create UEFI bootable images without needing the scripts in https://github.com/nikhiljha/pp-fedora-sdsetup that were made for the Pinephone. Using Fedora tooling to build the Pinephone Pro images opens up the path to smartphone support in upstream Fedora. I've been digging around in scattered documentation and talking to Conan Kudo on Matrix and IIUC, the way the upstream images are built is that Punji calls `koji image-build` which calls livemedia-creator. Please correct me if I've misunderstood this. I've tried to figure out how to build aarch64 images locally on my x86-64 laptop and made a bit of progress using Mock with livemedia-creator as documented at https://weldr.io/lorax/livemedia-creator.html#using-mock-and-no-virt-to-crea...
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.
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.
Say *what*?!?
All the arm images use ImageBuilder, they always have. Not sure what you mean by "what" here.
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,
Okay, this whole idea of moving everything to Image Builder is news to me. There's been *zero* discussion, preparation, or consultation with literally *anyone* over this. You *do* know that people other than you have to work with this stuff too, right? Did you (or whoever decided we're doing this) talk to any of the WGs or SIGs about this plan? What about feature parity? And what about teaching people to be able to work with it?
Not everything is moving to ImageBuilder for F-37, actually just IoT will be and it's been discussed there but I've never seen you there so maybe you missed it. It's a nicely contained compose where we can sort out all the problems with it without impacting the main compose and desktop deliverables.
Once we know how the service looks there will be proposals to move other artifacts over but that won't be until "feature parity", and in the case of ImageFactory frankly that won't be hard.
I'm involved in two desktop SIGs/WGs and the Cloud SIG/WG, and I had *no* idea you were planning this. I would expect at *least* a heads up and some reference of how things are going to work so we can get familiar with it.
Well ATM it's not planned for anything outside of IoT and once we know that's going to work there will be a Fedora Change proposal for IoT so it will be following the appropriate process.
In principle, I welcome having better image build tooling if it means that it's easier for us to work with it, but such changes are not done unilaterally, especially if you want others to be able to help and work with these.
You've completely miss interpreted what I wrote, believe me it will be *SO* much better.
I know you've complained about being the only person working on stuff, but I can say that one aspect of why you are the only one is because the tooling is a royal pain to use now.
Which is why I have been working with Matthew Miller, CPE and the ImageBuilder team to get the pieces in place so we can start to move over to tooling that is actively maintained and developed. Due to my available time, and the fact that I mostly care about IoT we're focusing on that to ensure that it can provide the key functionality, but as somehow being the person being the oz/ImageFactory maintainer I am well aware of the functionality it provided and will be ensuring it provides all that so we can EOL the old tools.
I personally don't use ImageFactory with the ARM kickstarts, even though ImageFactory is what we use to produce the images. That's because ImageFactory crashes on my computer and is basically unusable.
Anyway, since I know now... I'm looking forward to your Change proposal and accompanying documentation.
It will have a Change Proposal, starting with IoT. It's fully planned to follow the full Fedora process. As stated above it will start with IoT where we can deal with it in a contained manner. In the case of Mobility we're some way off from being able to provide anything official so in that context it would make sense to go with that tooling from the outset. We (the RHEL for Edge team in Red Hat) are working on things like producing images in ImageBuilder that are "encrypted" with a null cypher able to be re-encrypted on first boot so it makes sense to just consume that for Mobility functionality. We will be using that in Fedora IoT (yes, there will be changes for that too, I like marketing).
So please don't get your knickers in a knot, things are happening with regards to lovely enhancements to available services for infrastructure but rest assured when they are available they will be announced and when they change Fedora deliverables there will be proper change process followed.
P
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:
- SPI flash
- eMMC
- 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/35916/...
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?
reencrypt
On Sat, Feb 12, 2022 at 10:55 PM Be be.0@gmx.com 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:
- SPI flash
- eMMC
- 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.
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/...
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.
On 2/12/22 17:08, Peter Robinson wrote:
reencrypt
On Sat, Feb 12, 2022 at 10:55 PM Be be.0@gmx.com 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:
- SPI flash
- eMMC
- 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".
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/...
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.
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?
On Sat, Feb 12, 2022 at 11:19 PM Be be.0@gmx.com wrote:
On 2/12/22 17:08, Peter Robinson wrote:
reencrypt
On Sat, Feb 12, 2022 at 10:55 PM Be be.0@gmx.com 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:
- SPI flash
- eMMC
- 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/...
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.
On Sat, Feb 12, 2022 at 11:28:08PM +0000, Peter Robinson wrote:
On Sat, Feb 12, 2022 at 11:19 PM Be be.0@gmx.com wrote:
...snip...
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.
There is a way to bypass the eMMC if something goes wrong: https://wiki.pine64.org/wiki/PinePhone_Pro#Boot_order
kevin
On 2/12/22 17:28, Peter Robinson wrote:
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.
What is "Rockchip recovery"? Do you mean this: https://github.com/rockchip-linux/recovery ? I think that's some sort of "Android recovery" thing? How is that relevant to Fedora? Why would you want some Androidism rather than Tow Boot's USB mass storage mode?
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.
So I guess this is a CLI tool that reads the password from stdin? If so it should be easy enough for an OSK to output to it.
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.
What is "Rockchip recovery"? Do you mean this: https://github.com/rockchip-linux/recovery ? I think that's some sort of "Android recovery" thing? How is that relevant to Fedora? Why would you want some Androidism rather than Tow Boot's USB mass storage mode?
It runs from MASKROM so it's low level recovery, it's a means of recovering the firmware to recover bricked devices, the OS is irrelevant.
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.
So I guess this is a CLI tool that reads the password from stdin? If so it should be easy enough for an OSK to output to it.
On 2/12/22 19:04, Peter Robinson wrote:
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.
What is "Rockchip recovery"? Do you mean this: https://github.com/rockchip-linux/recovery ? I think that's some sort of "Android recovery" thing? How is that relevant to Fedora? Why would you want some Androidism rather than Tow Boot's USB mass storage mode?
It runs from MASKROM so it's low level recovery, it's a means of recovering the firmware to recover bricked devices, the OS is irrelevant.
Reading about Rockchip recovery for other devices, it seems that presents the device as a nonstandard USB device that requires a vendor-specific driver and userspace tooling. I don't understand what advantage this has over Tow Boot where you can just press Power + Volume Up to expose the eMMC as a USB mass storage device then use good old fashion dd.
On Sun, Feb 13, 2022 at 1:38 AM Be be.0@gmx.com wrote:
On 2/12/22 19:04, Peter Robinson wrote:
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.
What is "Rockchip recovery"? Do you mean this: https://github.com/rockchip-linux/recovery ? I think that's some sort of "Android recovery" thing? How is that relevant to Fedora? Why would you want some Androidism rather than Tow Boot's USB mass storage mode?
It runs from MASKROM so it's low level recovery, it's a means of recovering the firmware to recover bricked devices, the OS is irrelevant.
Reading about Rockchip recovery for other devices, it seems that presents the device as a nonstandard USB device that requires a vendor-specific driver and userspace tooling. I don't understand what advantage this has over Tow Boot where you can just press Power + Volume Up to expose the eMMC as a USB mass storage device then use good old fashion dd.
You're completely missing the point, it's for base level recovery for even if the firmware is hosed. It's designed for recovery even if the firmware breaks, so it could be used to recover tow-boot too.
On 2/13/22 03:04, Peter Robinson wrote:
On Sun, Feb 13, 2022 at 1:38 AM Bebe.0@gmx.com wrote:
On 2/12/22 19:04, Peter Robinson wrote:
> Simply pressing the volume up button on boot will expose the eMMC drive as a USB mass storage device, refer tohttps://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.
What is "Rockchip recovery"? Do you mean this: https://github.com/rockchip-linux/recovery ? I think that's some sort of "Android recovery" thing? How is that relevant to Fedora? Why would you want some Androidism rather than Tow Boot's USB mass storage mode?
It runs from MASKROM so it's low level recovery, it's a means of recovering the firmware to recover bricked devices, the OS is irrelevant.
Reading about Rockchip recovery for other devices, it seems that presents the device as a nonstandard USB device that requires a vendor-specific driver and userspace tooling. I don't understand what advantage this has over Tow Boot where you can just press Power + Volume Up to expose the eMMC as a USB mass storage device then use good old fashion dd.
You're completely missing the point, it's for base level recovery for even if the firmware is hosed. It's designed for recovery even if the firmware breaks, so it could be used to recover tow-boot too.
Considering I've never heard anyone, including the people working on Tow Boot, mention this with regard to the Pinephone Pro, I don't see how this is relevant. In the worst case you can press the RE button to disable the eMMC and it will boot from an SD card, which you can use to run the Tow Boot installer to flash it to the SPI flash.
Anyway, back to stuff that does matter for Fedora, can ImageBuilder currently produce raw UEFI bootable images or not? If it can, why doesn't that show up as an option when I run `composer-cli compose types`? Is there another package I need to install?
-
Be -
Be -
Javier Martinez Canillas -
Kevin Fenzi -
Neal Gompa -
Peter Robinson