fedora-ostree 2013.1



fedora-ostree is at the moment a script to take content generated via
rpm/yum and import it into an OSTree repository.  I referred to this
project before; it now is in a "proof of concept" phase - it boots
cleanly in a minimal install.

This is the incredibly lame script to generate a tarball:
http://fedorapeople.org/cgit/walters/public_git/fedora-ostree.git/tag/?id=v2013.1
which then can be imported into an ostree repository like so:

$ ostree --repo=/src/build/ostbuild/work/repo/ commit -b fedora/19/x86_64-minimal -s Import 
--tree=tar=/home/walters/fedora-ostree-19.tar.gz 

Then, at the moment, I suggest trying this out inside the gnome-ostree
VM.  Note you will need to download a new image from
http://build.gnome.org/ostree/buildmaster/images/z/current/ if you
haven't since ostree 2013.3.

Execute these steps as root:
$ ostree admin os-init fedora
$ ostree remote add fedora http://fedorapeople.org/~walters/fedora-ostree-f19-x86_64/repo/
$ ostree pull fedora
$ ostree admin deploy --os=fedora fedora:fedora/19/x86_64-minimal

To see what's going on:
$ ostree admin status

Now, a few one time setup bits for the new tree:
cp /etc/fstab /ostree/deploy/fedora/current/etc/fstab
chroot /ostree/deploy/fedora/current/
passwd -d root
(control-d)

Then reboot.  You should be in something that resembles Fedora except:

1) /usr is readonly
2) yum/rpm will fail

Ok, #2 makes it kind of distant from Fedora.  To make rpm work
is...well, a lot of work.  We need to move the rpm database to /usr, for
a start.

Note that you still have gnome-ostree inside the VM!  Just reboot again
and specify ostree:gnome-ostree:1 at the syslinux prompt, and you'll be
back.

Caveats aside, I think even this embryonic state is potentially useful
if it were polished a little bit more.  For example, some people have
expressed interest in using OSTree inside the datacenter - in this
model, you do whatever you want with packages on a build server, which
then gets put into an OSTree repository and can be efficiently
replicated[1] to all servers without doing client-side dependency
resolution, you have atomic upgrades, etc.


[1] Ok, relatively efficiently depending on the update; once we have
    deltas we'll be easily much more efficient than yum+deltarpm.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]