stable

rpm-ostree-2024.9-1.fc40

FEDORA-2025-0a378044f0 created by walters a month ago for Fedora 40

How to install

Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:

sudo dnf upgrade --refresh --advisory=FEDORA-2025-0a378044f0

This update has been submitted for testing by walters.

a month ago

This update's test gating status has been changed to 'ignored'.

a month ago

This update has been pushed to testing.

a month ago

walters edited this update.

a month ago
User Icon jeckersb provided feedback a month ago
karma

This update has been submitted for stable by bodhi.

a month ago
karma

This update has been pushed to stable.

a month ago
User Icon adamwill commented & provided feedback a month ago
karma

I think this broke ISO installs. We don't actually run openQA tests on rpm-ostree updates (I should fix that...), but since this went stable, the next F40 update tested failed: https://openqa.fedoraproject.org/tests/overview?distri=fedora&groupid=2&build=Update-FEDORA-2025-e38a38bec0&version=40 . The failure seems consistent - I've re-run the tests multiple times and they also failed the same on staging. In the install logs we see:

18:44:24,027 WARNING org.fedoraproject.Anaconda.Modules.Payloads:INFO:anaconda.modules.common.task.task:Configure OSTree bootloader
18:44:24,081 WARNING org.fedoraproject.Anaconda.Modules.Storage:DEBUG:blivet:             DeviceTree.get_device_by_name: name: vda ; incomplete: True ; hidden: True ;
18:44:24,195 WARNING brltty:unsupported generic resource identifier: bluetooth:
18:44:24,199 WARNING org.fedoraproject.Anaconda.Modules.Storage:DEBUG:blivet:             DeviceTree.get_device_by_name returned existing 15 GiB disk vda (13) with existing gpt disklabel
18:44:24,203 WARNING org.fedoraproject.Anaconda.Modules.Payloads:INFO:program:Running in chroot '/mnt/sysroot'... bootupctl backend install --auto --write-uuid --update-firmware --device /dev/vda /
18:44:24,269 WARNING org.fedoraproject.Anaconda.Modules.Payloads:INFO:program:error: boot data installation failed: installing component EFI: No update metadata for component EFI found
18:44:24,269 WARNING org.fedoraproject.Anaconda.Modules.Payloads:DEBUG:program:Return code: 1
18:44:24,269 WARNING org.fedoraproject.Anaconda.Modules.Payloads:INFO:anaconda.core.threads:Thread Failed: AnaTaskThread-ConfigureBootloader-1 (140461697431232)

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 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?

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

Note, I think what matters here is what's in the installer environment, not what's in the payload it's deploying. I'll look at the answers to the questions shortly, but my guess is this causes bootupd to be in the installer environment when it was not before. that shouldn't be hard to check once I've had lunch.

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.

So in the 'success' case, bootc is not in the installer environment and bootupd is not in the ostree (it's a Silverblue ostree). In the 'failure' case, bootc is in the installer environment and bootupd is in the ostree.

anaconda's conditional seems to just depend on whether bootupd is in the installed system root (so, the ostree):

def have_bootupd(sysroot):
    """Is bootupd/bootupctl present in sysroot?"""
    return os.path.exists(join_paths(sysroot, "/usr/bin/bootupctl"))

    def run(self):
        if have_bootupd(self._sysroot):
            self._install_bootupd()
        else:
            self._move_grub_config()
        self._set_kargs()

so, it's the presence of bootupd in the ostree that triggers the problem, I guess.

So in the 'success' case, bootc is not in the installer environment and bootupd is not in the ostree (it's a Silverblue ostree). In the 'failure' case, bootc is in the installer environment and bootupd is in the ostree.

anaconda's conditional seems to just depend on whether bootupd is in the installed system root (so, the ostree):

def have_bootupd(sysroot):
    """Is bootupd/bootupctl present in sysroot?"""
    return os.path.exists(join_paths(sysroot, "/usr/bin/bootupctl"))

    def run(self):
        if have_bootupd(self._sysroot):
            self._install_bootupd()
        else:
            self._move_grub_config()
        self._set_kargs()

so, it's the presence of bootupd in the ostree that triggers the problem, I guess.

Also, it does make sense to me that bootupd was not in the ostree before, because it's explicitly commented out on the f40 branch of workstation-ostree-config: https://pagure.io/workstation-ostree-config/blob/f40/f/fedora-common-ostree.yaml#_12

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

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.


Please login to add feedback.

Metadata
Type
unspecified
Karma
2
Signed
Content Type
RPM
Test Gating
Autopush Settings
Unstable by Karma
-1
Stable by Karma
2
Stable by Time
14 days
Dates
submitted
a month ago
in testing
a month ago
in stable
a month ago
modified
a month ago
approved
a month ago

Automated Test Results