Imaging/Side effects: Difference between revisions
No edit summary |
No edit summary |
||
Line 27: | Line 27: | ||
* http://lists.laptop.org/pipermail/devel/2009-January/022334.html (A comparison of changes caused by first boot) |
* http://lists.laptop.org/pipermail/devel/2009-January/022334.html (A comparison of changes caused by first boot) |
||
* [[/13.2.1|analysis of filesystem changes in 13.2.1 first boot]] |
* [[/13.2.1|analysis of filesystem changes in 13.2.1 first boot]] |
||
* [[/13.2.6|analysis of filesystem changes in 13.2.6 first boot]] |
Latest revision as of 05:17, 24 November 2015
Imaging laptops is not supported by OLPCA's deployment support team. However, it sometimes works in limited testing.
Introduction
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. The wireless MAC address is cached by the networking system. Hardware-dependent information from the firmware is cached on the laptop after first boot; in particular the keyboard language.
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.
Procedure
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, so that the modifications are cloned. The same actions can be used in both cases:
Stop the display manager. The remainder of these fixes must be typed into a virtual console, or a serial port.
sudo service olpc-dm stop
Delete the ".olpc-configured" files which tell olpc-configure it does not have to run again. This allows some of the files deleted below to be checked for and replaced.
sudo rm -vf /.olpc-configured rm -vf /home/olpc/.olpc-configured
Destroy any saved network connections. Otherwise the cloned laptop cannot connect to the networks the original laptop used.
sudo rm -rvf /etc/NetworkManager/system-connections/*
If SSH was enabled, destroy the SSH host key. Otherwise other systems in your network may report problems connecting to the laptops over SSH.
sudo rm -vf /etc/ssh/ssh_host_rsa_key{,.pub}
Destroy the Sugar journal and settings, forcing a first boot name prompt. Otherwise the cloned laptops won't be able to collaborate using activities, or the wrong names will be shown in Chat,
rm -vrf /home/olpc/.sugar /home/olpc/.config/{g,d}conf /home/olpc/.local/share/telepathy
Destroy the developer key request file. Otherwise the cloned laptops will apply for developer keys using the original laptop serial number and UUID.
rm -vrf /home/.devkey.html
Destroy any saved volume settings, forcing defaults. Otherwise the cloned laptop may start with silent speakers or microphone.
sudo rm -vf /etc/alsa/asound.state
Immediately shutdown, to avoid asound.state being saved:
sync && sudo poweroff -f
To fix loss of collaboration and first boot name prompt on an already cloned target system, start Terminal, enter the command:
rm -rf .sugar .config/gconf/desktop/sugar
and then shutdown using a double power button press.
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)
- http://lists.laptop.org/pipermail/devel/2009-January/022334.html (A comparison of changes caused by first boot)
- analysis of filesystem changes in 13.2.1 first boot
- analysis of filesystem changes in 13.2.6 first boot