any drawbacks to using copy-nand and save-nand to install XO images

[Michael Stone]

Bryan,

Several weeks ago, I was asked to do reverse engineer an image created via
save-nand for another client and I discovered many "unexpected differences"
that had crept into the image as a result of lack of detailed knowledge of what
happens during the first boot and lack of established procedures for comparing
images.

Some of the unintended changes that I observed included:

  * /home/olpc/.devkey.html  has been created and specialized.
  * Change in /etc/hosts
  * /security/state/var/lib/dbus/machine-id set.

  * LANG="es_AR.UTF-8"  setting in /home/olpc/.i18n
  * /security/state/etc/timezone set to GMT

  * Enabling XFree86-Misc extension in /etc/X11/xorg.conf
  * Removing the ServerFlags section in /etc/X11/xorg.conf
  * Removing control #32 in /etc/alsa/asound.state

  * 26M of data in /home/olpc/.sugar/default/data/
  * Extra cached data in /home/olpc/.sugar/default/*
  * Datastore exceptions recorded in the Journal log.
  * ssh(d) configuration and moduli in /security/state
  * LANG="C" setting in /security/state/etc/sysconfig/i18n 

The point of this laundry list is simply that, while save-nand may be
convenient for simple purposes, the changes made by our boot configuration
process causes it to generate very "ragged" results. A much better strategy is
to reflash an XO, boot it off of external media (like a USB key), make changes
to the NAND, then save-nand, thus avoiding the first-boot configuration junk.

Alternately, one can refer to the suggestions in an email I sent earlier this
week:

  http://lists.laptop.org/pipermail/devel/2008-March/012130.html

for some more other approaches.

Best,

Michael