Ubuntu Wiki

• Launchpad Entry: 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