Updates olpc

If you have marked a version as sticky and now wish to remove it, or if you are running an old release where the old version is maintained and you wish to free up the disk space occupied by it, you can follow the example Terminal session log shown below. This shows that the build currently running is build Do not purge a build if it is the one running now — things break badly.

The olpc-update script works by transferring only the differences between builds from a USB drive or across the internet link from an updates server. This makes updating easier, mostly quicker, and almost always with less data transfer.

The time efficiency gain is less easy to characterize. It depends on the speed of the internet link, the speed of the updates server, and whether the update was able to use its server-friendly efficiency mode. An olpc-update from to took under 17 minutes.

Several laptops can all be updated in the same way from one source with the same 'hints. The school server integrates with olpc-update. The XS-rsync component accepts software images and makes them available to olpc-update clients. A dated, alternative solution is described at Upgrade Server. Jump to: navigation , search. Navigation menu Personal tools Log in. Namespaces Page Discussion. Views Read View source View history. About the tablet Specifications Buying Help using Support for.

Last edited on , 17 December The first thing to do if you're interested in testing the absolute latest OS images is request a developer key. The key will let you install versions of the system software in development, and different operating systems altogether, including ones created by the community of XO developers and owners.

For example, there are several Linux distributions that run on the XO. When you run it, you must be the root user. And because it is memory hungry, we suggest that you run it when nothing else is running on your XO.

Fedora software comes in packages called RPM 's. If the update has been marked as high-priority, the user will be asked to close applications and reboot his machine immediately. A timer will run that will reboot the machine in 60 minutes if the user does not do so. The high-priority timer can be disabled in the security center; its purpose is merely to provide some extra protection to the youngest users who cannot necessarily be expected to understand or comply with the reboot request.

With the example above, it would be the directory that belonged to the updater's context. The kernel is the only special case to this handling: in the event that a verified update contains an updated kernel, that kernel will be placed into a predetermined place in the underlying filesystem by the security service.

Open Firmware will preferentially boot this newer kernel unless the rollback key combination is depressed during boot. Notice that the update operation has been reduced to a simple state toggle between any two OS images. In so doing, we have satisfied goals 1 and 2. The XO eschews traditional dependency-based approaches to package management, making application upgrades somewhat difficult.

The problem is compounded by the fact that Bitfrost does not permit applications to update themselves in-place, which is a common update method on platforms such as Mac OS X and Windows. When it comes to application updates, we wish to stay true to our goals of security and low-bandwidth updates, but are willing to settle for less fault tolerance as necessitated by the fact that most activities won't be OLPC-written or maintained.

The design should make it possible to have a single tool that can ascertain the existence of updated versions of any currently installed activities, and then fetch and install those updates. It should do so bandwidth-efficiently, such that files that are unchanged between activity versions aren't downloaded as part of the update, and also such that identical resources files packaged by multiple activities are never downloaded more than once, or not at all if they already exist on the system.

A manifest file is added to the bundle format specification. The manifest consists of the filename and strong cryptographic hash of every file in the bundle. Another file is added, called 'origin', that specifies a URL where updated activity bundles may be found, and a public key which will be used to sign such updated bundles. When a global activity update is initiated, the updater enumerates the origins for all installed activities, then probes each one in turn to determine which activities have available updates.

The resulting activity list is the 'available update set'. The most up-to-date bundle for each activity in the set is accessed, and the first several kilobytes downloaded.

Since bundles are simple ZIP files, the downloaded data will contain the ZIP file index which stores byte offsets for the constituent compressed files. The updater then locates the bundle manifest in each index and makes a HTTP request with the respective byte range to each bundle origin.

At the end of this process, the updater has cheaply obtained a set of manifests of the files in all available activity updates. A local database of manifests of all installed activities is kept, pruned only to records for files larger than a set size, e.