networking and /boot/ignition/config.ign

[cgwalters]

Currently we support dropping /boot/ignition/config.ign in the disk image. This is used by the coreos-installer, and in general is a convenient tool for bare metal.

The problem today is that if this file is present, we still require initramfs networking. I'd like to support a pattern where an entire config can be injected there (without using any includes).

It feels like to generalize this we'd really need Ignition itself to activate networking only when it needs to.

In the mean time...the workaround for this case of "static Ignition with no networking" looks like writing
set ignition_network_kcmdline="" in /boot/ignition.firstboot
per this code.

[cgwalters]

We could resolve this issue by documenting the above and accepting it as a "stable API", but it feels like it'd be more elegant if we configured networking from userspace rather than the kernel (i.e. rather than using the kernel cmdline, and having dracut parse that), have Ignition trigger dracut to get network only when it needed to or something

[ajeddeloh]

It feels like to generalize this we'd really need Ignition itself to activate networking only when it needs to.

We can't know that in a generalized way until Ignition has it's config, and even then we'd need a tool to parse the config and see if it's fetching anything from network (and given config merging it would be non-trivial). Starting networking from Ignition is also not ideal since it may take a while to start and could make debugging even harder.

I'm in favor of just stabilizing the /boot/ignition.firstboot file API.

[bgilbert]

The problem today is that if this file is present, we still require initramfs networking.

Why is that a problem? Yeah, it's a bit of a performance hit, but only once per machine.

it feels like it'd be more elegant if we configured networking from userspace rather than the kernel (i.e. rather than using the kernel cmdline, and having dracut parse that), have Ignition trigger dracut to get network only when it needed to or something

Once we have NetworkManager working in the initramfs, the plan is for the Ignition units to Require NetworkManager so we don't need the magic dracut kargs anymore.

[cgwalters]

Why is that a problem? Yeah, it's a bit of a performance hit, but only once per machine.

I was playing with Fedora-Silverblue-based-on-FCOS (FSBCOS? Yeah going with that), and it made sense to me to inject the Ignition boot data, but the target machine only had WiFi so Ignition networking failed. Even if we put wpa_supplicant in the initramfs...which...ugh, my Ignition config didn't reference anything external.

(Actually what the images I have going now do is boot into GNOME Initial Setup, the GUI equivalent of systemd-firstboot; I was using Ignition to do basic storage and config setup before that; but we clearly want to support both)

[cgwalters]

And actually there's a much simpler case of this, which is when one wants to boot the Live ISO without providing any config at all and just get the interactive shell.

In that case, we still require networking in the initramfs even if no config at all is required.

Maybe one solution here is to have an ignition-generator that checks for whether a config is provided at all, and only if we find one do we enable the network.

[cgwalters]

That said...man all of this is just unnecessarily painful with dracut legacy networking. With NM-in-initramfs we can only cleanly start NM if we detect it's necessary.

Edit: which is what bgilbert said above.

[jlebon]

This is part of the more generic conditional networking issue: coreos/fedora-coreos-tracker#443.

[arithx]

Closing as this seems to have been fixed in coreos/fedora-coreos-config#426