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
_______________________________________________
ostree-list mailing list
ostree-list gnome org
https://mail.gnome.org/mailman/listinfo/ostree-list