Import static grub configuration

[cgwalters]

Pull this from coreos-assembler; prep for moving ownership of it into bootupd.

In the short term, this will allow install tools to copy it manually.

[cgwalters]

Need to change coreos-assembler to do this, see https://github.com/coreos/coreos-assembler/blob/5824720ec3a9ec291532b23b349b6d8d8b2e9edd/src/create_disk.sh#L83

[cgwalters]

There's zero risk to this, it's just shipping some files in a subpackage.

The larger set of work is adding support for importing this into being "owned" by bootupd. But that can come after centralizing the static config into this package, where it can be reused by both osbuild and anaconda style flows.

[jlebon]

Hmm, if we're going to move the GRUB configs, I think they belong better in e.g. https://github.com/coreos/fedora-coreos-config instead. There's a lot of integration points between the two and other distros that want bootupd likely will have their own GRUB config. (I guess we could set up some inheritance here with source, though not sure it's worth the complexity.)

For the update case, we could easily ship an overlay somewhere under e.g. /usr/lib/grubcfgs/ and bootupd could learn to look there.

[cgwalters]

Hmm, if we're going to move the GRUB configs, I think they belong better in e.g. https://github.com/coreos/fedora-coreos-config instead.

The main problem is that doesn't come as an RPM today, and that causes friction with tooling currently oriented towards that as primary input sources (e.g. rpm-ostree compose image and Image Builder namely). It's not that RPMs are amazing or anything, but from the pungi side (which sagano is aiming to integrate with) adding more git repositories complicates the picture and current "hermetic" nature of things.

[jlebon]

We're already going to have to solve the RPM problem for a lot of overlay files we have in https://github.com/coreos/fedora-coreos-config so I'd just glob it as part of that effort. If the goal of bootupd is distro-independence, then IMO it doesn't make sense to have a GRUB config with opinionated things like bootuuid, Ignition firstboot stuff, our RAID1 setup, user dropins, etc...

[cgwalters]

Today, Image Builder has a separate copy of a grub config it uses, see https://github.com/osbuild/osbuild/blob/e48360e01c84ef702b6e5d34a26cedddc55a60c0/stages/org.osbuild.grub2.legacy#L204

And it'd be a giant effort to somehow wedge github.com/coreos/fedora-coreos-config into that. And as far as an RPM package place, given we already have bootupd and the plan is to move ownership there, it really seems simpler to move it here for now.

Other distributions can just ignore it (it's not even installed by default!). Other ostree/container-native distributions don't have the problem with RPM-obsessed build systems 😄

[cgwalters]

OK I dropped out the Ignition glue from this PR, so what we can do is use this even more minimal static version for Sagano work, and rework the version that lives in FCOS to write its additions into platform.cfg instead.

it doesn't make sense to have a GRUB config with opinionated things like bootuuid, Ignition firstboot stuff, our RAID1 setup, user dropins, etc...

bootuuid is used by bootc install today.

Ignition firstboot: dropped!

RAID1: eh...it aligns with also supporting mirrored EFI which we also want in bootupd.

user dropins: Also something desired for anyone using a static grub config I think.

IOW I don't want to block this demo I'm trying to put together of installing a Sagano container w/Anaconda (and bootupd) on refactoring the FCOS structure entirely by packaging fedora-coreos-config. And even if we did that, the converse is true that Sagano grub.cfg shouldn't have Ignition, so we still need two versions.

Hence I think this model of changing FCOS to inherit from this version should work out well.

[cgwalters]

Incidentally also, this project is still currently hardcoded to work with RPM #468 which is a far larger distro-independence problem, and one that will be hard to get away from. There's just going to be some ugly distro stuff in this project probably forever.

[jlebon]

Yeah, that looks better. A bit apprehensive about setting up more inheritance chains here for this but I'm cool also evaluating the full impact when we get to this in FCOS land if this is considered demo/WIP material.

Again, what I think we should aim for is to have GRUB logic located closer to the code that leverages it. E.g. the thing that writes the bootuuids is called by f-c-c. A lot, but not all, of password and Ignition integration live in f-c-c. Once we get to the packaging hurdle, these things would go together.

Having the update mechanism live in bootupd sounds great, and then f-c-c can leverage that by placing its file in some predefined directory or something?

[cgwalters]

E.g. the thing that writes the bootuuids is called by f-c-c.

Only in a "golden image" case. The Anaconda and bootc paths want to ensure that the system is set up properly with uuids from the start.

(And actually, I want to change Anaconda to use bootc install-to-filesystem which would then mean it's only bootc)

[cgwalters]

/override continuous-integration/jenkins/pr-merge

[openshift-ci]

@cgwalters: Overrode contexts on behalf of cgwalters: continuous-integration/jenkins/pr-merge

In response to this:

/override continuous-integration/jenkins/pr-merge

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]

Also thanks for the review and debate here! It's a tricky topic we're navigating and I think while the debate felt contentious at first I actually think the result ended up working well! Or at least it hopefully will 😄

[cgwalters]

Also xref https://github.com/osbuild/osbuild/blob/4e5de3808e2bf56e1060937c4d5e1796df441fa4/stages/org.osbuild.grub2#L280