Re: Question on Anaconda rpmostree payload

Good point.
Adding Anaconda devel list. The community could be interesting on this.
Jirka
On Tue, 2019-05-28 at 14:29 -0400, Colin Walters wrote:
> Adding Dusty and Jonathan.
>
> Can we take this thread to anaconda-devel@ ?  No reason not to
> discuss in public AFAICS, and this way conversation is archived for
> historical purposes, etc.
>
> On Tue, May 28, 2019 at 1:04 PM  wrote:
> > Hello,
> >
> > We are doing bigger rewrite of the Anaconda and we have a problem
> > with
> >
> > the moving sysroot of rpmostree payload. As you know the payload
> > more
> >
> > then we and most of all you know rpmostree I wanted to ask you
> > about
> >
> > the solution.
> >
> > Right now the sysroot of the rpmostree is changing during the
> >
> > installation. The code for the sysroot handling changed and we
> > would
> >
> > like to simplify the logic, by having the sysroot on static place
> > all
> >
> > the time.
> >
> > From the commit message I know there is a deployment and physical
> > root.
> >
> > The problem is however that you have to change to the other during
> > the
> >
> > installation. We would like to avoid this.
> >
> > If we can avoid changing the sysroot that would be best but in
> > other
> >
> > case I came with an idea of a bind mount. So when the mount is not
> > in
> >
> > the "correct" place we can bind mount the other folder there.
> >
> > However, that could complicate other things.
> >
> > Could you please give a suggestion for this?
> >
> > Thanks,
> >
> > Jirka

Question on Anaconda rpmostree payload

[Colin Walters]

> > On Tue, May 28, 2019 at 1:04 PM  wrote:
> > > We are doing bigger rewrite of the Anaconda and we have a problem with
> > >  the moving sysroot of rpmostree payload.

Is there any more background on this?  Is there an outstanding pull request?
> As you know the payload more
> > > then we and most of all you know rpmostree I wanted to ask you about
> > >  the solution.
> > >
> > > Right now the sysroot of the rpmostree is changing during the
> > >  installation. The code for the sysroot handling changed and we would
> > >  like to simplify the logic, by having the sysroot on static place all
> > >  the time.
> > > > From the commit message I know there is a deployment and physical root.
> > >
> > > The problem is however that you have to change to the other during the
> > >  installation. We would like to avoid this.

This is a complex topic.  I am not sure we can entirely avoid the code having
to support both.

Ultimately, the libostree code is designed to support being invoked from *outside* the system (as anaconda does), as well as *inside* the system (like `rpm-ostree upgrade` does in a booted system).  This is all of course quite symmetrical with yum's --installroot model, except ostree needs to handle more things (e.g. the bootloader config is owned by it).

These original commits are relevant:
https://github.com/storaged-project/blivet/commit/5b39c90ae582a8fb008c363395...
https://github.com/rhinstaller/anaconda/commit/0bbc9adf41b33062bbbfe478b3373...
> > > If we can avoid changing the sysroot that would be best but in other
> > >  case I came with an idea of a bind mount. So when the mount is not in
> > >  the "correct" place we can bind mount the other folder there.
> > >  However, that could complicate other things.

I want to say that in the past we did a bind mount and switched to moving...I had thought the change was in lorax but I can't find it now.  (...a few more minutes pass with some invocations of `git log --grep=ostree` and `git log --grep=mount`...).

Ah ok, see:
https://github.com/rhinstaller/anaconda/commit/664ef7b43f9102aa9332d0db5b7d1...

Are you thinking we basically invert things and basically do mount --rbind /mnt/sysroot/...deploy/$checksum ?
The main issue with that is that the bootloader writing happens *after* kickstart processing and the bootloader code in rpmostreepayload assumes that it's looking at the physical root right now, but that may not be hard to change.

Question on Anaconda rpmostree payload

[Vendula Poncova]

Hi Colin,

On Thu, May 30, 2019 at 2:47 PM Colin Walters  wrote:
> > > On Tue, May 28, 2019 at 1:04 PM  wrote:
> > > > We are doing bigger rewrite of the Anaconda and we have a problem
>
> with
> > > > the moving sysroot of rpmostree payload.
>
> Is there any more background on this?  Is there an outstanding pull
> request?

the problem is that we need to somehow inform our DBus modules about the
current path to the system root and that we will have to somehow monitor
whether a DBus module doesn't want to change this path. We could write a
DBus support for that, but we don't think that it is a good idea, because
we don't want to advertise this option.
> > As you know the payload more
> > > > then we and most of all you know rpmostree I wanted to ask you about
> > > >  the solution.
> > > >
> > > > Right now the sysroot of the rpmostree is changing during the
> > > >  installation. The code for the sysroot handling changed and we would
> > > >  like to simplify the logic, by having the sysroot on static place all
> > > >  the time.
> > > > > From the commit message I know there is a deployment and physical
>
> root.
> > > > The problem is however that you have to change to the other during
>
> the
> > > > installation. We would like to avoid this.
>
> This is a complex topic.  I am not sure we can entirely avoid the code
> having
> to support both.
>
> Ultimately, the libostree code is designed to support being invoked from
> *outside* the system (as anaconda does), as well as *inside* the system
> (like `rpm-ostree upgrade` does in a booted system).  This is all of course
> quite symmetrical with yum's --installroot model, except ostree needs to
> handle more things (e.g. the bootloader config is owned by it).
>
> These original commits are relevant:
>
> https://github.com/storaged-project/blivet/commit/5b39c90ae582a8fb008c363395...
>
> https://github.com/rhinstaller/anaconda/commit/0bbc9adf41b33062bbbfe478b3373...
> > > > If we can avoid changing the sysroot that would be best but in other
> > > >  case I came with an idea of a bind mount. So when the mount is not in
> > > >  the "correct" place we can bind mount the other folder there.
> > > >  However, that could complicate other things.
>
> I want to say that in the past we did a bind mount and switched to
> moving...I had thought the change was in lorax but I can't find it now.
> (...a few more minutes pass with some invocations of `git log
> --grep=ostree` and `git log --grep=mount`...).
>
> Ah ok, see:
>
> https://github.com/rhinstaller/anaconda/commit/664ef7b43f9102aa9332d0db5b7d1...
>
> Are you thinking we basically invert things and basically do mount --rbind
> /mnt/sysroot/...deploy/$checksum ?
> The main issue with that is that the bootloader writing happens *after*
> kickstart processing and the bootloader code in rpmostreepayload assumes
> that it's looking at the physical root right now, but that may not be hard
> to change.

Thanks for the info and the links. It was very helpful.

I think that we have found a solution that might work. Basically, there
will be two mount points: /mnt/sysimage for the physical root and
/mnt/sysroot for the system root. Then it is simple to remount /mnt/sysroot
withount changing /mnt/sysimage.

This idea is already implemented at:
https://github.com/rhinstaller/anaconda/pull/1996

I have tested several use cases and it seems to work fine so far.

What do you think about it?

Vendy
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list