bootupctl ignores boot timeout settings in a kickstart installation

[jikortus]

When installing a bootable container image via Anaconda and using a kickstart file with bootloader command that also specifies a boot timeout (--timeout parameter), the specified value is ignored and a predefined one from static GRUB configuration files is used. Using a predefined value makes likely perfect sense in the common scenarios, but somewhat breaks the user experience with Anaconda which provides, among many other configuration options, a possibility to set up an arbitrary timeout value.

[cgwalters]

I'm a bit uncertain. In the very short term, we should probably make Anaconda error out if it's passed any of these options.

In the longer term; note that part of the idea here is that one can include static GRUB configuration fragments as part of the container image...e.g. setting timeout=0 should be viable by dropping new files into /usr/lib/bootupd/grub2-static/configs.d/. (Is this documented well? Not really...)

To emphasize this, a big part of the idea of the bootc effort is that operating system configuration lives in the container - not in kickstarts. (At a practical level we need to support some configuration via per-machine mechanisms such as kickstart, especially static IP addressing for example). But again we're not just s/dnf/bootc/ here - the goal is to make containers the Source Of Truth.

There's also an argument that bootupd's static grub stuff should make some effort perhaps to support some of the same things that are handled by anaconda today in https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/storage/bootloader/grub2.py#L253
It's...messy though.

[jikortus]

I agree, those are two somewhat distinct, possibly even contradicting 'worlds', as I perceive it - container a source of truth on one hand, and regular kickstart installation with its many options it generally offers on the other hand.

As you mention the GRUB configuration can be done via snippets in /usr/lib/bootupd/grub2-static/configs.d/, I think the both approaches could be combined by using it: Anaconda could drop a related piece of configuration with a low priority in there, which would apply if it's not overriden by other, already existing higher priority configuration file from the container. This way we could let Anaconda do the timeout configuration (and possibly something else if needed) and yet have the container content as the primary source of truth.

But anyway it's not up to me to decide :-) and I reckon the best approach would be to also take into account possible feedback from our customers/community when the bootable containers installation gets into a common use.

[travier]

See also: #658 (comment)