GNOME.org
 

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

Answering myself: The text is a bit outdated. I'm trying to use it but
need to adapt some parts. I'm not sure if it will work :-(

On 12 May 2015 at 15:07, Leandro Santiago <leandrosansilva gmail com> wrote:

Oh, I have just found this document
https://wiki.gnome.org/Projects/OSTree/UsingOnArch, that although is
about archlinux, can be useful because explains how to change manually
the boot process :-) Is that text still valid?

On 12 May 2015 at 14:00, Leandro Santiago <leandrosansilva gmail com> wrote:

On 11 May 2015 at 23:58, Colin Walters <walters verbum org> wrote:

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!

You are welcome, and thank you again for the quick reply :-)



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.
My idea was that this copy of ostree would stay only in the first tree, and as soon the system was 
updated, it would have "normal" ostree installation and the previous one would not be used anymore 
(unless I decided to go back to it). My fear is that if the ostree executable or library is used early in 
the boot (like in initramfs) I may have some problems.
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?

The current system uses 2.28 but ostree is using 2.40.



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.

That's easier than I thought :-)



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.

As an initial setup, is it possible to setup grub (and the rest of
boot related things) manually? Does ostree put something inside the
initramfs image? I ask that because we currently use a custom
initramfs creation process, which may need to changed. I saw I need to
add a ostree= parameter to initrd. Is there anything else done inside
initrd? And thank you for filing the bug report. If implemented it
will be very useful :-) With that I would be able to boot from a
ostree tree and update the installation with grub2 and I then call
grub2-install, replacing the old one. Can something like this work?
Will ostree manage the /boot directory too?

_______________________________________________
ostree-list mailing list
ostree-list gnome org
https://mail.gnome.org/mailman/listinfo/ostree-list




--
Sent from my mind




--
Sent from my mind




-- 
Sent from my mind
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]