Support cloud-specific grub fragments

[bgilbert]

Some clouds need particular kernel command-line arguments and grub commands, usually for configuring the console. On CL, this is used on AWS, Azure, GCP, and Packet.

[dustymabe]

Do you have examples of what these values are in CL?

[dustymabe]

For the console values.. would it help if the kernel supported something like this?

[bgilbert]

1. AWS
   • Serial console primary
   • modprobe.blacklist=xen_fbfront net.ifnames=0. I'm not sure whether this is still important.
2. Azure
   • Serial console primary, plus an earlyprintk option for unclear reasons
3. GCP
   • Serial console primary
4. Packet
   • Serial console primary on non-default port
   • coreos.autologin, which could be handled via a different mechanism
   • GRUB gfxpayload variable, which may or may not be important

So yes, the multi-console patch would help. It's possible that most of the other bits can be dropped now, though Packet's use of ttyS1 will still be relevant.

[bgilbert]

According to the Packet folks, gfxpayload is not needed.

Each Packet machine generally has a randomized root password which is made available through the Packet API. Container Linux uses coreos.autologin instead. Fedora CoreOS could opt for the randomized password approach, if desired.

[dustymabe]

should we discuss implementation details? Today for the firstboot parameter we have:

• The grub stencil looks to see if /boot/coreos-firstboot exists and will set the coreos_firstboot grub variable.
• The grub variable then gets substituted into the kernel command line on boot because we explicitly added $coreos_firstboot to our kernel command line

We could do something similar (set a grub var that updates the kernel command line based on a placed file specific to what oem we are targeting) for this work? Would we even need a separate file?

In https://github.com/coreos/ignition-dracut/issues/39 we actually were discussing changing the firstboot workflow to just use grub env vars and not require a file, but that would need some investigation.

[bgilbert]

On Container Linux, the OEM partition has a grub.cfg fragment which is sourced by the main GRUB config at runtime. Those are the files linked in #110 (comment). The fragment is pretty much limited to setting or appending to variables used in the kernel command line, such as $linux_console or $linux_append.

We could do something similar here, but it may not be necessary, since (unlike in CL) the base image knows about all of the supported platforms. We could have conditionals in the base config that set variables based on the platform ID, which GRUB already knows.

See also #47 (comment).

[bgilbert]

Per #114 (comment) we won't be enabling a coreos.autologin-like parameter on Packet.