Skip to content
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

interactive live ISO experience no longer works with Ignition 2.4.0 #514

Closed
dustymabe opened this issue Jul 14, 2020 · 7 comments
Closed

Comments

@dustymabe
Copy link
Member

In the new Ignition we now default to writing out a config even if once wasn't provided by the user (coreos/ignition#1002). This breaks our hacky detection of if an Ignition config was provided for the ISO boot and causes the "interactive Live ISO" experience to not happen. We need to come up with a new way for us to properly detect this so we can not have a regression.

@dustymabe
Copy link
Member Author

cc @bgilbert. We should get this fixed before the testing release.

@dustymabe
Copy link
Member Author

One suggestion was to use the structured journal messages ignition logs now but that gets tricky because we're running in a generator. Obviously one solution may be to hoist this stuff into a different place so we don't have that limitation.

@arithx
Copy link
Contributor

arithx commented Jul 14, 2020

Whoops, didn't catch that implication when writing the PR sorry.

One alternative could be to temporarily have Ignition write out a separate file indicating that there was no user configuration. Or we could have a fetch-style stage that could exit depending on whether or not there is a provider / user config defined which we could call in the detection script.

@cgwalters
Copy link
Member

One suggestion was to use the structured journal messages ignition logs now but that gets tricky because we're running in a generator.

What's tricky about querying the journal from a generator?

(The reason this works is because this generator is running in the real root, Ignition runs in the initrd, so it's not going to race or anything)

@jlebon
Copy link
Member

jlebon commented Jul 15, 2020

Folded a fix for this into #426.

jlebon added a commit to jlebon/fedora-coreos-config that referenced this issue Jul 15, 2020
We shouldn't use `/run/ignition.json` to determine whether a user
config was provided since it's implementation details. Instead, use the
new official journal messages that Ignition emits.

Closes: coreos#514
@jlebon
Copy link
Member

jlebon commented Jul 15, 2020

One thing related to this is that we should fix (or check if it's already fixed by the recent work to close races) the iso-live-login scenario in testiso and turn that on in CI for this repo (and really, all the default testiso scenarios).

jlebon added a commit to jlebon/fedora-coreos-config that referenced this issue Jul 15, 2020
We shouldn't use `/run/ignition.json` to determine whether a user
config was provided since it's implementation details. Instead, use the
new official journal messages that Ignition emits.

Closes: coreos#514
@dustymabe
Copy link
Member Author

Folded a fix for this into #426.

Thanks @jlebon

One suggestion was to use the structured journal messages ignition logs now but that gets tricky because we're running in a generator.

What's tricky about querying the journal from a generator?

I just wasn't sure if it would work or not, or cause other problems. Looks like it works 🎉

jlebon added a commit to jlebon/fedora-coreos-config that referenced this issue Jul 15, 2020
We shouldn't use `/run/ignition.json` to determine whether a user
config was provided since it's implementation details. Instead, use the
new official journal messages that Ignition emits.

This is complicated by the fact that we need to support RHCOS, where the
journal messages haven't been backported. Use the fact that we always
have a base config to key off of whether to use the old behaviour vs the
new one. (More accurately, we'd want to check for
coreos/ignition#1002, but there's no easy way to
do this from the outside. Alternatively we can check the Ignition
version, though that's deeply nested under `/usr/lib/dracut/...`).

Anyway, this should be temporary until RHCOS moves to spec v3.

Closes: coreos#514
@jlebon jlebon closed this as completed in 65de5e0 Jul 15, 2020
c4rt0 pushed a commit to c4rt0/fedora-coreos-config that referenced this issue Mar 27, 2023
fedora-coreos-config: bump for in-place LUKS auto-growpart
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants