efi: transfer usr/lib/ostree-boot to usr/lib/efi

[HuijingHei]

efi: transfer usr/lib/ostree-boot to usr/lib/efi

This is required by step2 of #926 (comment), with the change, the files under legacy /usr/lib/ostree-boot/efi/EFI will be changed to /usr/lib/efi/<component>/<version>/EFI/.

---

efi: require minimum of 2 components for update metadata generation

Enhance generate_update_metadata() with validation to ensure
at least two packages are provided, preventing the creation of
incomplete or invalid update payloads.
See #994

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[HuijingHei]

Try to find why the CI failed. The CI is fixed now. Ready for review, thank you!

[cgwalters]

Looks sane to me!

[cgwalters]

I think this change was a good idea, but it's caused a multi-day breakage in bootc CI because of the version interlock it creates where older bootupd fails to understand systems whose layout is generated with newer bootupd.

See bootc-dev/bootc#1926

As of right now it seems this change is rolled out to most targets except Fedora 42, but it didn't propagate consistently or quickly of course.

In retrospect, what we probably should have done is made actually applying this change require an opt-in in the base image (config file say), or bootupctl backend install --format=2 or so. It's not strictly speaking too late to do that.

We're also working on bootc-dev/bootc#1816 which will obviate most issues of skew, but it's hard to avoid in the general case.

With format changes again, the key thing is to decouple understanding the change from application of the format.

[HuijingHei]

In retrospect, what we probably should have done is made actually applying this change require an opt-in in the base image (config file say), or bootupctl backend install --format=2 or so. It's not strictly speaking too late to do that.

Besides this, does it make sense to update bootupd on f42 and c9s?

[cgwalters]

I think we should keep c9s and c10s in lockstep by default unless there's a rationale against it.

For f42...well, I just turned off ci for that in bootc and honestly I don't see a good reason to update it by default, so no strong opinion from me.

Again in the end we are likely to fix this more comprehensively in bootc, so it's not urgent.

Though also tangential to this I think it's another case where the intersection between bootc and bootupd is fairly coupled and it could still make sense to do a merge.

[HuijingHei]

In retrospect, what we probably should have done is made actually applying this change require an opt-in in the base image (config file say), or bootupctl backend install --format=2 or so. It's not strictly speaking too late to do that.

Could you help to create such an issue for this?

it could still make sense to do a merge.

Agree!

[travier]

OK let's stop the 0.2.32 release rollout. Sorry I missed this earlier.

In retrospect, what we probably should have done is made actually applying this change require an opt-in in the base image (config file say), or bootupctl backend install --format=2 or so. It's not strictly speaking too late to do that.

Yes, let's do that to make sure we keep existing releases using the current format. We have a change for F44 so we should not change the layout in F43 and C9S at least. Maybe not even C10S but that could be discussed.

With format changes again, the key thing is to decouple understanding the change from application of the format.

+1

[travier]

bootupctl backend install --format=2

I think you meant generate-metadata here