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@xxxxxxxxxx
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
