Re: Question on Anaconda rpmostree payload
Vendula Poncova <[email protected]> Thu, 6 Jun 2019 19:59:49 +0200
| Newsgroups | gmane.linux.redhat.anaconda.devel |
|---|---|
| Message-ID | <CAAmygTR-nYQeoQbhK9=GzkfBRB0X_-9nUPfOrEWJpXw0Lr-7Tg@mail.gmail.com> |
--===============1035774889640831406== Content-Type: multipart/alternative; boundary="0000000000008a638a058aab7b14" --0000000000008a638a058aab7b14 Content-Type: text/plain; charset="UTF-8" Hi Colin, On Thu, May 30, 2019 at 2:47 PM Colin Walters <[email protected]> wrote: > > > On Tue, May 28, 2019 at 1:04 PM <[email protected]> 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 > [email protected] > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > --0000000000008a638a058aab7b14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Hi Colin,</div><div dir=3D"ltr"><br></div= ><div dir=3D"ltr">On Thu, May 30, 2019 at 2:47 PM Colin Walters <<a href= =3D"mailto:[email protected]">[email protected]</a>> wrote:<br></div><= div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin= :0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= >> > On Tue, May 28, 2019 at 1:04 PM <<a href=3D"mailto:jkonecny@r= edhat.com" target=3D"_blank">[email protected]</a>> wrote:<br> > <br> > >>=C2=A0 We are doing bigger rewrite of the Anaconda and we have= a problem with<br> > >>=C2=A0 the moving sysroot of rpmostree payload.<br> <br> Is there any more background on this?=C2=A0 Is there an outstanding pull re= quest?<br> <br></blockquote><div><br></div><div></div>the problem is that we need to s= omehow inform our DBus modules about the current path to the system root an= d that we will have to somehow monitor whether a DBus module doesn't wa= nt to change this path. We could write a DBus support for that, but we don&= #39;t think that it is a good idea, because we don't want to advertise = this option.<br>=C2=A0<blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> >=C2=A0 As you know the payload more<br> > >>=C2=A0 then we and most of all you know rpmostree I wanted to = ask you about<br> > >>=C2=A0 the solution.<br> > >> <br> > >>=C2=A0 Right now the sysroot of the rpmostree is changing duri= ng the<br> > >>=C2=A0 installation. The code for the sysroot handling changed= and we would<br> > >>=C2=A0 like to simplify the logic, by having the sysroot on st= atic place all<br> > >>=C2=A0 the time.<br> > >> <br> > >>=C2=A0 >From the commit message I know there is a deploymen= t and physical root.<br> > >>=C2=A0 The problem is however that you have to change to the o= ther during the<br> > >>=C2=A0 installation. We would like to avoid this.<br> <br> This is a complex topic.=C2=A0 I am not sure we can entirely avoid the code= having<br> to support both.<br> <br> Ultimately, the libostree code is designed to support being invoked from *o= utside* the system (as anaconda does), as well as *inside* the system (like= `rpm-ostree upgrade` does in a booted system).=C2=A0 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).<br> <br> These original commits are relevant:<br> <a href=3D"https://github.com/storaged-project/blivet/commit/5b39c90ae582a8= fb008c3633954a33b58394802c" rel=3D"noreferrer" target=3D"_blank">https://gi= thub.com/storaged-project/blivet/commit/5b39c90ae582a8fb008c3633954a33b5839= 4802c</a><br> <a href=3D"https://github.com/rhinstaller/anaconda/commit/0bbc9adf41b33062b= bbfe478b3373a3404de21aa" rel=3D"noreferrer" target=3D"_blank">https://githu= b.com/rhinstaller/anaconda/commit/0bbc9adf41b33062bbbfe478b3373a3404de21aa<= /a><br> <br> > >>=C2=A0 If we can avoid changing the sysroot that would be best= but in other<br> > >>=C2=A0 case I came with an idea of a bind mount. So when the m= ount is not in<br> > >>=C2=A0 the "correct" place we can bind mount the oth= er folder there.<br> > >>=C2=A0 However, that could complicate other things.<br> <br> 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.=C2=A0 (= ...a few more minutes pass with some invocations of `git log --grep=3Dostre= e` and `git log --grep=3Dmount`...).<br> <br> Ah ok, see:<br> <a href=3D"https://github.com/rhinstaller/anaconda/commit/664ef7b43f9102aa9= 332d0db5b7d13f8ece436f0" rel=3D"noreferrer" target=3D"_blank">https://githu= b.com/rhinstaller/anaconda/commit/664ef7b43f9102aa9332d0db5b7d13f8ece436f0<= /a><br> <br> Are you thinking we basically invert things and basically do mount --rbind = /mnt/sysroot/...deploy/$checksum ?<br> The main issue with that is that the bootloader writing happens *after* kic= kstart processing and the bootloader code in rpmostreepayload assumes that = it's looking at the physical root right now, but that may not be hard t= o change.<br> <br></blockquote><div><br></div><div>Thanks for the info and the links. It = was very helpful.</div><br><div>I think that we have found a solution that = might work. Basically, there will be two mount points: /mnt/sysimage for th= e physical root and /mnt/sysroot for the system root. Then it is simple to = remount /mnt/sysroot withount changing /mnt/sysimage.</div><div><br></div><= div>This idea is already implemented at:<br></div><div><a href=3D"https://g= ithub.com/rhinstaller/anaconda/pull/1996">https://github.com/rhinstaller/an= aconda/pull/1996</a></div><div><br></div><div>I have tested several use cas= es and it seems to work fine so far.</div><div><br></div><div>What do you t= hink about it?</div><div><br></div><div>Vendy<br></div><div>=C2=A0</div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex"> _______________________________________________<br> Anaconda-devel-list mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">Anacond= [email protected]</a><br> <a href=3D"https://www.redhat.com/mailman/listinfo/anaconda-devel-list" rel= =3D"noreferrer" target=3D"_blank">https://www.redhat.com/mailman/listinfo/a= naconda-devel-list</a><br> </blockquote></div></div> --0000000000008a638a058aab7b14-- --===============1035774889640831406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Anaconda-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/anaconda-devel-list --===============1035774889640831406==--