Hi Colin,
On Thu, May 30, 2019 at 2:47 PM Colin Walters <walters@xxxxxxxxxx> wrote:
> > 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:
https://github.com/storaged-project/blivet/commit/5b39c90ae582a8fb008c3633954a33b58394802c
https://github.com/rhinstaller/anaconda/commit/0bbc9adf41b33062bbbfe478b3373a3404de21aa
> >> 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/664ef7b43f9102aa9332d0db5b7d13f8ece436f0
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:
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
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
