Bug 2092012

Hi Luca,

Thanks for reporting this issue! The check in %pre and %posstrans is supposed to prevent the code that automatically updates the kernel crashkernel cmdline parameter from being executed as this feature doesn't support ostree. `/run/ostree-booted` seems to imply the ostreem system has been booted and is running, am I correct?

Another question is will package upgrade happens during compose time? Current the code will not be executed when  [ $1 == 2 ] i.e. during package upgrade.

> `/run/ostree-booted` seems to imply the ostree system has been booted and is running, am I correct?

Generally speaking yes, it is the most stable way to signal/check that a system has been booted in ostree-style.
It is also used by rpm-ostree at compose/install time in the sandboxed environment where scriptlets run, in order to signal that the package is being installed/composed into an ostree commit (i.e. not directly on a live system).
See https://github.com/coreos/rpm-ostree/blob/8ddf5f40d9cbbd9d3668cc75b703316e0a89ab11/src/libpriv/rpmostree-scripts.cxx#L350-L353 for reference.

> Another question is will package upgrade happens during compose time? Current the code will not be executed when  [ $1 == 2 ] i.e. during package upgrade.

I think that's not the case (normally).
I spotted a `kdumpctl` error at compose time, and I guess that was coming from the %posstrans logic indeed.
While looking into the specfile I noticed there was another similar check in %pre logic.
It would be good to fix both at once while at it, even if only one is actually triggering.

(In reply to Luca BRUNO from comment #3)
> > `/run/ostree-booted` seems to imply the ostree system has been booted and is running, am I correct?
> 
> Generally speaking yes, it is the most stable way to signal/check that a
> system has been booted in ostree-style.
> It is also used by rpm-ostree at compose/install time in the sandboxed
> environment where scriptlets run, in order to signal that the package is
> being installed/composed into an ostree commit (i.e. not directly on a live
> system).
> See
> https://github.com/coreos/rpm-ostree/blob/
> 8ddf5f40d9cbbd9d3668cc75b703316e0a89ab11/src/libpriv/rpmostree-scripts.
> cxx#L350-L353 for reference.

Thanks for the explanation! Btw, previously I used osbuild to create OSTree commits following
https://www.osbuild.org/news/2020-06-01-how-to-ostree-anaconda.html. Does /run/ostree-booted also exist during this type of compose?


> 
> > Another question is will package upgrade happens during compose time? Current the code will not be executed when  [ $1 == 2 ] i.e. during package upgrade.
> 
> I think that's not the case (normally).
> I spotted a `kdumpctl` error at compose time, and I guess that was coming
> from the %posstrans logic indeed.
> While looking into the specfile I noticed there was another similar check in
> %pre logic.
> It would be good to fix both at once while at it, even if only one is
> actually triggering.

Oh, I forgot RPM posttrans scriptlet doesn't provide way to distinguish between install and upgrade ([ $1 == 1] applies to both install and upgrade). That's why there is only  an error from %posttrans.

> Does /run/ostree-booted also exist during this type of compose?

That depends on how osbuild runs those scriptlets, but no I think that right now they aren't sandboxed in the same way and they don't see that file (at least right now).
But in that case too checking the kernel command-line is not useful, as it won't tell anything about the target system being composed.

(In reply to Coiby from comment #4)

> Thanks for the explanation! Btw, previously I used osbuild to create OSTree
> commits following
> https://www.osbuild.org/news/2020-06-01-how-to-ostree-anaconda.html. Does
> /run/ostree-booted also exist during this type of compose?

osbuild currently does not set `/run/ostree-booted`, but we totally could. You can detect running osbuild via the `container` environment variable. kdumpctl already does so:

https://src.fedoraproject.org/rpms/kexec-tools/blob/f36/f/kdumpctl#_1647

(In reply to Luca BRUNO from comment #5)
> > Does /run/ostree-booted also exist during this type of compose?
> 
> That depends on how osbuild runs those scriptlets, but no I think that right
> now they aren't sandboxed in the same way and they don't see that file (at
> least right now).
> But in that case too checking the kernel command-line is not useful, as it
> won't tell anything about the target system being composed.

Thanks for the explanation! Christian's comment reminds me of another task which is kexec-tools tries to set up the kernel crashkernel parameter when the system is installed. For ananaconda, we have a dedicated addon to do that.  For osbuild, it's done in the posttrans scriptlet.   Does ostree want kexec-tools to set up the kernel crashkernel parameter? If yes, can we do it when packages are installed/composed into an ostree commit?

(In reply to Christian Kellner from comment #6)
> (In reply to Coiby from comment #4)
> 
> > Thanks for the explanation! Btw, previously I used osbuild to create OSTree
> > commits following
> > https://www.osbuild.org/news/2020-06-01-how-to-ostree-anaconda.html. Does
> > /run/ostree-booted also exist during this type of compose?
> 
> osbuild currently does not set `/run/ostree-booted`, but we totally could.
> You can detect running osbuild via the `container` environment variable.
> kdumpctl already does so:
> 
> https://src.fedoraproject.org/rpms/kexec-tools/blob/f36/f/kdumpctl#_1647

Yes, kdumpctl have already made use of the bwrap-osbuild environmental variable to to set up crashkernel for osbuild. Note the use case is different from ostree for which kexec-tools tries to disable the feature of auto-updating crashkernel as it currently doesn't support  ostree. 

Btw, when implementing the feature of setting up crashkernel for osbuild, I haven't took the case of osbuild+ostree as documented in https://www.osbuild.org/news/2020-06-01-how-to-ostree-anaconda.html into consideration into consideration. Do you know if current kexec-tools could work  for the osbuild+ostree+anaconda case?

> Does ostree want kexec-tools to set up the kernel crashkernel parameter? If yes, can we do it when packages are installed/composed into an ostree commit?

During composes on rpm-ostree based systems, RPMs can not set kernel arguments. The kexec-tools should thus skip setting kernel arguments during scriptlets by checking for the presence of `/run/ostree-booted`.

Note that osbuild does not currently use rpm-ostree to do the compose and thus behaves a little bit differently from other rpm-ostree based variants of Fedora such as CoreOS, Silverblue, etc.

(In reply to Timothée Ravier from comment #9)
> > Does ostree want kexec-tools to set up the kernel crashkernel parameter? If yes, can we do it when packages are installed/composed into an ostree commit?
> 
> During composes on rpm-ostree based systems, RPMs can not set kernel
> arguments. The kexec-tools should thus skip setting kernel arguments during
> scriptlets by checking for the presence of `/run/ostree-booted`.
> 
> Note that osbuild does not currently use rpm-ostree to do the compose and
> thus behaves a little bit differently from other rpm-ostree based variants
> of Fedora such as CoreOS, Silverblue, etc.

Thanks for the explanation! I've posted a patch to skip setting kernel arguments for ostree system
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/thread/E72BIU7NITNMY643GOD2Q7L33SKK32IB/

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

According to https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/message/4OHV4WGOZD6JNSL25FQZMOVDEIGHGGMQ/ this should be fixed. Can you update the status? Thanks

(In reply to Timothée Ravier from comment #12)
> According to
> https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/
> message/4OHV4WGOZD6JNSL25FQZMOVDEIGHGGMQ/ this should be fixed. Can you
> update the status? Thanks

Thanks for the reminder!