Skip to content

tracker: Rebase onto Fedora 45 #2127

Open
Open
tracker: Rebase onto Fedora 45#2127
Labels
F45area/platformskind/enhancement
@marmijo

Description

@marmijo
marmijo
opened on Mar 31, 2026

Rebase to a new version of Fedora (N=45)

At previous Fedora major release

Open tickets to track related work for this release

At the first change checkpoint

Untag old packages

koji untag N-2 packages from the pool (at some point we'll have GC in place to do this for us, but for now we must remember to do this manually or otherwise distRepo will fail once the signed packages are GC'ed). For example the following snippet finds all RPMs signed by the Fedora 32 key and untags them. Use this process:

  • Find the key short hash. Usually found here. Then:
f32key=12c944d0
key=$f32key
echo > untaglist # create or empty out file
for build in $(koji list-tagged --quiet coreos-pool | cut -f1 -d' '); do
    if koji buildinfo $build | grep -i $key 1>/dev/null; then
        echo "Adding $build to untag list"
        echo "${build}" >> untaglist
    fi
done

Now we have a list of builds to untag. But we need a few more sanity checks.

  • Make sure none of the builds are used in N based FCOS. Check by running:
f32key=12c944d0
key=$f32key
podman run -it --rm quay.io/fedora/fedora-coreos:testing-devel rpm -qai | grep -i -B 9 $key
podman rmi quay.io/fedora/fedora-coreos:testing-devel

If there are any RPMs signed by the old key they'll need to be investigated. Maybe they shouldn't be used any longer. Or maybe they're still needed. One example of this is the shim RPM where the same build could be used for many Fedora releases. In this case you'll need to untag the RPM from coreos-pool, run a koji distrepo, which will remove that RPM from the repo metadata, and then re-tag it into the pool. The RPM in the repo will now be signed with a newer signing key.

  • After verifying the list looks good, untag:
# use xargs so we don't exhaust bash string limit
cat untaglist | xargs -L50 koji untag-build -v coreos-pool

  • Now that untagging is done, give a heads up to rpm-ostree developers that N-2 packages have been untagged and that they may need to update their CI compose tests to freeze on a newer FCOS commit.

  • Remove the N-2 signing key from the tag info for the coreos-pool tag. The following commands view the current settings and then update the list to the 33/34/35 keys. You'll most likely have to get someone from releng to run the second command (edit-tag).

    • koji taginfo coreos-pool
    • koji edit-tag coreos-pool -x tag2distrepo.keys="9570ff31 45719a39 9867c58f"

At Branching

Branching is when a new stream is "branched" off of rawhide. This eventually becomes the next major Fedora (N).

Release engineering changes

  • Verify that a few tags were created when branching occurred:

  • f${N+1}-coreos-signing-pending

  • f${N+1}-coreos-continuous

  • Add and tag a package (any package) which is in the stable repos into the continuous tag. This will create the initial yum repo that's used as input for building the COSA container.

  • koji add-pkg --owner ${FAS_USERNAME} f${N+1}-coreos-continuous $PKG

    • example: koji add-pkg --owner dustymabe f36-coreos-continuous fedora-release
    • This example uses the fedora-release RPM, but it could be any other.

  • koji tag-build f${N+1}-coreos-continuous $BUILD

    • example: koji tag-build f36-coreos-continuous fedora-release-36-0.16

  • Add the N+1 signing key short hash (usually found here) to the tag info for the coreos-pool tag. The following commands view the current settings and then update the list to the 32/33/34/35 keys. You'll most likely have to get someone from releng to run the second command (edit-tag). An example request looks like this.

    • koji taginfo coreos-pool
    • koji edit-tag coreos-pool -x tag2distrepo.keys="12c944d0 9570ff31 45719a39 9867c58f"

coreos-installer changes

Example PR: coreos/coreos-installer#1113

Update rawhide stream

Enable branched stream

At Fedora (N) Beta

Update fedora-coreos-config next-devel

  • Bump VERSION, MUTATE_OS_RELEASE, BUILDER_IMG in build-args.conf

  • Add the fedora-candidate-compose repo in manifest.yaml (example PR)

  • Update the repos in manifest.yaml if needed

  • Run cosa fetch --dry-run --update-lockfile

    • this updates the x86_64 lockfile - the others will get updated when bump-lockfile runs.
    • in the future we may support this in cosa fetch directly

  • PR the result

  • Re-enable next-devel if needed (docs)

  • Disable branched stream since it is no longer needed.

    • Update config.yaml to comment out the branched stream definition.

Prepare Fedora CoreOS (N) Beta announcement

  • Draft an announcement that contains information found in the "Communications Tracker", created in a step above, to inform users of Fedora CoreOS of upcoming changes in the Fedora (N) version. (example)

Ship rebased next

  • Ship next
  • Set a new update barrier for the final release of N-1 on next. In the barrier entry set a link to the docs. See discussion

Preparing for Fedora (N) GA

Do these steps as soon as we have a Go confirmation for GA, usually the Thursday of the week before GA.

Ship a final next release

If the packages in next-devel don't exactly match the last next release that was done, we need to do a release with the final GA content. This ensures that what we'll promote to testing has the exact content in GA (plus version fast-tracks). This usually happens on the Thursday of the announcement of Go.

  • Ensure final next release has GA content

Build rebased testing and final stable release on N-1

  • Build stable; promote it from the testing branch, which should still be on N-1. Don't release it yet (i.e. don't run the release job).
  • Build testing; promote it from the next branch instead of testing-devel. Don't release it yet (i.e. don't run the release job).

Update fedora-coreos-config testing-devel

  • Bump VERSION, MUTATE_OS_RELEASE, BUILDER_IMG in build-args.conf
  • Update the repos in manifest.yaml if needed
  • Sync the lockfiles for all arches from next-devel
  • Bump the base Fedora version in ci/buildroot/Dockerfile
  • Bump the Fedora version for the test containers in tests/kola/data/commonlib.sh
  • PR the result

At Fedora (N) GA

Do these steps on GA day.

Release rebased testing and final stable release on N-1

  • Run the release job for the staged testing and stable builds and start rollout.
  • Set a new update barrier for the final release of N-1 on testing. In the barrier entry set a link to the docs. See discussion

Disable next-devel stream if not needed

We prefer to disable next-devel when there is no difference between testing-devel and next-devel. This allows us to prevent wasting a bunch of resources (bandwidth, storage, compute) for no reason. After the switch to N if next-devel and testing-devel are in lockstep, then disable next-devel.

  • Follow the instructions here to disable next-devel

Switch upstream packages to shipping release binaries from Fedora (N)

Disable the fedora-candidate-compose repo

  • Remove from the manifest.yaml of next-devel the fedora-candidate-compose repo

After Fedora (N) GA

Ship rebased stable

  • Ship stable
  • Set a new update barrier for the final release of N-1 on stable. In the barrier entry set a link to the docs. See discussion

Open ticket for the next Fedora rebase

  • Create a new ticket from the rebase template
    • label with FN label where N is the Fedora version.

Update the FCOS Meeting-Action Template

Now that Fedora N is GA, we need to start tracking the release schedule of Fedora N+1 during the weekly Fedora CoreOS Community Meeting.

Miscellaneous container updates

These are various containers in use throughout our ecosystem. We should update or open a ticket to track updating them once a new Fedora release is out. If you open a ticket instead of doing the update add a link to the ticket as comment.

Metadata

Metadata

Assignees

No one assigned

    Labels

    F45area/platformskind/enhancement

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions