On Tue, Feb 7, 2012 at 10:26 PM, Gordan Bobic <gor...@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.langsd...@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. 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. Peter _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
