-
Notifications
You must be signed in to change notification settings - Fork 93
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
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.
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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM.
I am both scared by the regex monster and by your newly acquired knowledge on serial oddities across Linux and GRUB 😄
On a more serious note, I really only have a general question about UX.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
--console
option 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--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.
Add the corresponding
--dest-console
option to thecustomize
commands. Use theinstaller-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
. In the future we can potentially support a--live-console
or combined--console
customize option that also affects the live kernel and bootloader (#979), but defer that for now.