Imaging/Side effects: Difference between revisions
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. |
|||
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. |
||
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. |
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. |
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. |
A comparison of changes caused by first boot is available at http://lists.laptop.org/pipermail/devel/2009-January/022334.html. |
Revision as of 04:24, 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:
- http://lists.laptop.org/pipermail/devel/2008-March/012200.html (Michael Stone, survey of unintended boot state changes)
- http://lists.laptop.org/pipermail/devel/2008-April/012957.html (Bryan W. Berry, regarding /security)