More in https://src.fedoraproject.org/rpms/bootc/pull-request/112

Why was the repeated negative feedback here ignored? https://bodhi.fedoraproject.org/updates/FEDORA-2026-8ff894a3df#comment-4503686

This should appear in the updated quay.io/fedora/fedora-bootc:41 in a day or two at most

There was a regression in this one, fixed in FEDORA-2025-121a0d0b99

Looks like it's

[    6.112433] (sd-exec-[762]: /usr/lib/systemd/system-generators/ostree-system-generator failed with exit status 127.

Except we aren't getting logs from generators by default, but let's look at what changed in that code since the last release

This update has been unpushed.

Something like this (not tested locally yet)

diff --git a/bootc.spec b/bootc.spec
index 6d833bc..61eaf61 100644
--- a/bootc.spec
+++ b/bootc.spec
@@ -1,5 +1,9 @@
 %bcond_without check
+%if 0%{?rhel} >= 10 || 0%{?fedora} > 41
 %bcond_without ostree_ext
+%else
+%bcond_with ostree_ext
+%endif

 %if 0%{?rhel}
     %bcond_without rhsm

It's because you merged the rawhide branch into f41 https://src.fedoraproject.org/rpms/bootc/c/367bdba45f49cda1279600f1385d06e2c30a47ca?branch=f41 which flipped on the conditional.

I guess though having the branches separate is too painful and we should make the bconds have fedora version conditionals instead.

But it'd also work to revert https://src.fedoraproject.org/rpms/bootc/c/50bd1d9415ab42a263ff651a2ca5cff328450bb1?branch=f41 on the f41 branch

Will only re-land after we've merged https://github.com/ostreedev/ostree/pull/3366

This update has been unpushed.

https://pagure.io/workstation-ostree-config/pull-request/600

Ahhh man I was confused by finding it there, I didn't realize it was commented out.

Also of course I was looking at the container image quay.io/fedora/fedora-silverblue:40 but that already pulled this update, so of course it has bootupd.

If there's a way we can strengthen that to make it block bootupd despite the Recommends, that might be the best fix.

Yes there is. I will submit a patch.

Note, I think what matters here is what's in the installer environment, not what's in the payload it's deploying.

So, that is an interesting point because Anaconda required rpm-ostree, and it does now mean that bootc and bootupd will be pulled into the Anaconda environment. However...again in theory, having bootupd in the Anaconda environment itself should be irrelevant. See https://github.com/rhinstaller/anaconda/blob/91fe91ad6f03903114e6637d792b8d7caa679103/pyanaconda/modules/payloads/payload/rpm_ostree/util.py#L26 which looks at the target root, not the host environment.

The key thing should really be in the payload.

Also in a previous successful run, do the Anaconda logs show bootupd being used or not?

Trying to re-sever the rpm-ostree -> bootc requirement will be extremely messy right now. Not impossible, but really messy. So let's look at the bootc -> bootupd link.

Actually bootc today just Recommends: bootupd. So we could aim to explicitly exclude that package in the f40 workstation configs.

Except no wait, f40 workstation does include bootupd. What ostree ref or container image is this test case installing?

That failure is in bootupd, which is an independent project from rpm-ostree. It's not impossible that this change is related, but unlikely.

That test is for Silverblue it seems - there's an ongoing effort to enable bootupd there that might have gone wrong somehow? Although I don't see much at https://pagure.io/workstation-ostree-config/commits/f40

Hmm...oh actually, I think I may know what happened here. We changed rpm-ostree to Requires: bootc in this release. bootc Requires: bootupd. And Anaconda detects whether bootupd is installed in the image and uses it to determine whether or not it should be used.

I think for f40 I can unwind that requirement...but ugh, messy. We really should have had a different way to tell Anaconda to use bootupd (probably by querying whether it has anything in the update payloads).

Trying to look myself I see that https://openqa.fedoraproject.org/tests/3083444# is a recent test that passed.