create_disk: Add `bootupd-epoch`, hard require new bootupd

[cgwalters]

trafficstars

This hard requires

• https://github.com/coreos/bootupd/pull/543
• https://github.com/coreos/ignition/pull/1728

---

[dustymabe]

Thanks for working on this

[cgwalters]

Now with a config knob, off by default. This definitely needs some careful review (whee shell script fragility) and testing (across all architectures really).

[dustymabe]

Now with a config knob, off by default. This definitely needs some careful review (whee shell script fragility) and testing (across all architectures really).

+1 - i'll take a closer look in the morning when I'm fresh. Once we get it close on code review we can do a COSA build in the pipeline and run it through the bump-lockfile job in the staging pipeline (tests against all architectures).

[cgwalters]

Tested now on x86_64, booting BIOS and UEFI in both epoch 0 and 1.

[cgwalters]

Note that we're also discussing moving the static grub configs into a subpackage of bootupd, xref https://github.com/coreos/bootupd/pull/536

If we did that, it'd be another epoch. (Which, if we agree to do it, maybe we should just make "epoch 1" be that)

[cgwalters]

Renata added this on internal chat but replicating here: Once we do this we also want to update https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/

(That said, in the context of Sagano this would actually be a Sagano doc, not a CoreOS doc...)

[jlebon]

Interesting, CI just hit https://github.com/coreos/rpm-ostree/issues/4565. So I guess https://github.com/coreos/coreos-assembler/pull/3619 didn't do the trick.

[dustymabe]

Let me know what you think of the optional comments. Otherwise everything LGTM. I can do a multi-arch build of COSA and run this through the staging bump-lockfile job with both epoch 0 and 1 to see how the architectures respond to it if you like.

[cgwalters]

Sure, SGTM (honestly feel free to force push cleanups here if you like).

That said I think I'd actually want to wait and make "epoch 1" include the grub.cfg rework, so will release a new bootupd soon.

[cgwalters]

See https://github.com/coreos/bootupd/pull/543 (not totally proud of it, kind of hacky but...) anyways this is now updated to also take ownership of most of the grub config, what's left here is platform.cfg stuff.

I wonder if this PR would be better off actually just fully deleting the old code? Landing now would make it easier to test locally, but only slightly. The patch here would be way less ugly if it was 70% deletions instead.

[cgwalters]

OK this now builds on https://github.com/coreos/bootupd/pull/543 and https://github.com/coreos/ignition/pull/1728 And I've reworked it to just completely delete the old code. We can land this once we've updated bootupd and ignition in fcos (ugh I guess all the way to stable?) and tagged into rhcos.

[openshift-ci[bot]]

@cgwalters: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/rhcos	ed7fce9c460e67ed56c8a75d785a85d366f64fbd	link	true	/test rhcos

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[openshift-merge-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cgwalters]

I guess one option is to basically close this PR and aim to try to cut over to osbuild in https://github.com/coreos/coreos-assembler/pull/3643 ?

[dustymabe]

I think this PR is still useful. I wanted to get back to it and run it through some tests on multi-arch in the staging pipeline.

This has also been nice inspiration for @ravanelli who is working on a bootupd stage in osbuild.

[cgwalters]

Right, it was useful to write this to sanity check the bootupd support.

(Incidentally https://github.com/containers/bootc/pull/157 also landed)

[dustymabe]

going to close this out since we are moving away from using create_disk for our disk image creation.