Tiny Core Linux/Reversion: Difference between revisions

From OLPC
Jump to navigation Jump to search
Line 60: Line 60:
=== Using /versions/pristine ===
=== Using /versions/pristine ===


Since a local pristine copy of the build exists on the client laptop, it can be used first in order to reduce the amount of wireless data required:
Since a local pristine copy of the build exists, it can be used first to reduce the data required:
rsync --archive --delete \
rsync --archive --delete \
/mnt/mmcblk0p2/versions/pristine/860 \
/mnt/mmcblk0p2/versions/pristine/860 \
/mnt/mmcblk0p2/versions/run/
/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.
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 ===
=== Using a non-XO server ===
Line 72: Line 72:
=== Using a scripted USB drive ===
=== Using a scripted USB drive ===


(preparing a USB drive using mktinycorexo so that it can be used in a local area network for rapid reversion).
(preparing a USB drive using mktinycorexo so that it can be used in a local area network for rapid reversion ... added to mktinycorexo git).

=== Using rdiff ===

(use rdiff or rsync against block device ... probably won't work very quickly because it must read the client storage fully, whereas the filesystem methods above rely on the filesystem metadata to identify changed files.)

Revision as of 07:27, 17 January 2011

A procedure for reverting an XO to pristine filesystem configuration, as if it had just been installed, using Tiny Core Linux. Journal and all customisation is 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,
  • a wireless or wired network.

Setup for Server

  • install the required build but do not boot into it,
  • boot into Tiny Core Linux,
  • configure wireless:
iwconfig eth0 essid NETWORK
  • install rsync:
su -c 'tce-load -wi rsync' tc
  • mount the filesystems:
mount /mnt/mmcblk0p1
mount /mnt/mmcblk0p2
  • create an rsyncd.conf file:
cat << EOF > /etc/rsyncd.conf
[p1]
        path = /mnt/mmcblk0p1
        uid = root
        gid = root
[p2]
        path = /mnt/mmcblk0p2
        uid = root
        gid = root
  • start rsync daemon:
rsync --daemon
  • identify IP address:
ifconfig eth0

Setup for Clients

  • boot into Tiny Core Linux,
  • configure wireless:
iwconfig eth0 essid NETWORK
  • install rsync:
su -c 'tce-load -wi rsync' tc
(this step may be omitted by rebuilding Tiny Core Linux with rsync already installed)
  • mount the filesystems:
mount /mnt/mmcblk0p1
mount /mnt/mmcblk0p2
  • restore the filesystem to pristine state:
rsync --archive --compress --delete rsync://${IP}/p1 /mnt/mmcblk0p1
rsync --archive --compress --delete rsync://${IP}/p2 /mnt/mmcblk0p2
(where ${IP} is the IP address or host name of the server)
  • reboot:
reboot

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)

Using a scripted USB drive

(preparing a USB drive using mktinycorexo so that it can be used in a local area network for rapid reversion ... added to mktinycorexo git).

Using rdiff

(use rdiff or rsync against block device ... probably won't work very quickly because it must read the client storage fully, whereas the filesystem methods above rely on the filesystem metadata to identify changed files.)