Drop ostree-grub2

[cgwalters]

Since we switched to having the BLS be canonical and use the
ostree.bootloader=none config, we don't need the 15_ostree
stuff.

Drop the ostree-grub2 package and that cruft, finally achieving
what the intention was from the start in having that be a separate
subpackage that was intended as a short term hack.

[martinezjavier]

Looks good to me.

[dustymabe]

LGTM - seems to work fine in local tests.

[jlebon]

Hmm, I thought we still needed this for platforms which still used Anaconda + grub2-mkconfig (notably, ppc64le)? Wasn't that why we couldn't merge coreos/ignition-dracut#91 yet?

[cgwalters]

Hmm, I thought we still needed this for platforms which still used Anaconda + grub2-mkconfig (notably, ppc64le)? Wasn't that why we couldn't merge coreos/ignition-dracut#91 yet?

Ugh yeah you're right...I guess we can just keep it on ppc64le? Is there a tracker issue for what we need to do to get ppc64le on the train and fully drop Anaconda?

[martinezjavier]

Hmm, I thought we still needed this for platforms which still used Anaconda + grub2-mkconfig (notably, ppc64le)? Wasn't that why we couldn't merge coreos/ignition-dracut#91 yet?

The answer here is it depends.

There are two firmware interfaces for ppc64le: OF and OPAL.

For OF, we use grub2 so that means that the blscfg module is available there too.

For OPAL, the bootloader is a Linux kernel with a built-in initramfs that contains a user-space bootloader called petitboot. We added BLS support to petitboot so we shouldn't need the ostree-grub2 package there either.

But since is part of the firmware, it means that we have no control on the version that contains a machine and so it will only work on ppc64le machines using OPAL that don't have an old firmware (BLS support landed in petitboot 1.8.0 that was released on May 30, 2018).

[jlebon]

For OF, we use grub2 so that means that the blscfg module is available there too.

For OPAL, the bootloader is a Linux kernel with a built-in initramfs that contains a user-space bootloader called petitboot. We added BLS support to petitboot so we shouldn't need the ostree-grub2 package there either.

The issue though is that right now we don't embed the static GRUB config with blscfg on ppc64le at all. I thought there was an open PR to switch it over from Anaconda in cosa, but doesn't seem like it.

But since is part of the firmware, it means that we have no control on the version that contains a machine and so it will only work on ppc64le machines using OPAL that don't have an old firmware (BLS support landed in petitboot 1.8.0 that was released on May 30, 2018).

Ouch -- would it be unreasonable to say we require a version new enough for RHCOS/FCOS? Is it regular procedure to update those mini-OSes?

Is there a tracker issue for what we need to do to get ppc64le on the train and fully drop Anaconda?

Yeah, we should probably discuss this in a dedicated tracker issue.

[jlebon]

I opened #174 for the ppc64le revert. Can someone more familiar with the work left on ppc64le open a tracker issue on https://github.com/coreos/fedora-coreos-tracker similar to coreos/fedora-coreos-tracker#255? (@jcajka?)

[cgwalters]

But since is part of the firmware, it means that we have no control on the version that contains a machine and so it will only work on ppc64le machines using OPAL that don't have an old firmware (BLS support landed in petitboot 1.8.0 that was released on May 30, 2018).

Is it possible for users to update that firmware? Can we make doing so a prerequisite to running FCOS?

[martinezjavier]

The issue though is that right now we don't embed the static GRUB config with blscfg on ppc64le at all. I thought there was an open PR to switch it over from Anaconda in cosa, but doesn't seem like it.

I see, sorry for missing that when reviewing this pull-request...

Ouch -- would it be unreasonable to say we require a version new enough for RHCOS/FCOS? Is it regular procedure to update those mini-OSes?

That's what I thought too. The petitboot version is exposed to user-space through a sysfs entry: /sys/firmware/devicetree/base/ibm,firmware-versions/petitboot.

About if the OPAL firmware is regularly updated or not, I would guess that depends on the hardware vendor but @sharkcz should have a better answer.

[martinezjavier]

Is it possible for users to update that firmware? Can we make doing so a prerequisite to running FCOS?

My understanding is that since is Open Firmware in theory users should be able to update it. But in practice vendors could have a fork and this may need to be rebased to latest upstream.

For example in Fedora we don't have packages for OPAL firmware, that's up to the hardware vendor to provide.

Again this is a question for @sharkcz who is more familiar with ppc64le / OPAL and he can correct me if I got anything wrong here.

[sharkcz]

• from enterprise point of view the firmware updates are rare and rely on the HW vendors
• from a community point of view, you can built the firmware and update it yourself at any time, but not all HW has all the firmware sources available

So IMHO you would need a "support matrix" across the available HW. If a firmware with the required new enough versions of the components is available, I think we can require the users to update first for a new project/product like RHCOS/FCOS. The number of different systems isn't large.

[dustymabe]

I think we can require the users to update first for a new project/product like RHCOS/FCOS.

+1000

[cgwalters]

So...it sounds like we can probably drop the anaconda code from cosa? It's not fully clear to me how much we'd need to fix after doing that - hence the request for a tracker issue, but...maybe we can drop it now and leave master broken for ppc64le and have fixups land?

[ajeddeloh]

but...maybe we can drop it now and leave master broken for ppc64le and have fixups land?

I'm not sure if there's anyone who wants to drop it more than I do, but I don't think we should intentionally break master. Plus it would make incremental development / comparing before/after dropping anaconda harder.