It is recommended currently to only use fedostree inside a non-essential, disposable virtual machine (or a similar physical machine). While OSTree is carefully engineered to be safe, there is the fact that at the moment the binaries are not GPG signed nor is TLS not provided on the current server.
If you just want to experiment with complete safety, a prebuilt VM image is provided here. It's called fedostree-f20-demo.img.xz. To install, you must first uncompress it with xz -d fedostree-f20-demo.img.xz. Then using e.g. virt-manager, choose "Import existing disk image".
IMPORTANT: This system contains both a traditional Fedora
install and an OSTree root. To try out fedostree, you must (at
present) run through the bls_import step at the GRUB
commandline
Log in to the VM as root - there is no password.
Skip to Booting the system below.
First, you should understand what you'll be doing here. OSTree allows dynamically parallel installing operating systems; (almost) all of its data goes in the new toplevel directory /ostree. At the end you will have a dual boot.
Install the ostree package, and make sure you have ostree 2014.1 or newer (presently in Bodhi updates-testing).
yum install ostree
This bit of one time initialization will both create /ostree for you, as well as /ostree/deploy/fedostree. Only a few directories are created, we haven't really affected the system much yet.
ostree admin os-init fedostree
This step tells OSTree how to find the repository you built on the server. You only need to do this once.
ostree remote add --set=gpg-verify=false fedostree http://rpm-ostree.cloud.fedoraproject.org/repo
We still have only initialized configuration. This next step will just download (but not install) a "minimal" system (just @core):
ostree pull fedostree fedostree/20/x86_64/base/minimal
This step extracts the root filesystem, and updates the bootloader configuration:
ostree admin deploy --os=fedostree --karg-proc-cmdline --karg=selinux=0 fedostree:fedostree/20/x86_64/base/minimal
We need to do some initial setup before we actually boot the system. Copy in the storage configuration:
cp /etc/fstab /ostree/deploy/fedostree/current/etc
And set a root password:
chroot /ostree/deploy/fedostree/current passwd
And there is one final (manual) step: You must copy your system's kernel arguments from /boot/grub2/grub.cfg and add them to /boot/loader/entries/ostree-fedora-0.conf, on the options line. This step may be automated further in the future.
IMPORTANT NOTE: You must use selinux=0 for now.
Your system now contains both a traditional Fedora install and an OSTree root. There is no impact on your installed system except for additional disk space in the /boot/loader and /ostree directories.
At the GRUB prompt, instead of choosing one of the two listed entries, press c to get a command line. Now, enter:
bls_import
Then press Esc. You should have an additional boot menu entry, named ostree:fedora:0. Nagivate to it and press Enter.
To upgrade, run as root
ostree admin upgrade
Although yum is installed, it will operate in read-only mode. Do not attempt to use it at the moment. See the section on the homepage "Development area: Local package assembly".
But with OSTree, it's possible to atomically transition between different complete bootable filesystem trees. Let's now try the standard-docker-io tree:
ostree pull fedostree fedostree/20/x86_64/server/docker-io
If you look at the products.json script you can see this tree contains @core, @standard, and finally docker-io.
Like above, let's now deploy it:
ostree admin deploy --os=fedostree fedostree:fedostree/20/x86_64/server/docker-io systemctl reboot
After you reboot, note two things. First, you'll have two OSTree boot entries. That's because our previous minimal tree is still there. Choose the first OSTree boot entry. When you boot into this tree, note that you'll have a /usr/bin/docker binary. We have successfully atomically transitioned to a new filesystem tree.
Why the triple specification of "fedostree"? First, OSTree allows arbitrarily named "OS"es which have independent /var. You could have two deployments of the same tree, say "feostree-testing" and "fedostree". Second, "fedostree" is the name of the remote. Third, a naming convention for refs includes an OS name prefix at the front, here "fedostree". Some or all of these may be different.