install: make platform-specific bootloader changes when -p specified

[bgilbert]

If -p is specified and /boot/coreos/platforms.json exists, look up the specified platform and the metal platform in that file. Remove any metal-specific kernel arguments or GRUB commands specified there, and inject any kargs/commands for the new platform. This allows us to apply a platform-specific console configuration at install time.

Set the platform before performing kargs modification to allow the latter to change a platform-specific default console.

When installing via coreos.inst kargs, persist any console= kargs to the destination system, as suggested in coreos/fedora-coreos-tracker#567 (comment).

[bgilbert]

Notably, while this PR allows the user to override console kargs, it doesn't provide a way to override the GRUB console commands.

[bgilbert]

Tested the contents of grub.cfg and kargs after install -p with:

• No platforms.json
• Target platform omitted from platforms.json
• Target platform with kargs + GRUB commands in platforms.json
• Target platform with kargs only in platforms.json
• Target platform with GRUB commands only in platforms.yaml

Ready for review.

[bgilbert]

Rebased and reworked. Tested the contents of grub.cfg and kargs after install with:

• no -p,
• -p aws (platform-specific kargs and GRUB commands),
• -p aliyun (no platform-specific kargs or commands),
• -p metal (redundant),

with each of:

• no platforms.json,
• platforms.json from Add platform-specific console configuration metadata fedora-coreos-config#1181,
• modified platforms.json with metal-specific kargs and GRUB commands.

Also tested:

• -p aws --delete-karg=console=ttyS0,115200n8 with platforms.json
• Forwarding console kargs when installing with coreos.inst.install_dev

Ready for review.

[cgwalters]

I hadn't really looked at this before. I totally understand the goals, but this is also taking us even farther away from the "fancy dd" model. The feature requires coreos-assembler as is and is another thing that won't work for RHEL for Edge. (Of course, it could be made to, and I do hope eventually they support Ignition at least optionally which would greatly simplify the story, but just noting)

How much do we need this versus just documenting how to use the existing kernel argument switches?

[bgilbert]

This code is only invoked for -p. I agree that the config file hackery isn't ideal, but -p is already doing config file hackery so I feel like that bridge has already been crossed. If we're going to have platform-specific kargs, I don't think -p will be user-friendly without this; the user would need to go look up what kargs to add (and potentially remove) to match the preconfigured image for that platform.

RHEL for Edge doesn't use Ignition, so -p already isn't meaningful there, and in fact will fail because it won't find a preconfigured ignition.platform.id karg.

[bgilbert]

Updated!

[bgilbert]

Thanks for the review! The last commit needs some additional thought, so I've moved it to a separate PR #877.

[bgilbert]

Updated!

[jlebon]

LGTM!