Is it safe to run /usr/bin/bootupctl backend generate-update-metadata in a Containerfile?

[travier]

To fix issues with Fedora Atomic desktops, I'm considering backporting the bootupd inclusion to Fedora 39:

• Boot fails with "vmlinuz has invalid signature" or "bad shim signature, you need to load the kernel first" fedora-silverblue/issue-tracker#543
• https://gitlab.com/fedora/ostree/sig/-/issues/1

While thinking about that, I wondered if it would be able to create layered images with bootupd included in a layer.

Is it safe to run /usr/bin/bootupctl backend generate-update-metadata from a container layer?

FROM quay.io/fedora-ostree-desktops/kinoite:40

RUN rpm-ostree install bootupd \
    &&\
    /usr/bin/bootupctl backend generate-update-metadata \
    && \
    ostree container commit

I'll do some testing.

[cgwalters]

Offhand, I think so.

[travier]

I did that for a while in travier/fedora-kinoite@7e3df8d and it worked fine.

[fiftydinar]

Running this in Containerfile makes /usr/lib/ostree-boot/efi/ empty.

Is this normal behavior?

Credits to @bsherman for finding this out

[travier]

Yes, the content is moved to /usr/lib/bootupd/updates. bsherman/ublue-custom@7778989 looks weird and it will likely fail when installing with Ananconda.

What's your issue with /usr/lib/ostree-boot/efi/ being empty?

[bsherman]

What's your issue with /usr/lib/ostree-boot/efi/ being empty?

I noticed the change when trying to use grub2-switch-to-blscfg on an installed system, which failed since the image had bootupctl backend generate-update-metadata.

Yes, the content is moved to /usr/lib/bootupd/updates. bsherman/ublue-custom@7778989 looks weird and it will likely fail when installing with Ananconda.

My naive guess is, if using such an image with bootupd, the service must be started to update grub, rather than using grub2-switch-to-blscfg?

[travier]

You don't need to use grub2-switch-to-blscfg because that's what ostree does by default now and ostree-grub2 generates a config that reads BLS (unless you've explicitly told it not to but it's not the default). Bootupd will update older GRUBs to be able to read BLS.

[bsherman]

You don't need to use grub2-switch-to-blscfg because that's what ostree does by default now and ostree-grub2 generates a config that reads BLS (unless you've explicitly told it not to but it's not the default). Bootupd will update older GRUBs to be able to read BLS.

I see what's happening now. Apologies for the noise on this.

In the past I'd seen this discussion ( https://discussion.fedoraproject.org/t/why-does-grub2-present-twice-double-menuentry-for-each-ostree-entry/73990/8 ) and Universal Blue forums were we'd documented use of grub2-switch-to-blscfg as a way to drop the duplicate boot entries in Grub.

I had NOT seen your recent updates to that discussion, however. Recent questions about the duplicate entries and noticing it reoccurring on my own system caused me to ask some questions.

Since it's clearly expected behavior, I'm content. Thank you for the response!

[travier]

Yes, with an updated GRUB (with BLS support) and dynamic GRUB configs (pre-bootupd) then you'll get duplicated GRUB entries. This will go away once we transition people to static GRUB configs by default, hopefully for F42 but we don't have this ready yet.