Add metal-bios and metal-uefi targets

[cgwalters]

Split out the "net.ifnames" stuff into a separate kickstart, and
generate a raw disk image metal-bios if specified.

Note to really be useful this requires Ignition to load /boot/config.ign
or so.

[cgwalters]

Depends #302

[cgwalters]

An architectural question here is whether we should follow the "buildextend" model instead. The issue with that is that the "cloud/metal" split introduced here has changes around the kernel cmdline/networking that would be tricky to do as a "transformation" of a cloud image (or vice versa).

One thing that might be nice is if we actually pushed handling the early networking logic to Ignition; e.g. it could detect the oemid and e.g. tell dracut to request networking, and also configure the network adapter. That way the disk image would look a lot closer between the two cases - we'd be doing things dynamically in Ignition.

[cgwalters]

@ajeddeloh re my random network/Ignition musings ⬆️

[cgwalters]

OK rebased 🏄‍♂️ and lifting WIP. This still requires Ignition to read /boot or something equivalent to be ergonomic though.

[cgwalters]

OK and now with GPT partitioning by default and a metal-uefi target.

[cgwalters]

and a metal-uefi target

Which actually boots when I dd it to a spare laptop I have.

[dustymabe]

Changes mostly LGTM some comments scattered.

[dustymabe]

Which actually boots when I dd it to a spare laptop I have.

nice! 🥳

[dustymabe]

One thing I do wonder: If the "no anaconda" work lands soon we will be ripping some of this out. Is that something you'd be OK with ?

[dustymabe]

cc @ajeddeloh

[cgwalters]

One thing I do wonder: If the "no anaconda" work lands soon we will be ripping some of this out. Is that something you'd be OK with ?

Yeah of course, but the external API should stay the same - e.g. the metal-bios and metal-uefi names. (So if we want to bikeshed those do it now)

[cgwalters]

Squashed in the fixes ⬆️

[dustymabe]

Yeah of course, but the external API should stay the same - e.g. the metal-bios and metal-uefi names. (So if we want to bikeshed those do it now)

re: metal-bios and metal-uefi. No problem with the names but if we are able to get a combined image then the need for having separate names would go away. So the api would change in that case. Acceptable?

[cgwalters]

No problem with the names but if we are able to get a combined image then the need for having separate names would go away. So the api would change in that case. Acceptable?

I had thought we'd just have them refer to the same image.

[dustymabe]

I had thought we'd just have them refer to the same image.

I guess we can cross that bridge when we get there, but if we do the work to get a combined image I'd rather deprecate metal-bios metal-uefi and expose it as metal in the future.

[cgwalters]

but if we do the work to get a combined image I'd rather deprecate metal-bios metal-uefi and expose it as metal in the future.

shrug - we're talking about a few lines of JSON. I don't think it's worth worrying over too much.

[dustymabe]

but if we do the work to get a combined image I'd rather deprecate metal-bios metal-uefi and expose it as metal in the future.

shrug - we're talking about a few lines of JSON. I don't think it's worth worrying over too much.

agree. just wanted to set expectations accordingly

[dustymabe]

ok relooked over this.. only outstanding comment is #305 (comment) I think

[dustymabe]

/me running through a test now

[cgwalters]

And updated again to fix ShellCheck.

[dustymabe]

ran a cosa build metal-bios after running a cosa build and I get No apparent changes since previous commit; use --force-nocache to override . Should we add any handling for cases like that?

[cgwalters]

Should we add any handling for cases like that?

Yes but let's not block merging this on that.

• It's a developer issue and we need to ship content
• This code needs to land so multi-arch work doesn't conflict and I've already rebased a few times
• Really cmd-build needs a rewrite; doing things like that requires parsing the JSON which sucks in bash

[dustymabe]

Yes but let's not block merging this on that.

OK

Finally got through with testing. I was able to take the output fedora-coreos-29.4-metal-bios.raw convert it to gz and then use the installer ISO from my other work and perform an install.

[cgwalters]

This was deployed in FCOS in coreos/fedora-coreos-pipeline#43