b69a88b111
The current code checks if /boot/uEnv.txt is a symlink to decice if sysroot requires u-boot support. Why this is bad: There are 2 ways to provide a custom env to u-boot from user space: 1) A compiled binary that is sourced from u-boot. 2) A text file (usually /uEnv.txt) that is imported into env from u-boot. The current OSTree u-boot integration code was designed with the 1st case in mind. Many bootscripts provided by an embedded device vendors expect to find uEnv.txt in the top level directory, it is often hardcoded when building u-boot and is difficult to change later on. Or in other cases it is stored in read-only memory so changing it would require re-flushing boot loader with a new env. So the issue here is that OSTree's and vendor uEnv.txt want to exist and the same path and OSTree would throw away any changes added to /uEnv.txt by user on the next upgrade/deploy. This patch "hides" away the OSTree's env file loader/uEnv.txt from users who are used to edditing uEnv.txt at the top level directory. Now to add OSTree support on such boards you can simply add a custom logic in uEnv.txt that loads ostree env from /loader/uEnv.txt This change is backward compatible with the previous ostree releases and solves the issue described in: https://bugzilla.gnome.org/show_bug.cgi?id=755787 |
||
|---|---|---|
| bsdiff@1edf9f6568 | ||
| build-aux | ||
| doc | ||
| docs-md | ||
| libglnx@e684ef07f0 | ||
| manual-tests | ||
| packaging | ||
| src | ||
| tests | ||
| .gitignore | ||
| .gitmodules | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| GNUmakefile | ||
| Makefile-boot.am | ||
| Makefile-decls.am | ||
| Makefile-libostree-defines.am | ||
| Makefile-libostree.am | ||
| Makefile-ostree.am | ||
| Makefile-otutil.am | ||
| Makefile-switchroot.am | ||
| Makefile-tests.am | ||
| Makefile.am | ||
| README-historical.md | ||
| README.md | ||
| TODO | ||
| autogen.sh | ||
| cfg.mk | ||
| configure.ac | ||
| maint.mk | ||
| ostree.doap | ||
README.md
OSTree
OSTree is a tool that combines a "git-like" model for committing and downloading bootable filesystem trees, along with a layer for deploying them and managing the bootloader configuration.
Traditional package managers (dpkg/rpm) build filesystem trees on the client side. In contrast, the primary focus of OSTree is on replicating trees composed on a server.
Features:
- Atomic upgrades and rollback
- GPG signatures and "pinned TLS" support
- Support for parallel installing more than just 2 bootable roots
- Binary history on the server side
- Introspectable shared library API for build and deployment systems
Projects using OSTree
rpm-ostree is a tool that uses OSTree as a shared library, and supports committing RPMs into an OSTree repository, and deploying them on the client.
Project Atomic uses rpm-ostree to provide a minimal host for Docker formatted Linux containers.
xdg-app uses OSTree for desktop application containers.
GNOME Continuous is a custom build system designed for OSTree, using OpenEmbedded in concert with a custom build system to do continuous delivery from hundreds of git repositories.
Building
Releases are available as GPG signed git tags, and most recent versions support extended validation using git-evtag.
However, in order to build from a git clone, you must update the submodules. If you're packaging OSTree and want a tarball, I recommend using a "recursive git archive" script. There are several available online; this code in OSTree is an example.
Once you have a git clone or recursive archive, building is the same as almost every autotools project:
env NOCONFIGURE=1 ./autogen.sh
./configure --prefix=...
make
make install DESTDIR=/path/to/dest
More documentation
Some more information is available on the old wiki page: https://wiki.gnome.org/Projects/OSTree
The intent is for that wiki page content to be migrated into Markdown in this git repository.
Contributing
See Contributing.