Software updating is an essential feature for a connected embedded Linux device, even if it is not required by end users of the device, since responce to newly discovered vulnerabilities in critical Linux software should be as fast as possible. One approach that is widely used in Linux world is using a package manager that will download a package and take care of all the dependencies. Unfortunately, some dependencies and/or conflicts with other packages can not be noticed by repository mantainers. On a PC it would just lead to the necessity to revert the package back to the working version, but on an embedded device with no human operator it is not possible. Theoretically, number of system configurations is an exponent of number of packages one can install, which means that it is practically impossible to make sure that no combination will result in a broken system. In embedded world it is more common to update whole file system image atomically. Thus we can test system configuration before we distribute it to the devices. To allow for atomic switching between file tree versions, dual disk partitioning scheme is used: while Linux is running on a root file system stored in one partition, updates are written to another. When the whole new file system image is downloaded, Linux can switch atomically to it. The main drawback of this approach is that you actually have to download the whole file tree (which can be 100-800MB large in modern devices) for every update. You also can use only half of your available disk space at once.

OSTree was developed by GNOME team for the GNOME Continuous project and was not initialy intended to be used in embedded Linux. It stores all the data in a git-like object repository, but unlike git it is designed to store binary data and can deploy data as hardlinks to the objects in the repository, thus saving significant amount of disk space. Like git it allows to incrementally transfer data between repositories, thus making distribution of software updates possible. OSTree repository contains roughly three kinds of objects: commit, directory and file object. Every commit points to a directory tree and represents a version of file system tree. Commits can then be deployed to a dedicated area and the system can switch to a deployed file tree much the same way it would switch to another partition in dual-partition scheme. Since deploying files just creates hard links to the file objects in the repository, there is no data duplication.

These benefits come at a price: since deployed files are just hardlinks to objects in a repository, they can't be changed, as it would corrupt the repository and other deployed file systems. Therefore, a clear separation should be mantained between read-only data, such as executables and resources and writable data, such as temporary files, logs, configuration stored in /etc. These requirements are not too restrictive, for most use-cases it will just involve putting data in correct directories. An image class that thansforms an OSTree-ignorant file tree to appropriate form and BSP packages for some popular platforms (Raspberry Pi, Porter board, QEMU; minnowboard coming soon) were integrated into Yocto build process and are now available as a separate Yocto layer on Github [https://github.com/advancedtelematic/meta-updater]. It allows you to create OSTree-enabled image and a commit in your OSTree repository as a part of your normal build process (simply 'bitbake your_image').