Issues rebasing to stock Fedora Kinoite from a Universal Blue image: Server returned HTTP 404

Ask Fedora
,
1

So I’ve been using an image based on Universal Blue’s kinoite-main for a while, and I am now trying to rebase back to the stock Fedora Kinoite image.

I was able to successfully rebase to the unsigned version of the image from quay.io (ostree-unverified-registry:quay.io/fedora/fedora-kinoite:latest), but I’m having great difficulty in rebasing to the main signed stock remote (fedora: fedora/44/x86_64/kinoite).

Firstly, the Universal Blue image removed all the fedora remote references. I was able to add them back with ostree remote add ..., but trying to rebase from the remote leads me to a 404 error from ostree.fedoraproject.org:

$ rpm-ostree status
rpm-ostree status
State: idle
Deployments:
● ostree-unverified-registry:quay.io/fedora/fedora-kinoite:latest
         Digest: sha256:079f493ebc3ddf75de92e1d53e908fa5b9269dc40634c0b9bbf9c0322840d4a4
        Version: 44.20260827.0 (2026-08-27T00:34:17Z)
...

$ rpm-ostree rebase fedora:fedora/44/x86_64/kinoite 
Receiving metadata objects: 2/(estimating) 225 bytes/s 903 bytes... done 
error: While pulling fedora/44/x86_64/kinoite: While fetching https://ostree.fedoraproject.org/objects/19/7beecf02587f7d9c9dd80e97fd0b2af624737c363079868818daadc3
d30c27.commit: Server returned HTTP 404

I compared my system state with a fresh up-to-date install of Fedora Kinoite in a virtual machine, and it is on the the same commit as indicated by the hash that my host install is unable to fetch:

[vm] $ rpm-ostree status
State: idle
Deployments :
● fedora: fedora/44/x86_64/kinoite
          Version: 44.20260828.0 (2026-08-28T00:34:21Z)
           Commit: 197beecf02587f7d9c9dd80e97 fddb2af624737¢363079868818daadc3d30c27
     GPGSignature: Valid signature by 36F612DCF27F7D1A48A835E4DBFCF71C6D9F90A6

NOTE: The above output was sent through Spectacle’s text extraction from a screenshot of the VM console window, as I was unable to directly copy the text output out of the VM console. If there’s any typos in the hashes or signature, it’s probably an OCR error.

I’m not sure what I’m missing here. As it stands, the ostree remotes and the container-policy.json in both the VM and my host system are identical – the 404 might indicate a service issue with the endpoint, but I find that unlikely since I was able to successfully upgrade the system in the VM.

I could also completely reinstall Kinoite to ensure a known good configuration, but I’d like to avoid that if at all possible, as reloading all my user configuration would be very time-consuming.

Any help would greatly be appreciated :slight_smile:

EDIT: Also for reference, my ostree remotes are set up as the following (both test VM and host):

$ ostree remote list -u
fedora          https://ostree.fedoraproject.org
fedora-compose  https://kojipkgs.fedoraproject.org/compose/ostree/repo/

I’ve added them back to my host system with these commands:

$ sudo ostree remote add fedora https://ostree.fedoraproject.org
$ sudo ostree remote add fedora-compose https://kojipkgs.fedoraproject.org/compose/ostree/repo/
2

Yes, the 2 commits on the host and VM machines seem to be identical (apart from the obvious OCR typos).

Only for troubleshooting reasons, do you get the same error when rebasing to Silverblue?

3

SOLUTION AT THE END

Thanks for the reply! I tried rebasing to Silverblue on my host machine, and got the same issue:

[host] $ rpm-ostree rebase fedora:fedora/44/x86_64/silverblue
Receiving metadata objects: 2/(estimating) 225 bytes/s 903 bytes... done
error: While pulling fedora/44/x86_64/silverblue: While fetching https://ostree.fedoraproject.org/objects/aa/d4969ea41a17cc9c2d4a0eebc3d34e703c10ceeae47fd681dc7b3234ad943d.commit: Server returned HTTP 404

In the VM, rebasing to Silverblue with the same command doesn’t hit any 404s.

I suspect that the Universal Blue image may have changed some configuration on how remote image objects links are determined, although I have no idea where that would be configured from.

I then experimentated with disconnecting the VM from the internet both before the reabse command and partway through it, to try and force an error message showing what it was trying to connect to. I got these errors:

VM internet disconnected before rebase:

error: While pulling fedora/44/x86_64/silverblue: While fetching mirrorlist 'https://ostree.fedoraproject.org/mirrorlist': While fetching https://ostree.fedoraproject.org/mirrorlist: [6] Could not resolve hostname

VM internet disconnected during rebase:

error: While pulling fedora/44/x86_64/silverblue: While fetching https://d2ukShbyrobdzx.cloudfront.net/objects/80/3c58fSbe2d49b4ee771ed0311cacd79e63001b61339f6ac31ffala9abe6447.dirtree: [6] Could not resolve hostname

Again, there may be OCR issues from Spectacle.

Checking in a browser, https://ostree.fedoraproject.org/mirrorlist points to https://d2ukShbyrobdzx.cloudfront.net[1], which in turn points to the correct object links. I also noticed that when I was trying to rebasing on the host machine, it appears to make no attempt to read from a mirrorlist.

This now strongly points to an issue of some mirrorlists on my host not being properly set up. Looks like some more investigation is in order.

Alright I think I’ve found a solution!

Doing some grepping around on /etc (as well as from this post: Mirrorlist-missing error on kinoite update - #4 by miabbott) I appear to have missed adding the mirrorlist when adding the Fedora remotes.

In the VM, the /etc/ostree/remotes.d/fedora.conf contains the mirrorlist information, as well as some other metadata that my host was missing.

I added the lines to my host config, et voilà, rebasing to the stock Kinoite remote went perfectly!

  1. I suspect this is some rotating CDN endpoint. ↩︎