[4.0] rpm-ostree 2026.1: `rpm-ostree upgrade` exits 0 without a new deployment on bootc hosts (upstream #5567, fixed in 2026.2)

[JayDoubleu]

Describe the bug

Azure Linux 4.0 ships rpm-ostree-2026.1-4.azl4 (preview repo; the 4.0 branch spec is at 2026.1). On a host installed with bootc install from an Azure Linux 4.0 bootc image, rpm-ostree upgrade pulls the new container image and exits 0 without staging a deployment. It prints no message. The result is the same with and without layered packages.

This is upstream rpm-ostree issue coreos/rpm-ostree#5567, fixed by coreos/rpm-ostree#5569 (commit 242903283b, with the follow-up a194bf5375 for the "No upgrade available." message). The fix is in rpm-ostree 2026.2 and later. Version 2026.1 has an early return in deploy_transaction_execute (src/daemon/rpmostreed-transaction-types.cxx) that ignores the changed base image for container origins.

To Reproduce

1. Build a bootc image from mcr.microsoft.com/azurelinux-beta/base/core:4.0 with kernel bootc ostree bootupd rpm-ostree and the bootloader packages from the preview repo. Push it to a registry.
2. Install it with bootc install to-disk and boot the host.
3. Push a changed image under the same tag.
4. On the host run rpm-ostree upgrade.

Output:

Pulling manifest: ostree-image-signed:docker://10.0.2.2:5000/azurelinux-bootc:dev

Exit code 0. rpm-ostree status shows no new deployment. journalctl -u rpm-ostreed shows only "Fetching ostree-image-signed:docker://..." and "Txn Upgrade ... successful".

bootc upgrade on the same host stages the new image. rpm-ostree deploy sha256:<digest> and rpm-ostree rebase ostree-image-signed:docker://.../azurelinux-bootc@sha256:<digest> also work, so the pull path is fine and only the upgrade transaction is affected.

Versions: rpm-ostree-2026.1-4.azl4, bootc-1.13.0-4.azl4, ostree-2025.7-5.azl4, kernel 6.18.45-1.3.azl4, x86_64.

Expected behavior

rpm-ostree upgrade stages the new image, or prints "No upgrade available." when there is none.

Request

Update rpm-ostree to 2026.2 or later on the 4.0 branch, or backport commits 242903283b and a194bf5375 from upstream.

[eric-desrochers]

Thanks for bringing this bug to our attention. I'll pass it along to our development team for evaluation. We're still actively developing and refining the product, so please bear with us as we work through this issue.

In the meantime, have you also reported this against Fedora 43? Since we fork the package from Fedora, and Fedora 43 appears to be on 2026.1 as well, it may be worth tracking the issue upstream too:
Fedora 43 rpm-ostree spec file

Our preference is to stay aligned with upstream whenever possible. Keeping the same version as Fedora helps us avoid introducing downstream divergence.

[JayDoubleu]

Thanks. Fedora 43 already has the fix, so there is nothing to report there.

Fedora 43 is still on rpm-ostree 2026.1, but in March and April Fedora added the two upstream patches to its 43 branch without bumping the version:

• rpm-ostree-2026.1-2.fc43, stable since 2026-03-13, backport of Fix silent upgrade failure on container systems coreos/rpm-ostree#5569 (the silent upgrade failure)
• rpm-ostree-2026.1-3.fc43, stable since 2026-04-05, backport of deploy: Print status message on container early-return path coreos/rpm-ostree#5575 (the "No upgrade available." message)

Azure Linux 4.0 builds rpm-ostree-2026.1-4.azl4 from the Fedora 43 dist-git as of the 2026-02-24 snapshot. That is before both patches, so Azure Linux has the bug and Fedora does not.

Two ways to pick up the fix, both aligned with Fedora:

1. Wait for the next global Fedora 43 snapshot bump past 2026-03-20. rpm-ostree then refreshes with the two patches on its own.
2. Pin rpm-ostree to the current Fedora 43 head now, which is what [4.0] rpm-ostree: pin to Fedora 43 head with the fix for the silent upgrade failure on bootc hosts #18804 does: the same version and the same two patches that Fedora ships, no Azure Linux-specific code, and the pin can be dropped as soon as the snapshot catches up.

The rebuilt package from #18804 passed an install, upgrade and rollback loop on a bootc host, with and without a layered package.

[eric-desrochers]

Thanks Jay, glad to hear Fedora:43 already fixed it.

ADO reference: 23866 assigned to our dev team for continuity.