Fedora IoT installer images have `inst.ks=hd:LABEL=Fedora-40-BaseOS-x86_64:/osbuild.ks`, boot to a hub complaining about incomplete kickstart

[AdamWill]

Current Fedora IoT installer images - built with osbuild - have an osbuild.ks file and a default kernel parameter inst.ks=hd:LABEL=Fedora-40-BaseOS-x86_64:/osbuild.ks that points to it. The file contains a single line:

ostreesetup --osname=fedora --url=file:///run/install/repo/ostree/repo --ref=fedora/rawhide/x86_64/iot --nogpg

...that's it. Obviously this is a very incomplete kickstart, so it causes anaconda to boot to interactive mode, with almost every spoke showing an attention flag caused by incomplete kickstart data:

this doesn't seem like it can be the intended experience. I don't know exactly when it started - it was between Fedora-IoT-ostree-x86_64-40-20231010.0.iso and Fedora-IoT-ostree-40.20231129.2-20231129.2.x86_64.iso , but I think the former was not built by osbuild, so it's not really a valid comparison. I don't think we've seen a 'successful' osbuild-built image yet, actually, so this may have been happening all along.

Filing here as it looks like the code responsible for adding the inst.ks param is in this repo.

[AdamWill]

this is how the hub would look in a more typical install that doesn't involve an incomplete kickstart:

note Keyboard and Time & Date are not in the attention state, and Installation Destination doesn't say "Kickstart insufficient".

[miabbott]

@paulwhalen could you investigate this and see that it gets fixed?

[pcdubs]

If we add some of those details to the included kickstart:

# partitioning
clearpart --none --initlabel
autopart --type=plain --nohome --noswap
# System language
lang en_CA.UTF-8
# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
ostreesetup --osname=fedora-iot --remote=fedora-iot --url=file:///run/install/repo/ostree/repo --ref=fedora/rawhide/x86_64/iot --nogpg
# System timezone
timezone America/Toronto --utc

Looks better, but not exactly like the typical Fedora install:

The partitioning no longer says kickstart insufficient, but also is not the attention calling red font.

[nullr0ute]

I think we just need to specify keyboard and timezone:

# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
ostreesetup --osname=fedora-iot --remote=fedora-iot --url=file:///run/install/repo/ostree/repo --ref=fedora/rawhide/x86_64/iot --nogpg
# System timezone
timezone America/Toronto --utc

But no @paulwhalen not Canadian variants ;-)

We explicitly want users to specify partitioning, but I think need need to get it to the "automatic partitioning" rather than "wipe everything" as people might not be pleased with that!

For storage I think dropping the clearpart line should be enough for that, so:

# partitioning
autopart --type=plain --nohome --noswap

[supakeen]

This issue is still active in Fedora-IoT-ostree-40-20240305.0.x86_64.iso. This is currently blocking all OpenQA tests for Fedora IoT. I'm assigning the issue to me to fix :)

[AdamWill]

I will try and work around it in openQA for now, so it can run all the tests that are currently skipped because install doesn't work. I should probably have done that sooner, but I kept expecting this to get fixed.

[AdamWill]

openQA workaround is in, but the tests now fail on https://bugzilla.redhat.com/show_bug.cgi?id=2268505 . I'm doing anaconda builds with my proposed fix for that backported.

[supakeen]

I've been doing some debugging and figuring out why this is happening and I've got the installer to the above view which is much more complete. Would it be OK to create a PR that changes it to that? :)

[supakeen]

Just jotting down a few notes, first is taking the custom kickstart approach:

1. autopart --nohome --noswap is not enough to get the "kickstart insufficient" to be gone, we would need to do this with reqpart --boot + part so a target device is also automatically selected. I'll need to confirm this with Anaconda if I'm doing that right.
2. Specifying the kickstart more fully does indeed work (timezone, lang, and keyboard) but due to point 1 the kickstart is still insufficient.

If we were to instead write the kickstart to /usr/share/anaconda/interactive-defaults.ks then Anaconda does not enter kickstart mode I believe and will use its defaults for the rest of the spokes/hubs. Writing a single kickstart with only the ostreesetup bits into that path gives us the above screenshot.

Now I have two approaches I can take for this, the first, or the second. Both are a bit of work. We don't support the part command in our kickstart stage in osbuild and for interactive defaults it clashes a bit with how we currently define installer images.

I'm going to be implementing the second approach unless someone stops me as it seems more sane to let Anaconda do its thing as much as possible and to only define the ostree bits.

[AdamWill]

I've been doing some debugging and figuring out why this is happening and I've got the installer to the above view which is much more complete. Would it be OK to create a PR that changes it to that? :)

The state of the Time & Date spoke in that screenshot is a bit odd, but assuming that was just transient and it would clear to "OK" state, it looks good.