Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bootupctl ignores boot timeout settings in a kickstart installation #599

Open
jikortus opened this issue Jan 11, 2024 · 3 comments
Open

Comments

@jikortus
Copy link

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
Copy link
Member

cgwalters commented Jan 11, 2024

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
Copy link
Author

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
Copy link
Member

travier commented Jun 6, 2024

See also: #658 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants