create_disk: Use bootupd to install uefi if configured

[cgwalters]

See https://github.com/coreos/bootupd
and coreos/fedora-coreos-tracker#510

Basically in order to handle updates, bootupd also
takes care of installation. For example this also generates a JSON
file with the versions.

In order to sanely "ratchet" this change, only use bootupd if
we find the ostree deployment is using it.

[cgwalters]

One thing I went back and forth on is whether the grub.cfg file should be part of the bootupd payload or not. For us, it clearly can be...and possibly should be. But bootupd is basically just replacing what traditional yum update shim-x64 does today; the RPMs don't include the config.

If we e.g. implemented coreos/fedora-coreos-tracker#465 for boot then we'd need to edit the grub config to refer to the uuid instead of label, so we wouldn't want to update it. (Or perhaps better we'd want to split the uuid to a separate file)

[cgwalters]

Requires: coreos/fedora-coreos-config#595
And also requires bootupd git master.

[darkmuggle]

One thing I went back and forth on is whether the grub.cfg file should be part of the bootupd payload or not. For us, it clearly can be...and possibly should be.

I think I'm aligned with your thinking here with the caveaut that we have an option to let the user YOLO on it. My vote would be to have everything managed in /boot unless the user opts out (e.g. /usr/sbin/bootupd --yolo...)

But bootupd is basically just replacing what traditional yum update shim-x64 does today; the RPMs don't include the config.

One of the reasons I'm excited about bootupd is because of the potential. I would encourage us not limiting what it can do. I sort of hope that bootupd can manage /boot for things like grub.cfg and blsconfigs. With a little planning this could give RHCOS a path for doing secure boot or even gasp appended initrd's.

[cgwalters]

I think I'm aligned with your thinking here with the caveaut that we have an option to let the user YOLO on it. My vote would be to have everything managed in /boot unless the user opts out (e.g. /usr/sbin/bootupd --yolo...)

Right, but doing that kind of thing requires the equivalent of what dpkg/ostree/rpm do in understanding "this is a config file" versus "this is code", and tracking that in a database and implementing a policy like "only replace this if it wasn't modified" etc. Not seriously hard or anything, but a scope increase.

One of the reasons I'm excited about bootupd is because of the potential. I would encourage us not limiting what it can do. I sort of hope that bootupd can manage /boot for things like grub.cfg and blsconfigs. With a little planning this could give RHCOS a path for doing secure boot or even gasp appended initrd's.

ostree is handling the bootloader configs today right? There's a PR for multiple initrds (as distinct from appended) here: ostreedev/ostree#2155

[ashcrow]

So far so good 😃

[cgwalters]

OK just like coreos/fedora-coreos-config#595 I've redone this so we at least temporarily support both pre-bootupd and bootupd models.

[darkmuggle]

Changes look good, but we don't have bootupd yet:

No match for argument: bootupd
Error: Unable to find a match: bootupd
script returned exit code 123

[miabbott]

Changes look good, but we don't have bootupd yet:

No match for argument: bootupd
Error: Unable to find a match: bootupd
script returned exit code 123

It looks like the make install approach is required for now

coreos/fedora-coreos-config#595 (comment)

Side note: the reason this is useful now is I am testing bootupd via
make install DESTDIR=/var/srv/walters/builds/fcos/overrides/rootfs/ so it doesn't matter that it's not listed in the manifest too. But I do plan to package it soon.

[cgwalters]

https://bugzilla.redhat.com/show_bug.cgi?id=1878908

[cgwalters]

OK CI is failing in coreos/fedora-coreos-config#595 because it needs this...so we need to ratchet things by keeping the version of code here's that's conditional.

[jlebon]

Makes sense to me.
/lgtm

(CoreOS CI flake; restarted.)

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ashcrow, cgwalters, jlebon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ashcrow,cgwalters,jlebon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment