[fedora-arm] F14 qemu arm default board

[Gordan Bobic]

On 12/30/2010 05:44 PM, Chris Tyler wrote:
> On Thu, 2010-12-30 at 16:51 +0000, Gordan Bobic wrote:
>> Chris Tyler wrote:
>>
>>>> *since we don't seem to support kickstart, and we don't have an
>>>> installer, you can really only import in an existing image. But hey it
>>>> is better then what we had!
>>>
>>> The concept of an "installer" in ARM land is pretty limited. There is a
>>> graphical installer for Sheeva/Guruplugs, but it's primarily a tool for
>>> installing a kernel and prebuilt rootfs (it would be hard to package for
>>> Fedora, too, since it contains an entire prebuilt Linux image for use
>>> during bootstrapping, and building that from source would be Big).
>>
>> Sheeva can get a kernel image to boot via TFTP, so making an "installer"
>> kickstart a base image shouldn't be too difficult. the problem is
>> booting the installer in the first place.
>
> You could boot an installer via TFTP, but why? These systems aren't
> really strong for running software interactively -- you'd probably end
> up on the serial console (which you have to use to get the TFTP boot
> configured anyway).

Sure, for some things, but there is a growing number of netbooks based 
on ARM coming out, from the tiny ones with 128MB of RAM that go on ebay 
for £30, up to really decent ones like the Genesi Efika and Toshiba 
AC100. For these, an x86-style installer would easily be justifiable (if 
only their flash disk subsystem wasn't woefully slow - but as I said, 
that can be addressed by LD_PRELOAD-ing libeatmydata during the install, 
and syncing at the end. Or have the installer do the minimum install by 
extracting a tar ball and taking it from there with RPM for the extra 
packages.

> I think that installing a rootfs via SD/microSD is a much lower-pain
> option, and the right way forward is unifying the rootfs tools across
> the various archs. A rootfs and a live CD/live USB image are pretty much
> the same thing; we're currently using different tools on different
> archs, and the current tools are broken in various ways (LiveUSB with
> overlays stops with no notice and unrecoverable errors once the overlay
> is full -- a big problem for Sugar on a Stick -- and the rootfs tools
> for the secondary archs are different, many of them not using
> kickstarts) -- it's time to refactor and unify.

Definitely agreeing on unifying the approach.

Gordan