Bug 2360044 - registry.fedoraproject.org/fedora:latest points to Fedora 41
Summary: registry.fedoraproject.org/fedora:latest points to Fedora 41
Keywords:
Status: ON_QA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedfind
Version: 43
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Adam Williamson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 2322468
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-04-16 05:10 UTC by Benjamin Gilbert
Modified: 2026-02-15 01:28 UTC (History)
2 users (show)

Fixed In Version:
Clone Of: 2322468
Environment:
Last Closed:
Type: Bug
Embargoed:
fedora-admin-xmlrpc: mirror+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FC-3106 0 None None None 2026-02-06 18:21:32 UTC

Description Benjamin Gilbert 2025-04-16 05:10:23 UTC
+++ This bug was initially created as a clone of Bug #2322468 +++

Description of problem:
Fedora 42 has been released but registry.fedoraproject.org/fedora:latest is still Fedora 41.

Version-Release number of selected component (if applicable):
n/a

How reproducible:
Always

Steps to Reproduce:
1. podman run --pull=always -ti --rm registry.fedoraproject.org/fedora:latest cat /etc/fedora-release

Actual results:
Fedora release 41 (Forty One)

Expected results:
Fedora release 42 (Forty Two)

Additional info:
This seems to happen on almost every Fedora release.  Can we do something to make sure it doesn't?

Comment 1 Adam Williamson 2025-04-16 05:58:19 UTC
it should be fixed automatically in a couple of hours, when the next nightly compose runs. The 20250515 compose ran at 7:15 UTC, before I updated the release source-of-truth used by cloud-image-uploader to mark F42 as stable, so the image uploader didn't apply the 'latest' tag when uploading that compose. It should do for the next compose.

Comment 2 Benjamin Gilbert 2025-04-16 06:17:54 UTC
Thanks, Adam.  Is there any process change we could make so :latest gets updated at the same time as the Fedora release?

Comment 3 Adam Williamson 2025-04-16 06:25:59 UTC
well, not *really*, no, because we don't time things so a Cloud compose is completing at the exact moment the release goes live, and the thing that syncs cloud images to registries (and updates the latest tag, if appropriate) runs when a compose completes.

I mean, I guess we could add a manual step to the release SOP to do a manual registry edit to change the 'latest' tag to point to the most recent images for the new release, I guess, but we'd have to figure out the command(s) and credentials to use. It's not totally trivial since we're using multi-image manifests. We could *probably* just use skopeo to download the manifest for the fedora:42 (or whatever) tag and reupload it unmodified as fedora:latest , but I'm just whiteboarding there, I haven't tried it to see if there are any bear traps. It was enough of a pain writing the stuff to do it automatically.

Comment 4 Adam Williamson 2025-04-16 07:08:50 UTC
there's a few ways we could have the uploader sync the compose done early on release day, potentially. the easiest is just to have someone update the fedfind metadata before that compose completes. it's not safe to update it before the bitflip, but I *think* it's safe to update it any time after the bitflip. I just usually update it when I wake up on release day because that's what I'm used to doing.

Comment 5 Adam Williamson 2025-04-16 18:01:26 UTC
ugh. i wake up, and f41 is still latest (on quay.io and I presume r.f.o too). not sure why. will try and figure it out.

Comment 6 Adam Williamson 2025-04-16 18:33:07 UTC
uf, right, there's a instance-level cache of the release metadata in fedfind which expires in one day. I forgot I wrote that. I *suspect* that maybe we got cached data where F41 was still 'current', when we published today's F42 containers. I kinda wanna leave it one more day and see if it gets it right next time.

Comment 7 Adam Williamson 2025-04-18 07:19:23 UTC
ok, yeah, *now* it's right, latest points to 42. so, a combination of the timing of the metadata update, and the fedfind instance cache of that metadata. i'll see if I can come up with anything to improve this next time.

Comment 8 Fedora Update System 2026-02-06 18:19:10 UTC
FEDORA-2026-be03969526 (fedfind-6.1.4-1.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-be03969526

Comment 9 Fedora Update System 2026-02-06 18:19:10 UTC
FEDORA-2026-04f7655da7 (fedfind-6.1.4-1.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-04f7655da7

Comment 10 Fedora Update System 2026-02-07 01:28:34 UTC
FEDORA-2026-be03969526 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-be03969526`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-be03969526

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2026-02-07 01:53:48 UTC
FEDORA-2026-04f7655da7 has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-04f7655da7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-04f7655da7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2026-02-15 01:11:58 UTC
FEDORA-2026-be03969526 (fedfind-6.1.4-1.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Fedora Update System 2026-02-15 01:28:47 UTC
FEDORA-2026-04f7655da7 (fedfind-6.1.4-1.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.