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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
