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