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