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 jkonecny@redhat.com 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
On Tue, May 28, 2019 at 1:04 PM jkonecny@redhat.com 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.
Hi Colin,
On Thu, May 30, 2019 at 2:47 PM Colin Walters walters@verbum.org wrote:
On Tue, May 28, 2019 at 1:04 PM jkonecny@redhat.com 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 Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.fedoraproject.org