any drawbacks to using copy-nand and save-nand to install XO images
michael at laptop.org
Thu Mar 27 15:23:59 EDT 2008
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
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
for some more other approaches.
More information about the Devel