Tiny Core Linux/Reversion

A procedure for reverting an XO with OLPC OS to pristine filesystem configuration, as if it had just been installed, using Tiny Core Linux.

Identity, registration, Journal, post-install activities, and all customisations are lost.

Requirements

• an XO to act as a server,
• any number of XO to act as client to undergo reversion,
• a Tiny Core Linux bootable USB drive (tested on microcore-3.4-xo-2011-01-18.tar),
• a wireless or wired network.

Setup for Server

• install the required operating system build but do not boot into it, (or, having booted into it, follow the extra steps to fix side-effects of cloning),
• boot into Tiny Core Linux,
• remove the USB drive,
• configure wireless:

iwconfig eth0 essid NETWORK

• start the server:

xo-server

• note the displayed IP address.

Setup for Clients

• boot into Tiny Core Linux,
• remove the USB drive,
• configure wireless:

iwconfig eth0 essid NETWORK

• restore the filesystem to pristine state:

xo-revert ${IP}

(where ${IP} is the IP address or host name of the server)

• reboot:

reboot

Ad-hoc Wireless

The above procedure depends on a wireless access point. If one is not available, an ad-hoc network may be set up, but this requires more care to set unique IP addresses. In place of the iwconfig command above:

iwconfig eth0 mode ad-hoc channel 1 essid pq
ifconfig eth0 1.1.1.1

Change the last digit for each laptop added to the ad-hoc network.

The additional time cost of doing this begins to approach the cost of fs-update, so investment in a remastered USB drive with ad-hoc scripts may be more appropriate.

Timings

Reversion of three XO-1.5 that had been booted once into 10.1.3 os860 cost 1m 45s each as compared to 17m using fs-update and over half an hour using NANDblaster.

Optimisation

Using /versions/pristine

Since a local pristine copy of the build exists, it can be used first to reduce the data required:

rsync --archive --delete \
/mnt/mmcblk0p2/versions/pristine/860 \
/mnt/mmcblk0p2/versions/run/

However, since /home/olpc is not present in this pristine copy, the full rsync is still required. In the test case, the local copy cost 16s, followed by the full rsync at cost of 1m, a saving of about 15s.

Using a non-XO server

(placing the rsync daemon on a server system)

Not for Upgrades

Do not use this technique for operating system upgrades where the change is significant; it is faster to use fs-update. As an example, 10.1.2 to 10.1.3 takes three hours, because of the amount of filesystem change. The delay is due to the filesystem writes to the internal SD card; the wireless is mostly idle, transferring only 993 MB over the three hours.