Allow to specify a different livecd label than `COS_LIVE` to derivatives

[mudler]

Is your feature request related to a problem? Please describe. currently, we rely on COS_LIVE label hardcoded on several places, so the livecd packages depends directly on it

Describe the solution you'd like To have them at least customizable somehow, so derivatives can build their own and change the label on the resulting ISO.

The makeiso extension already allows to apply a disk label, but we have to explore where we hardcode that in cOS code - and make sure that can be customized

Describe alternatives you've considered N/A

Additional context

[mudler]

This is already possible while creating the ISO with makeiso, we just need to document how to do that

[Itxaka]

Whi as @mudler comments, this is possible to do when creating the iso by using the label stanza, that results into a non-booting iso due to a mismatch in lables.

On one side we have the actual partition label for the iso, which is covered by makeiso already, but on the other we have the syslinux packages which have the COS_LIVE label hardcoded adn we need to change those as well.

That is simple to do as on package build we can inherit a value from the values file and do a sed on the files BUT...the problem is how to sync between the iso (which uses the manifest file) and the package (which uses the values file).

Any idea bout how to sync both? Require both to be changed is kind of a bad solution because we will get desync issues there.

[davidcassany]

Would be nice to have some sort of config file to name all these devices (COS_LIVE, COS_OEM, COS_PERSISTENT, etc.) the problem I see is that we need to access these values in very different stages of the build process and in runtime.

What about creating a config package that includes a cOS config file and then make packages like syslinux to require it so at build time the configs can be read and applied? The package could be part of the cos image so at run time packages such as installer could also read the values and apply them accordingly. The point is that if we create a config file centralizing these sort of values they need to be available at both, runtime and build time.

[mudler]

Whi as @mudler comments, this is possible to do when creating the iso by using the label stanza, that results into a non-booting iso due to a mismatch in lables.

Yes right, my point is that if we can't find a common solution we can just document how to override the syslinux config reusing our docs (https://rancher-sandbox.github.io/cos-toolkit-docs/docs/creating-derivatives/build_iso/#customize-bootloader) with a practical example IF someone really wants to change the iso label

Would be nice to have some sort of config file to name all these devices (COS_LIVE, COS_OEM, COS_PERSISTENT, etc.) the problem I see is that we need to access these values in very different stages of the build process and in runtime.

I see what are you doing here :smile: ... reminds me of this nice card we have in the icebox #160 :bomb:

That would be very nice, I'd also add that it would be nice in the same way to specify partition sizes and maybe even the image sizes that are created... (I'm refering to the active/passive ones) but that's another topic

What about creating a config package that includes a cOS config file and then make packages like syslinux to require it so at build time the configs can be read and applied? The package could be part of the cos image so at run time packages such as installer could also read the values and apply them accordingly. The point is that if we create a config file centralizing these sort of values they need to be available at both, runtime and build time.

That sounds good, we can also reuse https://rancher-sandbox.github.io/cos-toolkit-docs/docs/customizing/general_configuration/ to be consistent

[mudler]

I think this is already doable now with grub and how the docs are wrote around it to specify a live cd label, although this is not actually tested. I would close this card and see if this comes back again as someone encounters bugs while trying to do this. Any thoughts cc @davidcassany @Itxaka ?

[davidcassany]

Well, this is related to #160 indeed. It is possible to configure it if you rebuild the live/grub packages with the modified label. Bootloader config needs to know the label, so this is not as simple a placing a label into the manifest... 😞

I believe to properly support that we need to embrace the customizations at install time story #1152. IMHO this is pretty related as it faces the same sort of limitations, we are shipping bootloader config in a package that relies on some label names. Since this is for bootloader it is not simple to dynamically resolve it from somewhere (conf file) at runtime, it should be done at install time (during ISO creation or disk creation/installation).

My desired solution (not straight forward) would be:

• code template resolver in elemental
• add the template resolver (not sure if anything else beyond bootloader and default cloud-init files would need it) for config files at install time in elemental after mtree verification is done (aka resolve packages/grub2/config/grub.cfg.tmpl).
• code ISO/disk builder in elemental
• use the template resolver in ISO builder to customize config files

[davidcassany]

Cutsomization of labels is already possible closing