Add install --console and ... customize --dest-console to configure GRUB and kernel console
#977
Conversation
It was originally factored out for unit testing, but these days we just use KargsEditor which has its own tests. Simplify by using KargsEditor directly, with a separate initial probe to ensure we can find the ignition.platform.id.
This has us rewriting the BLS config twice if `--platform` is specified, but that option is non-performance-critical and also an edge case, so let's aim for legibility. Preparatory for next commit.
bgilbert
changed the title
install --console and ... customize --dest-console to configure GRUB and kernel consoleinstall --console and ... customize --dest-console to configure GRUB and kernel console
|
Ready for review! |
|
CI is failing because |
|
Overall strategy seems sane to me without reviewing the code directly. One question I have.. Should we consider giving the user a warning if they try to set the kernel argument for console directly so that existing users get pointed towards this new (better) feature? |
And by "set the kernel argument for console directly" I mean either in the provided Ignition config (won't work for remote Ignition references, but that's OK), or through |
|
Updated!
I've added a warning for |
Once CoreOS stops enabling the serial console by default, users will need a way to enable it themselves. This really only affects bare metal, since other platforms have a consistent console configuration, so coreos-installer is a good place to handle it. Users can already pass console= kargs, but we need a way to specify GRUB commands, ideally without having to actually use GRUB syntax. Add a --console option that accepts kernel console= syntax, since that's already familiar. Parse the option and convert it to both a console karg and GRUB commands, using the existing mechanism for GRUB command substitution. If --platform is also specified, have --console override that platform's default console settings. If --console is specified more than once, aggregate the console settings, following the multiple-console semantics for GRUB (use both consoles) and the kernel (use all consoles, with the last console primary). There are serial console features only supported by GRUB (stop bits) or by the kernel (RTS/CTS flow control). Support the common subset and reject the rest. Also, round-trip console kargs to a less-compact but semantically equivalent format, since explicit is good and it saves some code complexity. Document this as "bootloader console" rather than "GRUB console" to allow for future bootloaders other than GRUB.
If a flag was absent from features.json, we were failing to parse rather than defaulting the flag to false. This didn't matter in practice because both flags were introduced into production at the same time as the file in FCOS 35.20211215.2.0.
Use the installer-config-directives features.json object introduced by coreos/coreos-assembler#3083 to check whether the image's coreos-installer is new enough to support --console.
Rather than manually adding new fixtures to every test individually, have each test declare its minimum supported fixture, and then automatically run the test on any newer fixtures. Fixes failure to invoke some tests on 2022-02 fixture.
In particular, it includes the "console" directive.
If one or more console= kargs are specified to the install or iso/pxe customize subcommands, and Console can successfully parse all of those kargs, warn the user that they might benefit from specifying them using the console mechanism instead. For legibility, wrap the message at 80 characters, but avoid wrapping in the middle of the example argument lists. Use the textwrap crate to do this. textwrap is already a clap dependency without default features, and we also avoid non-default features here, so this doesn't increase the binary weight.
| @@ -0,0 +1,347 @@ | |||
| // Copyright 2022 Red Hat, Inc. | |||
There was a problem hiding this comment.
This module is both terrifying and great, which is about what we expected I think. 😆
Really nice work!
Once CoreOS stops enabling the serial console by default, users will need a way to enable it themselves. This really only affects bare metal, since other platforms have a consistent console configuration, so coreos-installer is a good place to handle it. Users can already pass
console=kargs, but we need a way to specify GRUB commands, ideally without having to actually use GRUB syntax.Add a
--consoleoption that accepts kernelconsole=syntax, since that's already familiar. Parse the option and convert it to both a console karg and GRUB commands, using the existing mechanism for GRUB command substitution. If--platformis also specified, have--consoleoverride that platform's default console settings. If--consoleis specified more than once, aggregate the console settings, following the multiple-console semantics for GRUB (use both consoles) and the kernel (use all consoles, with the last console primary).There are serial console features only supported by GRUB (stop bits) or by the kernel (RTS/CTS flow control). Support the common subset and reject the rest. Also, round-trip console kargs to a less-compact but semantically equivalent format, since explicit is good and it saves some code complexity.
Document this as "bootloader console" rather than "GRUB console" to allow for future bootloaders other than GRUB.
Add the corresponding
--dest-consoleoption to thecustomizecommands. Use theinstaller-config-directivesfeatures.jsonobject introduced by coreos/coreos-assembler#3083 to check whether the image's coreos-installer is new enough to support--console. In the future we can potentially support a--live-consoleor combined--consolecustomize option that also affects the live kernel and bootloader (#979), but defer that for now.