GNOME.org
 

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

Hello again. It seems the information in the link I provided
(https://wiki.gnome.org/Projects/OSTree/UsingOnArch) is a bit
outdated.

I am following it but doing some adaptations (I am no longer trying to
adapt my current and old operating system, I starting adapting a clean
archlinux first, which will be the base of the new system, and I will
take care of the migration later, and first I need to know ostree
better).

First of all, I have a remote repository (--mode=archive-z2), created
after a clean and recent archlinux (2015.05.01) instalation. It has
only one ref (refs/heads/archlinux/initial) and its located in
http://server:8080/repo/. It was added under the name "origin" in the
client.

I pulled the code from my current installation with:

# ostree pull origin archlinux/initial # Yeah, I know the ref initial
makes no sense, it's just an experiment :-0

Then now I have to deploy it. That's when things get obscure.

If I try to call:

# ostree admin deploy archlinux/initial

Ostree will complain it's is not booted from ostree, which os true.
Then I noticed it may accepts an --os= flag. In my case, I wish it to
be archlinux. As there is no archlinux on ostree, I initialize it
first (should I do that?, that's not in the link):

# ostree admin os-init archlinux

It created the directory /ostree/deploy/archlinux. Sounds good.

Then I try to deploy again:

# ostree admin deploy --os=archlinux archlinux/initial
Error: Failed to find boot/vmlinuz-<CHECKSUM> in /

Then... I got stuck :-(

I am doing this process into a chrooted envirnonment (with
arch-chroot).  I tried to copy my current vmlinuz to
/boot/vmlinuz-$CHECKSUM (CHECKSUM comes from ostree log
archlinux/initial), but it didn't work either...

Is there any updated reference of the "transition" process? If not,
I'll be happy to write some if anyone could provide any clue about
what to do next :-)


On 12 May 2015 at 16:41, Leandro Santiago <leandrosansilva gmail com> wrote:

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




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