Tiny Core Linux/Reversion: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
 
(19 intermediate revisions by the same user not shown)
Line 1: Line 1:
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.
A procedure for reverting an XO with OLPC OS to pristine filesystem configuration, as if it had just been installed, using Tiny Core Linux.

On the reverted laptops, identity, registration, Journal, post-install activities, and all customisations are lost.

On the pristine laptop, customisations are kept, and passed to the reverted laptops.

Note: works for XO-1.5, XO-1.75, and XO-4, reverting the internal storage. For XO-1, requires an SD card, and reverts the filesystem on the SD card, leaving the internal storage unchanged.


== Requirements ==
== Requirements ==
Line 5: Line 11:
* an XO to act as a server,
* an XO to act as a server,
* any number of XO to act as client to undergo reversion,
* any number of XO to act as client to undergo reversion,
* a Tiny Core Linux bootable USB drive,
* a Tiny Core Linux bootable USB drive (tested with the 2014-06-17 build, git hash 9a9e70c),
* a wireless or wired network.
* a wireless or wired network.


== Setup for Server ==
== Setup for Server ==


* install the required build but do not boot into it,
* install the required operating system build but do not boot into it, (or, having booted into it, follow the [[Imaging/Side_effects|extra steps to fix side-effects of cloning]]),
* boot into Tiny Core Linux,
* boot into Tiny Core Linux,
* remove the USB drive,
* configure wireless:
* [[Tiny Core Linux#Configure wireless|configure wireless]],
iwconfig eth0 essid NETWORK
* start the server:
* install rsync:
xo-server
su -c 'tce-load -wi rsync' tc
* mount the filesystems:
* note the displayed IP address.
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 ==
== Setup for Clients ==


* boot into Tiny Core Linux,
* boot into Tiny Core Linux,
* remove the USB drive,
* configure wireless:
* [[Tiny Core Linux#Configure wireless|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:
* restore the filesystem to pristine state:
xo-revert ${IP}
rsync --archive --compress --delete rsync://${IP}/p1 /mnt/mmcblk0p1
:(where ${IP} is the IP address or host name of the server as displayed above)
rsync --archive --compress --delete rsync://${IP}/p2 /mnt/mmcblk0p2
:(where ${IP} is the IP address or host name of the server)
* reboot:
* reboot:
reboot
reboot
<!--
The {{Code|xo-revert}} can be interrupted and restarted without losing any progress. This requires manual ''umount''. To display progress, add the {{Code|--verbose}} flag ''after'' the IP address. -->

== 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 method 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 ==
== Timings ==

Reversion of three XO-4 that had been booted into 13.2.1 cost about 50s <!-- 52.16s 50.8s 34.72s 36.53s 34.28 --> each as compared to 7m using fs-update. This increased to 1m 42s when done all at once, due to network and server contention.


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.
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.

Reversion of an XO-1 SD card that had been booted once into 13.2.1 cost 1m 20s compared to a substantial time using fs-update.


== Optimisation ==
== Optimisation ==
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.
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 ===


An XO as a server lacks memory and bandwidth. A larger server can be used.
(placing the rsync daemon on a server system)

* copy the filesystem from the pristine laptop to a server, by running these commands on the server:
sudo mkdir /tmp/p1 /tmp/p2
sudo rsync -avP rsync://$IP/p1 /tmp/p1
sudo rsync -avP rsync://$IP/p2 /tmp/p2
* set up an rsyncd.conf or merge with an existing rsyncd.conf,
cat << EOF > /tmp/rsyncd.conf
[p1]
path = /tmp/p1
uid = root
gid = root
[p2]
path = /tmp/p2
uid = root
gid = root
EOF
* if rsync is not running, start the server
sudo rsync --daemon --config /tmp/rsyncd.conf
* note the IP address of the server,
* use ''xo-revert'' on each laptop, specifying the IP address of the server.

== Not for Upgrades ==

Do not use this technique for operating system upgrades where the change is significant; especially if the operating system build number changes. 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 storage; the wireless is mostly idle, transferring only 993 MB over the three hours.

== Why not XO-1? ==

Almost too slow. A revert of 13.2.6 from first boot to not yet booted state costs 2m 55s. Scripts for XO-1 have been recently committed, see http://dev.laptop.org/git/users/quozl/mktinycorexo/commit/?id=fa73fb56a22937f7c15d8cdc5938f728c94b5def


== Hard links ==
=== Using a scripted USB drive ===


The reversion method does not retain hard links, and so may grow a filesystem. Adding --hard-links to the command avoids the problem, but increases processing time.
(preparing a USB drive using mktinycorexo so that it can be used in a local area network for rapid reversion).

Latest revision as of 05:09, 24 November 2015

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

On the reverted laptops, identity, registration, Journal, post-install activities, and all customisations are lost.

On the pristine laptop, customisations are kept, and passed to the reverted laptops.

Note: works for XO-1.5, XO-1.75, and XO-4, reverting the internal storage. For XO-1, requires an SD card, and reverts the filesystem on the SD card, leaving the internal storage unchanged.

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 with the 2014-06-17 build, git hash 9a9e70c),
  • a wireless or wired network.

Setup for Server

xo-server
  • note the displayed IP address.

Setup for Clients

  • boot into Tiny Core Linux,
  • remove the USB drive,
  • configure wireless,
  • restore the filesystem to pristine state:
xo-revert ${IP}
(where ${IP} is the IP address or host name of the server as displayed above)
  • 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 method 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-4 that had been booted into 13.2.1 cost about 50s each as compared to 7m using fs-update. This increased to 1m 42s when done all at once, due to network and server contention.

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.

Reversion of an XO-1 SD card that had been booted once into 13.2.1 cost 1m 20s compared to a substantial time using fs-update.

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

An XO as a server lacks memory and bandwidth. A larger server can be used.

  • copy the filesystem from the pristine laptop to a server, by running these commands on the server:
sudo mkdir /tmp/p1 /tmp/p2
sudo rsync -avP rsync://$IP/p1 /tmp/p1
sudo rsync -avP rsync://$IP/p2 /tmp/p2
  • set up an rsyncd.conf or merge with an existing rsyncd.conf,
cat << EOF > /tmp/rsyncd.conf
[p1]
        path = /tmp/p1
        uid = root
        gid = root
[p2]
        path = /tmp/p2
        uid = root
        gid = root
EOF
  • if rsync is not running, start the server
sudo rsync --daemon --config /tmp/rsyncd.conf
  • note the IP address of the server,
  • use xo-revert on each laptop, specifying the IP address of the server.

Not for Upgrades

Do not use this technique for operating system upgrades where the change is significant; especially if the operating system build number changes. 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 storage; the wireless is mostly idle, transferring only 993 MB over the three hours.

Why not XO-1?

Almost too slow. A revert of 13.2.6 from first boot to not yet booted state costs 2m 55s. Scripts for XO-1 have been recently committed, see http://dev.laptop.org/git/users/quozl/mktinycorexo/commit/?id=fa73fb56a22937f7c15d8cdc5938f728c94b5def

Hard links

The reversion method does not retain hard links, and so may grow a filesystem. Adding --hard-links to the command avoids the problem, but increases processing time.