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

Gordan Bobic gordan at bobich.net
Tue Feb 7 22:44:44 UTC 2012


On 02/07/2012 10:34 PM, Peter Robinson wrote:
> On Tue, Feb 7, 2012 at 10:26 PM, Gordan Bobic<gordan at bobich.net>  wrote:
>> On 02/07/2012 10:20 PM, Peter Robinson wrote:
>>>
>>> On Tue, Feb 7, 2012 at 9:15 PM, Mark Langsdorf
>>> <mark.langsdorf at calxeda.com>    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).
>
> Offers zero flexibility over file system types, file system layout,
> package configuration and a billion other combinations of choices that
> people might want.

It would still offer package configuration flexibility, you'd just use 
the installer FS as the rootfs. But yes, you wouldn't get the 
flexibility of fs layout and fs type flexibility. Then again, if that's 
an issue, you don't get partition alignment flexibility anyway, which 
tends to be pretty important on SSDs and disks with 4KB hardware sectors 
(especially those that completely hide the fact that they have 4KB 
sectors). So I would argue that if we're going to worry about that, 
let's worry about the full scale of the limitations that the installer 
imposes.

> Oh and text mode works just fine, even works over serial port. I use
> it on occasion but the fact is that anyone who does any amount of
> server installs that use those sorts of options automate it using
> kickstart and scripting.

The problem with the text mode install is that the manual partition 
options were removed, and there is no way to do anything but an install 
using the default partition layout. Kickstart is a workaround, but 
having to either write a kickstart for a every test install is tedious 
when there is no reason for it to be.

Gordan


More information about the arm mailing list