Imaging/Side effects: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
Imaging laptops is not supported by OLPCA's deployment support team. However, it sometimes works in limited testing.
'''Imaging laptops is not supported by OLPCA's deployment support team. However, it sometimes works in limited testing.'''


We haven't worked on figuring out what pieces of the system are touched, so copying the machines can have unintended side effects. It seems that nearly everyone who tries to distribute images by cloning runs into some oddities.
We haven't worked on figuring out what pieces of the system are touched, so copying the machines can have unintended side effects. It seems that nearly everyone who tries to distribute images by cloning runs into some oddities.

Revision as of 13:39, 30 December 2010

Imaging laptops is not supported by OLPCA's deployment support team. However, it sometimes works in limited testing.

We haven't worked on figuring out what pieces of the system are touched, so copying the machines can have unintended side effects. It seems that nearly everyone who tries to distribute images by cloning runs into some oddities.

There are a number of changes made to system files during the first boot of the machine which you might not want to copy between machines. SSH keys, for instance, are generated once at first boot on every XO. Also, hardware-dependent information from the firmware is cached on the laptop after first boot.

That said, it also seems that this method of customization is the most appealing and straightforward, and matches some of the existing desktop deployment practices for ICT in education.

A comparison of changes caused by first boot is available at http://lists.laptop.org/pipermail/devel/2009-January/022334.html.

To correct for the side-effects you may either prepare the source system before it is cloned, or fix each target system after it is cloned. If you are cloning to more than one target, then it is more efficient to modify the source system. The same actions can be used in both cases:

# destroy saved volume settings, forcing defaults.
rm -f /etc/alsa/asound.state
# destroy saved wireless MAC address (not required on 10.1.2 build os851 or later)
rm -f /etc/udev/rules.d/70-persistent-net.rules
# destroy the SSH host key, forcing regeneration.
rm -f /etc/ssh/ssh_host_rsa_key{,.pub}
# destroy the Sugar settings, forcing a first boot name prompt.
rm -rf /home/olpc/.sugar

Usually the most important one is the last one, since without it collaboration between Sugar users may be hindered. Another way to achieve it on an already cloned target system is to start Terminal, enter the command:

rm -r .sugar

and then use Control/Alt/Erase to restart Sugar. The first boot name prompt will appear within about 12 seconds, on an XO-1.

See also: