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.
On 02/02/2012 10:22 PM, Jonathan Chiappetta wrote:
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?
Not going to happen, sadly. The rootfs is common across all the devices (armv5tel for soft-float, armv7hl for hard-float).
Kernels are SoC specific. Not quite as narrowly specialized as device specific, but it's still not going to be a one-size-fits all, at least not any time soon (probably years).
For example, if you have a Marvell Kirkwood kernel, you could use that kernel on all supported Marvell Kirkwood devices (SheevaPlug, GuruPlug, DreamPlug, etc.). If you have a Marvell Armada kernel, you could boot that on a D2Plug, CuBox, Compulab SBC-A510, etc. If you have a Tegra2 kernel, you could boot that on Toshiba AC100, TrimSlice, etc.
Gordan
Gordan Bobic gordan@bobich.net writes:
Kernels are SoC specific. Not quite as narrowly specialized as device specific, but it's still not going to be a one-size-fits all, at least not any time soon (probably years).
For example, if you have a Marvell Kirkwood kernel, you could use that kernel on all supported Marvell Kirkwood devices (SheevaPlug, GuruPlug, DreamPlug, etc.). If you have a Marvell Armada kernel, you could boot that on a D2Plug, CuBox, Compulab SBC-A510, etc. If you have a Tegra2 kernel, you could boot that on Toshiba AC100, TrimSlice, etc.
Just a pipe-dream, but how hard would it be to take these SoC-specific requirements and move them into a module that could get put into the initramfs? Is there enough generic across all e.g. Armv5 boards that this could happen?
Gordan
-derek
On Fri, Feb 3, 2012 at 1:50 PM, Derek Atkins warlord@mit.edu wrote:
Gordan Bobic gordan@bobich.net writes:
Kernels are SoC specific. Not quite as narrowly specialized as device specific, but it's still not going to be a one-size-fits all, at least not any time soon (probably years).
For example, if you have a Marvell Kirkwood kernel, you could use that kernel on all supported Marvell Kirkwood devices (SheevaPlug, GuruPlug, DreamPlug, etc.). If you have a Marvell Armada kernel, you could boot that on a D2Plug, CuBox, Compulab SBC-A510, etc. If you have a Tegra2 kernel, you could boot that on Toshiba AC100, TrimSlice, etc.
Just a pipe-dream, but how hard would it be to take these SoC-specific requirements and move them into a module that could get put into the initramfs? Is there enough generic across all e.g. Armv5 boards that this could happen?
At the moment impossible. Once devicetree gets completed it then becomes quite probable.
Peter
On 02/02/2012 02:41 PM, Gordan Bobic wrote:
Not going to happen, sadly. The rootfs is common across all the devices (armv5tel for soft-float, armv7hl for hard-float).
Hold up, there's a middle ground that we can shoot for here, even prior to everybody getting onboard with FDT.
Kernels are SoC specific. Not quite as narrowly specialized as device specific, but it's still not going to be a one-size-fits all, at least not any time soon (probably years).
What it really comes down to is getting the bootloader (typically uboot) to load a kernel and initramfs. Maybe it's an OMAP or a Tegra kernel, maybe it's Kirkwood or Highbank or Armada or or or... but you can squeeze all that onto one tarball.
The support grid is really just 2x2: You're either armv5tel or armv7hl. You either need a separate partition for bootloader bits (omap, etc scenario) or you don't (tegra scenario). Putting together tarball that has everything a person needs for most systems is doable. A couple paragraphs per board type for how to get the specific board type is all it will take in the way of specialized documentation. In most cases it will simply be a matter of a couple setenv commands.
On Fri, 2012-02-03 at 16:25 -0800, Brendan Conoboy wrote:
The support grid is really just 2x2: You're either armv5tel or armv7hl. You either need a separate partition for bootloader bits (omap, etc scenario) or you don't (tegra scenario). Putting together tarball that has everything a person needs for most systems is doable. A couple paragraphs per board type for how to get the specific board type is all it will take in the way of specialized documentation. In most cases it will simply be a matter of a couple setenv commands.
Can we really reduce this to 2x2?...
Partitioning: - one partition (tegra)(kirkwood) - two partitions (omap)(happy kirkwood)(raspi) - three partitions or more (jcm ;-) - non-partitioned bootloader area plus two partitions (ecafe)
Kernel format: - uImage - uImage plus prepended headers (raspi)
Bootloader configuration: - boot.scr - nand - cmdline.txt
Bootloader binary: - MLO in partition 1 (omap) - gpu firmware in partition 1 (raspi) - in nand (plug computers)
...etc.
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.
-- Chris
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.
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.
--Mark Langsdorf Calxeda, Inc.
On Tue, Feb 7, 2012 at 9:15 PM, Mark Langsdorf mark.langsdorf@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.
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.
Peter
On 02/07/2012 10:20 PM, Peter Robinson wrote:
On Tue, Feb 7, 2012 at 9:15 PM, Mark Langsdorf mark.langsdorf@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).
Gordan
On Tue, Feb 7, 2012 at 10:26 PM, Gordan Bobic gordan@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.langsdorf@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
On 02/07/2012 10:34 PM, Peter Robinson wrote:
On Tue, Feb 7, 2012 at 10:26 PM, Gordan Bobicgordan@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.langsdorf@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.
It would still offer package configuration flexibility, you'd just use the installer FS as the rootfs. But yes, you wouldn't get the flexibility of fs layout and fs type flexibility. Then again, if that's an issue, you don't get partition alignment flexibility anyway, which tends to be pretty important on SSDs and disks with 4KB hardware sectors (especially those that completely hide the fact that they have 4KB sectors). So I would argue that if we're going to worry about that, let's worry about the full scale of the limitations that the installer imposes.
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.
The problem with the text mode install is that the manual partition options were removed, and there is no way to do anything but an install using the default partition layout. Kickstart is a workaround, but having to either write a kickstart for a every test install is tedious when there is no reason for it to be.
Gordan
A little late replying, but hopefully people are still up for the discussion....
On 02/06/2012 08:33 PM, Chris Tyler wrote:
Can we really reduce this to 2x2?...
Partitioning:
- one partition (tegra)(kirkwood)
- two partitions (omap)(happy kirkwood)(raspi)
- three partitions or more (jcm ;-)
- non-partitioned bootloader area plus two partitions (ecafe)
Let me throw a different perspective at this: What if we waste some space? I mean, just because tegra only needs one partition doesn't mean the standard image we produce can't have 3, right? It's a little wasteful, but the idea is that we're optimizing for simple distribution rather than for optimal installation. Perhaps we make a stock image with 3 partitions leaving some space where the non-partitioned bootloader would go. What is the widest-common-denominator we can get to in a single partition layout? Lets shoot for that.
Kernel format:
- uImage
- uImage plus prepended headers (raspi)
That just means we need the files to have different names, no?
Bootloader configuration:
- boot.scr
- nand
- cmdline.txt
Trickier, probably calling for documentation rather than a just-works configuration. Then again, if we target the most popular device for each standard filename we go a long way toward satisfying the widest possible audience. Then document those target devices that aren't covered by the defaults.
Bootloader binary:
- MLO in partition 1 (omap)
- gpu firmware in partition 1 (raspi)
Can we put mlo and gpu firmware in the same partition? If their filenames are distinct it's just a small loss of space to support both.
- in nand (plug computers)
Documentation for this, alas.
...etc.
It's that etc that's getting me. Even though all these boards have different requirements, they aren't all conflicting, they're just different and cause some bloat to support from a single image. A single image that handles most of the use cases is possible, even if it isn't space optimal. At least, that's my theory. Perhaps somebody who has more of the hardware in question can comment.
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).
(4) One tarball with a firstboot script that resizes / to fill the remainder of space then resize2fses itself :-)
Really though, whoever does the work to make something happen gets to be right for the time being.
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.
Agree the an installer is definitely called for, but I'd like to continue working on a native installer, while granting that a non-arm image installer is also called for (Certainly it's the only way you're going to get an optimal rootfs out of the box).
El Thu, 02 Feb 2012 17:22:06 -0500 Jonathan Chiappetta jchiappetta@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.
Dennis
On 02/06/2012 10:26 PM, Dennis Gilmore wrote:
El Thu, 02 Feb 2012 17:22:06 -0500 Jonathan Chiappettajchiappetta@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