Influence kernel parameters at install time

[davidcassany]

Elemental client elemental install command should have some way to easily influence the kernel parameters within the bootloader.

Ideas:

• make the grub2 configuration file a template and render it at install phase
• pass kernel parameters as a grub environment variable that gets filled at install time
• patch grub.cfg at install time
• mix of template and grub2 approach

This will allow us to set all labels at install time and remove any partition or filesystem label literal from elemental-toolkit repository.

[mudler]

I wonder if we can't reuse already the grub extra boot params envs instead of generating the grub.cfg.

I've a mixed feeling about generating grub configs, at that point I feel we could drift away and show discrepancies between node, besides adding non-obvious code paths.

[mudler]

Having a post-install hook seems also something that is already doable by using the after-install stage. so this is completely doable already by pushing a cloudconfig which alters the boot options, among the lines of https://rancher.github.io/elemental-toolkit/docs/customizing/configure_grub/#grub-environment-variables

[mudler]

This sounds really invasive and hard to maintain in the long run - do we need custom partition labels for state, persistency, and all? It feels reimplementing tools to generate grub configs.

So.. gotta ask: what's the motivation behind this?

If it comes to add boot parameters after install that's easily doable already by writing the grub env files, this can be easily instrumented from the agent too.

[kkaempf]

It's mostly about any quirks your hardware/driver combination has and you need to work around by passing kernel parameters (for ISO boot and for disk boot)

[mudler]

Right, but is this card about generating grub.cfg during install? That's a big design change as it starts to add dynamic config generation on runtime.

For such options on the livecd is not needed, neither after install. I'm just concerned about dynamic configuration generation as it propagates down to other paths, e.g. when resetting a system

[davidcassany]

So.. gotta ask: what's the motivation behind this?

The motivation is to decouple as much as possible the OS image contents from the installation details such as partition layout and its labels and also give the opportunity to set the kernel parameters, stuff like selinux=0 or selinux=1 should be install or even runtime choices, those should not be enforced inside the OS image.

So I think it would be nice at install time to be capable to set partition labels and selinux=1 or selinux=0. Now if we want to change that we need to build custom OS Image or run weird and hard to maintain installation hook scripts to change few literals here and there.

My idea is that the OS Image sets the bootloader configuration but there is an expectation between the given configuration and elemental-cli to define some values so there is no need to hardcode default literals.

[kkaempf]

One more use case: rancher/cluster-api-provider-rke2#291