[fedora-arm] Possible File Formats for a Fedora ARM release

Brendan Conoboy blc at redhat.com
Fri Feb 17 06:40:02 UTC 2012


A little late replying, but hopefully people are still up for the 
discussion....

On 02/06/2012 08:33 PM, Chris Tyler wrote:
> Can we really reduce this to 2x2?...
>
> Partitioning:
> - one partition (tegra)(kirkwood)
> - two partitions (omap)(happy kirkwood)(raspi)
> - three partitions or more (jcm ;-)
> - non-partitioned bootloader area plus two partitions (ecafe)

Let me throw a different perspective at this: What if we waste some 
space?  I mean, just because tegra only needs one partition doesn't mean 
the standard image we produce can't have 3, right?  It's a little 
wasteful, but the idea is that we're optimizing for simple distribution 
rather than for optimal installation.  Perhaps we make a stock image 
with 3 partitions leaving some space where the non-partitioned 
bootloader would go.  What is the widest-common-denominator we can get 
to in a single partition layout?  Lets shoot for that.

> Kernel format:
> - uImage
> - uImage plus prepended headers (raspi)

That just means we need the files to have different names, no?

> Bootloader configuration:
> - boot.scr
> - nand
> - cmdline.txt

Trickier, probably calling for documentation rather than a just-works 
configuration.  Then again, if we target the most popular device for 
each standard filename we go a long way toward satisfying the widest 
possible audience.  Then document those target devices that aren't 
covered by the defaults.

> Bootloader binary:
> - MLO in partition 1 (omap)
> - gpu firmware in partition 1 (raspi)

Can we put mlo and gpu firmware in the same partition?  If their 
filenames are distinct it's just a small loss of space to support both.

> - in nand (plug computers)

Documentation for this, alas.

> ...etc.

It's that etc that's getting me.  Even though all these boards have 
different requirements, they aren't all conflicting, they're just 
different and cause some bloat to support from a single image.  A single 
image that handles most of the use cases is possible, even if it isn't 
space optimal.  At least, that's my theory.  Perhaps somebody who has 
more of the hardware in question can comment.

> But back to the original question: what's the optimal way to package an
> installable image? I see several valid options:
>
> (1)- Per-platform image with MBR plus one or more partitions, with the
> last partition shipped as minimal length and resizable to fill the
> device (either at installation or firstboot).
>
> (2)- Per-platform tarball, including a tarball for a boot partition (if
> applicable) plus a tarball of the rootfs, plus some sort of layout
> config file (XML? script?) that configures how the partitioning is set
> up.
>
> (3)- Generic per-arch (armv5tel/armv7hl) rootfs tarball plus
> per-platform boot tarball, separately downloaded. (Nice to cache the
> rootfs if installing into multiple, different devices, but messy as far
> as RPM knowledge of what's on the boot partition).

(4) One tarball with a firstboot script that resizes / to fill the 
remainder of space then resize2fses itself :-)

Really though, whoever does the work to make something happen gets to be 
right for the time being.

> I think having an easy installer is ultimately more important than which
> format we use. To get tens of thousands of people running Fedora on
> Raspis in the next six months, for example, we need a tool that's
> friendly, dirt-simple to use, and ideally runs on Windows as well as
> Fedora.

Agree the an installer is definitely called for, but I'd like to 
continue working on a native installer, while granting that a non-arm 
image installer is also called for (Certainly it's the only way you're 
going to get an optimal rootfs out of the box).

-- 
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com


More information about the arm mailing list