Re: Question on Anaconda rpmostree payload

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> > On Tue, May 28, 2019 at 1:04 PM <jkonecny@xxxxxxxxxx> 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:

> >>  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:

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.

Anaconda-devel-list mailing list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux