On 02/07/2012 10:20 PM, Peter Robinson wrote:
On Tue, Feb 7, 2012 at 9:15 PM, Mark Langsdorf
<mark.langsdorf@xxxxxxxxxxx> wrote:
On 02/06/2012 10:33 PM, Chris Tyler wrote:
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).
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.
Speaking for a possible minority position here, I'd also like to
see a solution that scales well for business customers looking
to provision dozens to hundreds of notes with real SATA drives.
A generic 2GB image intended for an SD-card is probably not going
to fit the bill.
No, you would want a standard anaconda install for that using
kickstart files. The is planned and TBH may already even work.
Really? Anaconda has been made to build/work on ARM? When?
I don't see how anything other than option 3 is sustainable over
any significant number of different platforms, though. So I'd
want to see a resizable generic per-arch rootfs that is
intended to be the last partition following 0 or more boot
partitions that are platform specific.
I agree. The ultimate plan is to use anaconda for all options. Things
will settle down when things like device-tree become the norm and we
can use a few standard kernels across devices.
I don't see why it needs to be any diffrent - you can ship the ext4
installer image, make the installer stretch the image to the size of the
disk (or some user-selectable size), and then install from local disk to
local disk, to the same FS the installer is running from. The only
downside is that you will not be able to align the partitions properly
for the SSD erase block sizes and suchlike, but the primary
architectures don't do that either (whether they should is open to
debate, but I personally thought that removing the relevant options from
the text mode install around F11 was a giant leap backwards for server
installs).
Gordan
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
