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

[Gordan Bobic]

On 02/06/2012 10:26 PM, Dennis Gilmore wrote:
> El Thu, 02 Feb 2012 17:22:06 -0500
> Jonathan Chiappetta<jchiappetta at learn.senecac.on.ca>  escribió:
>> I would like to discuss (or learn about previous discussions)
>> regarding the file format for future possible fedora-arm releases. I
>> believe we should have one file which should provide all the data
>> necessary to make a final bootable fedora-arm device.
>>
>> Are there any suggestions on how the file should be laid out? For
>> example:
>>
>> Fedora-20-ARMv5-Guru.tgz = { ARMv5.guru.boot.tgz ,
>> Fedora-20-ARM.root.tgz } Fedora-20-ARMv5-Panda.tgz =
>> { ARMv5.panda.boot.tgz , Fedora-20-ARM.root.tgz }
>> Fedora-20-ARMv7-Panda.tgz = { ARMv7.panda.boot.tgz ,
>> Fedora-20-ARM.root.tgz } ...
>>
>> The only problem I don't understand is that it doesn't seem to be as
>> simple as just choosing a general ARMv5 kernel for an ARMv5 device as
>> an ARMv5 Guru differs from a ARMv5 Smarttop which differs from an
>> ARMv5 Panda, etc...
>>
>> I'm sure most of you have a better idea of how this should work but
>> the user should only have to download one file at the end of the day
>> right?
>>
>> Thanks,
>> Jon.
>>
>>
>
> I think that what we likely need to do is to ship something that is a
> disk image. a sparsified file say 2 or 4g that we setup with MLO
> installed first, a vfat first partition. and a / partition.  that we
> can just dd onto a sdcard. then extend the filesystem to the size of
> the disk. this way things like a guruplug, panda etc just work.
>
> for a trimslice we likely want to a anaconda install image that can be
> booted and will run anaconda.
>
> in the first case we should have a minimal install, XFCE, gnome, KDE,
> LXDE, and SoaS at the least.  anaconda can follow later. we could
> always boot the live sdcards on a trimslice or a smartop/smartbook
> where you have the possibility of running anaconda. as well as future
> server class hardware. its something that needs o be on the road map.
> but doesnt need to be now.  Im not sure that we should ship just
> tarballs of root filesystems. a card deployment tool could use qemu and
> yum to install the right kernel for the system onto a sdcard. once we
> have dd'ed on the drive.
>
> What im getting at is we need to have a packaged format like a disk
> image, something that is simple to deploy. isos do not really make any
> sense for ARM, but we should have live images, install images, etc.

All this seems a bit too close to just untarring the image. If you're 
going to do that, might as well wait for a working Anaconda, ship an 
image of the ext4 file system and on it all the rpms, and let Anaconda 
install to the same fs it's running from.

The problem is that you still have the problem of having to load up a 
different kernel image for every device. Until that is no longer 
necessary (and let's face it, that's going to be a while), I'm not sure 
I see that much value in complicated installation procedures.

After all, if somebody knows how to dd an image to a SD card, they also 
know how to untar the rootfs onto the SD card. And since even then it 
won't just boot without the correct kernel for the device, I'm not at 
all sure I see the advantage. It certainly doesn't seem to improve 
accessibility for the less technically minded.

Gordan