11:49 p.m.
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-c...
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/359...
Does this seem like a reasonable plan? Is there anything I've overlooked?
4:57 p.m.
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:
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.
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-c...
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/359...
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
7:42 p.m.
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.
8:08 a.m.
Hello,
On Fri, Feb 11, 2022 at 2:51 AM Be <be0(a)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.
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/
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
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
1:25 p.m.
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. 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-c...
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/359...
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.
1:35 p.m.
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.
1:37 p.m.
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
1:57 p.m.
New subject: Moving everything to ImageBuilder in F37? (was Re: Re: Fedora on Pinephone Pro & path to upstreaming)
Bringing this subthread to devel@ since apparently this has a wide impact...
On Sat, Feb 12, 2022 at 2:26 PM Peter Robinson <pbrobinson(a)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-c...
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.
--
真実はいつも一つ！/ Always, there's only one truth!
2:23 p.m.
New subject: Moving everything to ImageBuilder in F37? (was Re: Re: Fedora on Pinephone Pro & path to upstreaming)
Bringing this subthread to devel@ since apparently this has a wide
impact...
On Sat, Feb 12, 2022 at 2:26 PM Peter Robinson <pbrobinson(a)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-c...
>
> 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
4:54 p.m.
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?
5:08 p.m.
reencrypt
On Sat, Feb 12, 2022 at 10:55 PM Be <be.0(a)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:
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.
> 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/359...
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.
5:19 p.m.
On 2/12/22 17:08, Peter Robinson wrote:
reencrypt
On Sat, Feb 12, 2022 at 10:55 PM Be <be.0(a)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:
>
> 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".
>> 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/359...
>
> 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?
5:28 p.m.
On Sat, Feb 12, 2022 at 11:19 PM Be <be.0(a)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(a)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:
>>
>> 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/359...
>>
>> 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.
5:48 p.m.
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(a)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
7 p.m.
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.
7:04 p.m.
>>> 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.
7:38 p.m.
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.
3:04 a.m.
On Sun, Feb 13, 2022 at 1:38 AM Be <be.0(a)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.
7:10 a.m.
On 2/13/22 03:04, Peter Robinson wrote:
On Sun, Feb 13, 2022 at 1:38 AM Be<be.0(a)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?
826
days inactive
839
days old
18 comments
6 participants
participants (6)
-
Be -
Be -
Javier Martinez Canillas -
Kevin Fenzi -
Neal Gompa -
Peter Robinson