-
Notifications
You must be signed in to change notification settings - Fork 95
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
iso: add kargs
commands to manage kernel args
#341
Conversation
The command requires coreos/coreos-assembler#1637 to work so that ISOs have the necessary info in the header, but the PR itself can of course be merged independently. |
UX concern: it is my understanding that |
Yeah, good point. Open to bikeshed on names. 🖌️
(And deprecate/forward Maybe we could make that second command be |
|
I don't mind
|
In help, presumably, not at runtime. @jlebon Remember to update the subcommand list in |
This follows from @dustymabe suggestion. Some approach like this feels good to me because:
|
My argument for @lucab Does that meet the criteria list you have in #341 (comment)? |
@jlebon yes, not strongly attached to specific keywords as long as the intent is clear. |
src/cmdline.rs
Outdated
@@ -438,6 +457,40 @@ pub fn parse_args() -> Result<Config> { | |||
.takes_value(true), | |||
), | |||
) | |||
.subcommand( | |||
SubCommand::with_name("embed-kargs") | |||
.about("Embed additional kernel args in an ISO image") |
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.
Maybe Add kernel arguments to the ISO image
?
One concern: we also have the same use case for the ISO of needing to remove the default nosmt
in FCOS?
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.
The wording here matches the wording used for the ignition
subcommand. It's more or less s/embedded Ignition config/embedded additional kernel args/
. Thought that was nice, but not against rewording entirely if folks prefer!
Re. nosmt
, yeah right now this is limited to managing additional kernel args. I think we could redesign things so that it handles base kargs as well, though it's definitely easier technically (and I think somewhat conceptually too) to operate in an "overlay" pattern, again like the ignition
command. For example, appended-kargs remove
will change the file back to a binary match of the original file.
I was looking at the kargs we bake in today, and the two big ones that one might want to revert are the smt
one and the cgroupsv2 one. Both of those can be done by just overriding with another karg (i.e. mitigations=off systemd.unified_cgroup_hierarchy=1
).
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.
Actually hmm, for the mitigations=off
test, my test might not be valid because I was testing in a VM with a single core & thread anyway. But I definitely observed cat /sys/devices/system/cpu/vulnerabilities/*
change output. I'll do another sanity-check that SMT can be re-enabled this way.
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.
I'll do another sanity-check that SMT can be re-enabled this way.
OK, so this test was slightly wrong because the default kernel behaviour is mitigations=auto
, not off
. But anyway, I did verify using qemu-kvm -smp threads=2
and lscpu
that appending mitigations=auto
is indeed equivalent to removing the mitigations=auto,nosmt
flag.
src/iso.rs
Outdated
let s = std::str::from_utf8(&area[..area_size]).chain_err(|| "invalid UTF-8 area")?; | ||
let s = s.trim_end_matches('#'); | ||
if s.is_empty() { | ||
bail!("No embedded additional kernel args."); |
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.
Is that an error?
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 matches the semantics for iso ignition show
. :)
This was changed to `coreos-installer iso appended-kargs` in later reviews: coreos/coreos-installer#341
appended-kargs
commands to manage additional kernel args
OK, rebased this on top of #343 (that was quite the conflict-fest) and moved to |
coreos/coreos-assembler#1638 will need to be updated. |
This was changed to `coreos-installer iso appended-kargs` in later reviews: coreos/coreos-installer#341
Yup, that's part of coreos/coreos-assembler#1637! If we merge the cosa PR first, then we should be able to see this in action in CI here by inspecting the |
How about renaming the command to just |
done |
I think given coreos/fedora-coreos-tracker#567 we should probably also support explicitly reconfiguring the console, not just appending to the existing list. |
didn't get your point. Now we can |
OK, that sounds good. Is it possible to do in one commandline? Otherwise people without reflinks are going to feel some pain in rewriting the ISO twice. It looks like some basic tests could be added here for CI. |
not yet
exactly, but this depends on coreos/coreos-assembler#1637 , so it's better to do a bit later in a separate PR |
@nikita-dubrovskii Hope you don't mind, I picked this up again and pushed some refactors on top! I kept your co-ownership in the commit. Some things I did:
There are some more tweaks I'd like to do, but the code works well as is! Requires: coreos/coreos-assembler#1985 |
appended-kargs
commands to manage additional kernel args kargs
commands to manage kernel args
Np, thx for the updates
Hmm, i'm not a fan of many
Yep, quotes were used to handle spaces, at least i was testing it. LGTM |
OK, split out some prep patches into separate commits and simplified it down to having just |
This is mostly a revert of coreos#1652, though with a spin on it: we automatically detect if the `coreos-installer` in the cosa container has coreos/coreos-installer#341. This will allow us to test the functionality in that PR's CI before merging, as well as avoiding ugly warnings until it gets into cosa proper. (This addresses the original reason for the revert.) Another difference is that we capture the stderr and make it part of the warning to make it less scary if operating on an older CoreOS ISO and to make it clear that it's non-fatal.
This is mostly a revert of coreos#1652, though with a spin on it: we automatically detect if the `coreos-installer` in the cosa container has coreos/coreos-installer#341. This will allow us to test the functionality in that PR's CI before merging, as well as avoiding ugly warnings until it gets into cosa proper. (This addresses the original reason for the revert.) Another difference is that we capture the stderr and make it part of the warning to make it less scary if operating on an older CoreOS ISO and to make it clear that it's non-fatal.
That way, cosa itself uses the fresh binaries when calling out to `coreos-installer` (e.g. for downloading images, injecting Ignition configs, etc... and soon also injecting ISO kargs).
Then, `bls_entry_options_delete_and_append_kargs` is a thin wrapper around that new function to convert to the callback semantics we need. Prep for future patch.
To clarify, once we're agreed on the general direction here, my suggestion is to merge coreos/coreos-assembler#1989 and then we should be able to verify in CI here that it's working by looking at the console log output for |
This is mostly a revert of coreos#1652, though with a spin on it: we automatically detect if the `coreos-installer` in the cosa container has coreos/coreos-installer#341. This will allow us to test the functionality in that PR's CI before merging, as well as avoiding ugly warnings until it gets into cosa proper. (This addresses the original reason for the revert.) Another difference is that we capture the stderr and make it part of the warning to make it less scary if operating on an older CoreOS ISO and to make it clear that it's non-fatal.
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.
LGTM generally!
This is mostly a revert of #1652, though with a spin on it: we automatically detect if the `coreos-installer` in the cosa container has coreos/coreos-installer#341. This will allow us to test the functionality in that PR's CI before merging, as well as avoiding ugly warnings until it gets into cosa proper. (This addresses the original reason for the revert.) Another difference is that we capture the stderr and make it part of the warning to make it less scary if operating on an older CoreOS ISO and to make it clear that it's non-fatal.
This matches rpm-ostree's `kargs --replace` syntax as well. This functionality isn't actually used by anything, but it's prep for that.
Prep for future patch.
We were already using this shorter help text for `iso ignition embed --output`. Let's use that for all the other similar `--output` flags to be consistent, and also because the next patch introduces another command which will use this and it will help staying within the 80 character column limit.
Updated and now with a test on the FCOS ISO! Once I moved the embed area-related values into a struct, I refactored things a bit more to just put the functions in the struct's |
Cool! We can see coreos/coreos-assembler#1989 in action in the
|
The new commands are `coreos-installer iso kargs modify/reset/show`. These allow modifying the baked in kernel arguments in a CoreOS live ISO. My primary motivation for this is for embedding the right serial console argument into the ISO before booting it: ``` $ coreos-installer iso kargs modify --append console=ttyS0 my.iso $ coreos-installer iso kargs show my.iso mitigations=auto,nosmt ... console=ttyS0 $ cosa run --qemu-iso my.iso -c ... [ 0.000000] Command line: BOOT_IMAGE=/images/vmlinuz ... console=ttyS0 ... ``` This example specifically demonstrates what cosa will do automatically itself once it can rely on this functionality. This will for example allow `testiso` tests to be much more useful because we'll actually have console logs. But it's of course useful generically. Another way to look at it is that it mirrors/brings to parity the provisioning capabilities of the live PXE path. Co-authored-by: Nikita Dubrovskii <nikita@linux.ibm.com>
Updated! |
Document additions from coreos#341
Document additions from coreos#341
The new commands are
coreos-installer iso kargs modify/reset/show
.These allow modifying the baked in kernel arguments in a CoreOS live
ISO.
My primary motivation for this is for embedding the right serial console
argument into the ISO before booting it:
This example specifically demonstrates what cosa will do automatically
itself once it can rely on this functionality. This will for example
allow
testiso
tests to be much more useful because we'll actually haveconsole logs.
But it's of course useful generically. Another way to look at it is that
it mirrors/brings to parity the provisioning capabilities of the live
PXE path.
Co-authored-by: Nikita Dubrovskii nikita@linux.ibm.com