End Of Life

Description

Each release of Fedora is maintained as laid out in the maintenance schedule. At the conclusion of the maintenance period, a Fedora release enters END OF LIFE status. This procedure describes the tasks necessary to move a release to that status. To get the correct EOL date visit the release schedule for the latest release.

Actions

Reminder Announcement

A week before the EOL date send an email to the devel-announce@, test@, test-announce@, and announce@ mailing lists as a reminder about the release EOL.

Hello all,

Fedora Linux 42 will go end of life for updates and support on
YYYY-MM-DD.
No more updates of any kind, including security updates or security
announcements, will be available for Fedora Linux 42 after this
date. No pending updates for Fedora Linux 42 will be pushed to stable.

Fedora Linux NN+1 will continue to receive updates until approximately
one month after the release of Fedora Linux NN+3. The maintenance
schedule of Fedora Linux releases is documented here[1]. The docs also
contain instructions[2] on how to upgrade from a previous release of
Fedora Linux to a version receiving updates.

Regards,
Fedora Release Engineering

[1] https://docs.fedoraproject.org/en-US/releases/lifecycle/#_maintenance_schedule
[2] https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/

Please ensure that the reminder email is scheduled to be sent one week before the end of life.

`fedora-appstream-metadata` Package Update

This is not necessary if the package already has the correct EOL date.

If the EOL date is not correct then update the fedora-appstream-metadata package with the new EOL date.

This includes changing the date_eol parameter in org.fedoraproject.fedora.metainfo.xml and Version in fedora-appstream-metadata.spec. Open a pull request against the rawhide branch. The main admin of the repository then builds the package and creates an update.

The update must be in the stable repository for the release that is going end of life before proceeding further.

Final Bodhi Stable Push

Do a final stable push for the release in Bodhi, following the Pushing Updates SOP.

Koji Tasks

Disable Builds By Removing Build Targets

koji remove-target f42
koji remove-target f42-candidate
koji remove-target f42-container-candidate
koji remove-target f42-flatpak-candidate
koji remove-target f42-infra
koji remove-target f42-coreos-continuous
koji remove-target f42-rebuild

Remove Existing Sidetags From The EOL Release

for i in `koji list-sidetags --basetag f42`
do
	koji remove-sidetag $i
done

You need to do this differently because just removing the target of a sidetag will leave it in a weird state where it cannot be removed.

Purge Copies Of RPMs Signed With EOL Release Key

Add the release key to the koji_cleanup_signed_rpms.py script.
Run the script on compose-branched01.rdu3.fedoraproject.org.

tmux
sudo su
cd /root/releng
./scripts_new/release-process/end-of-life/koji_cleanup_signed_rpms.py

Running this script in a tmux session is recommended as it takes a long time to finish.

Bodhi Tasks

Run the following Bodhi commands to set the releases state to archived.

bodhi releases edit --name "F42" --state archived
bodhi releases edit --name "F42C" --state archived
bodhi releases edit --name "F42F" --state archived

Fedora Infra Ansible Changes

It is necessary to make several changes in the Ansible repository and run relevant playbooks.

Update `FedoraPreviousPrevious.yaml`

File: /vars/all/FedoraPreviousPrevious.yaml
Set the value to False.

Adjust The EOL For `gnome-software`

File: /roles/pkgdb-proxy/files/pkgdb-gnome-software-collections.json
Set the "status" to "EOL".

Remove EOL Release From `robosignatory` Configuration

File: roles/robosignatory/templates/robosignatory.toml.j2
Remove stanzas that have "fedora-42" in them.

Run The Playbooks

Open a pull request with the above changes.
Run the associated playbooks on batcave01.rdu3.fedoraproject.org:

sudo ansible-playbook /srv/web/infra/ansible/playbooks/groups/bodhi-backend.yml
sudo ansible-playbook /srv/web/infra/ansible/playbooks/groups/koji-hub.yml
sudo ansible-playbook /srv/web/infra/ansible/playbooks/groups/releng-compose.yml
sudo ansible-playbook /srv/web/infra/ansible/playbooks/groups/proxies.yml -t pkgdb2
sudo ansible-playbook /srv/web/infra/ansible/playbooks/openshift-apps/bodhi.yml -t all,rollout
sudo ansible-playbook /srv/web/infra/ansible/playbooks/openshift-apps/greenwave.yml -t all,rollout

You will need to have someone enable sshd on autosign01.rdu3.fedoraproject.org and then run:

sudo ansible-playbook /srv/web/infra/ansible/playbooks/manual/autosign.yml

And then someone with the robosignatory passphrase will need to restart it.

Another way to run the playbook is using the rbac-playbook wrapper in case you are not in sysadmin-main.

Syntax: sudo rbac-playbook groups/bodhi-backend.yml

Final Announcement

Send the final announcement to devel-announce@, test@, test-announce@, and announce@ lists. Use the template from release engineering repo. NOTE: The above template is the same as the reminder announcement. We should revise it and create a separate one.

Other Tasks

Remove EOL Release From `Koschei`

The release going EOL must be removed from Koschei to prevent a flood of failed scratch builds. See the Koschei sysadmin guide for details.

Remove Release From `fedfind` Source Of Truth

The Quality team maintains a source of truth for release information used by the fedfind tool on fedorapeople (people01) in /srv/groups/qa/metadata/release.json. If you have access to this file, you can remove the release going EOL from the file’s list of stable releases. Otherwise, alert the quality team to do so.

Stage The EOL Release To Archive

Log into to bodhi-backend01 and log in as the ftpsync user.

ssh bodhi-backend01.rdu3.fedoraproject.org
sudo su
su - ftpsync

Change into the releases directory.
cd /pub/fedora/linux/releases
Check to see that the target directory doesn’t already exist.
ls /pub/archive/fedora/linux/releases/
Do a recursive rsync to update any changes in the trees since the previous copy.
rsync -avAXSHP ./42/ /pub/archive/fedora/linux/releases/42/

Similarly, sync updates and updates/testing.

cd ../updates/
rsync -avAXSHP 42/ /pub/archive/fedora/linux/updates/42/
cd testing
rsync -avAXSHP 42/ /pub/archive/fedora/linux/updates/testing/42/

Do the same with fedora-secondary.

cd /pub/fedora-secondary/releases/
rsync -avAXSHP ./42/ /pub/archive/fedora-secondary/releases/42/
cd ../updates/
rsync -avAXSHP 42/ /pub/archive/fedora-secondary/updates/42/
cd testing
rsync -avAXSHP 42/ /pub/archive/fedora-secondary/updates/testing/42/

Update update-fulltimelist for archives.
sudo -u ftpsync /usr/local/bin/update-fulltimelist -l /pub/fedora/update-fulltimelist.lock -t /pub archive
This job runs every 2 hours and updates mirror metadata. Once it has completed and mirrors have picked up the change, it is safe to proceed with the move-to-archive script.
Announce to the mirror list (mirror-admin@) that this has been done and that in 2 weeks the old content will be moved to the archive.

Hello mirror admins,

Fedora Linux 42 has now reached end of life and has been successfully
staged to the archive locations. The archived content is now available
under:

/pub/archive/fedora/linux/releases/42
/pub/archive/fedora/linux/updates/42
/pub/archive/fedora/linux/updates/testing/42
/pub/archive/fedora-secondary/releases/42
/pub/archive/fedora-secondary/updates/42
/pub/archive/fedora-secondary/updates/testing/42

This includes all necessary content for releases, updates, and
updates/testing for both the primary and secondary architectures.

In two weeks, we will proceed with removing the Fedora 42 content from
the main mirrors. If there is anything else that we need to take care
of, please let us know so that we may plan accordingly.

Thank you for your continued support and providing access to users around the world.

Best regards,
Your Name
Fedora Release Engineering

Move The EOL Release To Archive

In two weeks, run the following playbook from batcave01.rdu3.fedoraproject.org:

sudo -i ansible-playbook -v /srv/web/infra/ansible/playbooks/manual/mirrormanager/move-to-archive.yml --extra-vars="product='Fedora' version='42'"

If there are problems, the postgres DB may have issues and so you need to get a DBA to update the backend to fix items.
Wait an hour or so then you can remove the files from the main tree.

We need to do a cleanup here for both fedora and fedora-secondary for releases, updates, and updates/testing for the 42 release.

ssh bodhi-backend01
cd /pub/fedora/linux/releases/42
ls
# make sure you have stuff here
rm -rf *
ln ../20/README .
cd /pub/fedora/linux/updates/42
ls
# make sure you have stuff here
rm -rf *
ln ../20/README .
cd /pub/fedora/linux/updates/testing/42
ls
# make sure you have stuff here
rm -rf *
ln ../20/README .

#for fedora-secondary
cd /pub/fedora-secondary/releases/42
ls
# make sure you have stuff here
rm -rf *
ln ../20/README .
cd /pub/fedora-secondary/updates/42
ls
# make sure you have stuff here
rm -rf *
ln ../20/README .
cd /pub/fedora-secondary/updates/testing/42
ls
# make sure you have stuff here
rm -rf *
ln ../20/README .

Consider Before Running

Resource contention in infrastructure, such as outages
Extenuating circumstances for specific planned updates, if any
Send the reminder announcement, if it isn’t sent already

Want to help? Learn how to contribute to Fedora Docs ›