Re: Adapting a running installation to OStree: the adventure begins (with a lot of questions)

[Colin Walters <walters verbum org>]

On Mon, May 11, 2015, at 10:01 AM, Leandro Santiago wrote:
> Hello to all, first of all I'd like to congratulate ostree developers
> for this amazing piece of software. I see a of of future on it and I
> hope it will improve a lot the Linux usage, specially on the desktop
> side.

Thanks!

> I have a heavy duty here, which consists in updating a current
> operating system based on a old version of gentoo (from around 2011)
> into a updated system manageable by ostree. I cannot just format this
> system, because it's deployed on thousands of machines to which I do
> not have direct access. So no installation from scratch :-( Perhaps
> though SSH, but not always. So I must upgrade them automatically, in
> runtime and guess what? Atomically :-). But yes, the update can reboot
> the machines normally.

Right.  It's definitely possible - and nondestructively in fact, in that
you could roll out updates to a subset of them, see how it works, and
if you hit problems on specific hardware, use a serial console (assuming
these are servers) to go back to the older bootloader entry.

> My plan is first of all install ostree in this system. As I could not
> compile it in those machines, I copied ostreee executable and
> dependencies from the CentOS atomic (v2015.6) and shipped it with an
> newer version of glibc (2.17, as opposite to the 2.12 from the current
> system), required by the binaries. It seems to work and I could do
> things like creating a bare repository, check log, etc.

That's probably OK for an experiment but not going to be sustainable
long term.  We may introduce new dependencies and you really
don't want to be in a situation where say there's a security issue
and you can't rebuild from source.

I know for this type of use case people want OSTree to be conservative
with dependencies.  What version of e.g. glib2 is in use?

> So I'd like to know if you see any problems with this approach. My
> idea is that, after ostree is running properly, an admin upgrade (or
> deploying another branch) will update the system to a new
> installation, with newer glibc (probably it will be something based on
> CentOS, so I'll be able to use rpm-ostree), simple like this. Am I
> being too ingenuous? Is there any thing which can prevent this
> approach?

You should be able to boot into whatever target system you want,
including the CentOS Atomic Host, or a pre-composed system from
an RPM set of your choice.  (Or if using raw OSTree, you can use
whatever system you want to inject content, including portage -
rpm-ostree just has nicer rpm+OSTree integration, as you might guess).

> I have also changed the directories structure, putting everything into
> /usr and creating the correspondent sym-links. No problems until now.

Right.

> Then I need a way of putting the current tree into a repository, in a
> way it can be replicated to the other machines. That's my first
> problem. I see a commit command, but I don't know where it will get
> the changes from. My first thought is getting it from /, but I can put
> them in a separate directory (when I can chroot manually for changes).
> But no idea about how to proceed.

rpm-ostree always makes a clean chroot and commits that.  It's currently
not significantly more sophisticated than:

yum --installroot=/var/tmp/myos ...
ostree --repo=/path/to/repo commit -b myos /var/tmp/myos

This is the basic start of a package manager <-> ostree integration.

> Then there's the boot manager problem. I found almost nothing about
> how to adapt the boot manager, just an overview (Booting and initramfs
> technology documentation page). I'd like some help regarding this too.
> Is ostree somehow used during the boot phase? I ask that because it
> might prevent me from using the glibc trick above. The GRUB version
> here is quit old (0.97), so I need to know if you think it's suitable
> for usage with ostree. If not, I'm open to suggestions :-)

I filed:
https://bugzilla.gnome.org/show_bug.cgi?id=749246

That's going to block you until GRUB1 support is implemented,
unless you choose the option of installing a new bootloader like
syslinux or grub2 after the deployment.