Imaging/Side effects: Difference between revisions

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.

@@ Line 1: / Line 1: @@
+'''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. 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. 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 ==
-That said, it also seems that this method of customization is the most appealing and straightforward.
-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:
+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:
+{{Template:Software_Side_Effects_Fixes}}
- # 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:
+To fix loss of collaboration and first boot name prompt on an already cloned target system, start Terminal, enter the command:
- rm -r .sugar
+ rm -rf .sugar .config/gconf/desktop/sugar
+and then shutdown using a double power button press.
-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:
+== 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)
+* [[/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]]

Imaging/Side effects: Difference between revisions

Latest revision as of 05:17, 24 November 2015

Introduction

Procedure

See Also

Navigation menu

Search