##(see the SpecSpec for an explanation)

 * '''Launchpad Entry''': UbuntuSpec:mobile-lucid-arm-ext-images
 * '''Created''': November 9th, 2009
 * '''Contributors''': Michael Casadevall
 * '''Packages affected''': debian-cd, ubuntu-cdimage

== Summary ==

As it stands, ARM images are currently created as a dd'able VFAT image that should be written to a pendrive for booting ARM SoCs. This specification considers the possibility of creating extX images versus vfat images on antimony.

== Release Note ==

ARM images are now ext{2|3|4} based.

== Rationale ==

vfat based images impose significant limitations such as no links, and limitations on filenames (which under specific circumstances are known to break alternate images). By moving to extX based images, we can bypass these limitations, and well as have media thats much more robust to abuse (such as sudden shutdowns). As the critical-blocker issues with VFAT images has thus been resolved, evaluation of the remaining merits ext-based images must be completed before continuing.

== User stories ==

== Assumptions ==
 * That all SoCs can start from at least an ext2 filesystem
 * That there is a sane way to create said filesystem as a non-root user (possibly using Device/PolicyKit) so we can replace mtools

== Design ==

== Implementation ==

debian-cd and Canonical IS require that we have a non-root method of building filesystem images. A proof of concept using e2tools exists, but currently is fairly slow, and will require optimiziation if we choose to peruse ext based images.
 
=== Code Changes ===

debian-cd will have to have support for a new ext2/3/4 image type, which will invoke the proper creation scripts similar to the already existing iso and vfat image types

=== Migration ===

N/A: Only affects new installations

== Test/Demo Plan ==

Current ISO testing mechanisms can be used for testing the resulting images.

== Unresolved issues ==
 * That there is a sane way to create said filesystem as a non-root user (possibly using Device/PolicyKit) so we can replace mtools

== BoF agenda and discussion ==

{{{
== Why? ==
 * vfat not robust, especially for persistent images
 * can use links for multiple kernels, squashfs's, etc -- Meh!
 * attributes and permissions  relevant? -- see point 2
 * performance improvement, can be tuned & optimized
 * supported by various boot loaders
 
== Why not? ==
 * Loose compatibility with ms & os/x
 * Build time on build system slower
 * flash devices may require vfat for fs block levelling
 * incompatible with usb creator use cases
 * persistence and permissions is not relevent
 * what are real use cases for links?  any?
 * some boot loaders/softloader may not work with ext2/3
 
== Action Items ==
 * benchmarking ext2 vs vfat performance for casper, validate >=10% 
   * boot and installation times
}}}
----
CategorySpec