Cambios importantes en Fedora CoreOS

Esta es una lista de los cambios principales introducidos en Fedora CoreOS, junto con las notas correspondientes. Estos cambios también se anuncian en la lista de correo coreos-status. Tenga en cuenta que esta no es una lista exhaustiva de los cambios en Fedora CoreOS y solo incluye los cambios principales que pueden requerir acciones manuales. Esta lista está en orden cronológico inverso para mantener los cambios recientes al principio.

Cambiar a actualizaciones de OCI

A partir de Fedora 42, Fedora CoreOS se actualizará mediante imágenes OCI en lugar del repositorio OSTree. Solicitud de cambio de Fedora: https://fedoraproject.org/wiki/Changes/CoreOSOstree2OCIUpdates. Más información: https://github.com/coreos/fedora-coreos-tracker/issues/1823

Planificación

Este cambio se introdujo primero en las nuevas imágenes de disco para el flujo "next", como parte de la actualización a Fedora 42. Los flujos "testing" y "next" se implementarán posteriormente cuando se actualicen a Fedora 42. Tras algunas versiones, migraremos las máquinas existentes mediante una versión de barrera.

Actualizar Flujo Fecha de Lanzamiento

next 42.20250316.1.0

2025-03-18

testing

TBD

stable

Seguirá el testing como usual

Notas

Actualmente, los hosts de Fedora CoreOS obtienen actualizaciones del repositorio OSTree. Con este cambio, los hosts obtendrán actualizaciones del registro de contenedores de Quay.io. Este cambio sería transparente, aunque los entornos proxy requieren atención, ya que los nodos buscarán actualizaciones en una dirección diferente.

Nota: Las imágenes de disco se actualizarán primero, por lo que las nuevas instalaciones de Fedora CoreOS basadas en Fedora 42 usarán imágenes OCI. Tras algunas versiones, migraremos los nodos existentes.

Este cambio solo se aplica al selector a conmutar a OCI como es transporte para contenido de Fedora CoreOS. Admitir derivación aún es un trabajo en progreso, consulte la cuestión de seguimiento para más detalles: https://github.com/coreos/fedora-coreos-tracker/issues/1726

mantenimiento v1 de cgroups inhabilitado

En systemd v256, se inhabilitó la compatibilidad con cgroups v1. Si anteriormente desactivó la migración a cgroups v2, su sistema no podrá arrancar después de la actualización. Debe actualizar los argumentos del kernel antes de la actualización.

Actualice un sistema existente desde cgroupsv1 a cgroupsv2 y reinicie inmediatamente
$ sudo rpm-ostree kargs --delete=systemd.unified_cgroup_hierarchy --reboot

Planificación

Este cambio ha sido implementado como parte de la rebase a Fedora 41.

Transmisión de actualizaciones Fecha de lanzamiento prevista

next

41.20240916.1.0 (16 sep, 2024)

testing

41.20241027.2.0 (28 oct, 2024)

stable

41.20241027.3.0 (8 nov, 2024)

Notas

See: fedora-coreos-tracker/issues#1715.

Detailed description of the change, the impacts, how to test, what manual actions are needed, etc.

Podman v5.0

The Podman container runtime will be upgraded from v4 to v5. This is a major release that removes support for CNI networking in favor of Netavark.

See also the Fedora Change and the tracking issue.

Planificación

This change will be rolled out together with the rebase to Fedora 40.

Update Stream Targeted release date

next

40.20240322.1.0 (Mar 24, 2024)

testing

40.20240416.2.0 (Apr 22, 2024)

stable

40.20240416.3.1 (May 07, 2024)

Notas

The full release notes for Podman v5 are available on GitHub and the breaking changes are explained in Podman 5.0 breaking changes in detail. Here is a summary of how this will impact Fedora CoreOS nodes:

  • CNI networking support has been removed and Netavark is now the only supported option.

  • Pasta is now the default rootless networking backend.

  • In the (unlikely) case that you were using podman machine inside of Fedora CoreOS, you will have to delete and re-create your podman machine. See Migration of Podman 4 to Podman 5 machines for more details.

  • Support for cgroups v1 is deprecated and will removed in a future version.

  • Rollbacks to a previous version with Podman v4.x will likely require manual action.

System console changing to platform-specific defaults

The system console setup will be changed to get a better user experience by default. The new defaults will depend on both the CPU architecture and platform.

The changes will only affect new Fedora CoreOS installations. Upgraded systems will retain their current console settings.

See also the coreos-status announcement.

Planificación

This change will be rolled out progressively:

Update Stream Targeted release date

next

2022-10-03 (37.20221003.1.0)

testing

2022-11-28

stable

Will follow testing as usual

Notas

The current default depends on the CPU architecture:

  • On x86_64, the first serial port ttyS0 is the primary console and the graphical console is secondary.

  • On other architectures, Fedora CoreOS generally does not configure a particular console, leaving the bootloader and kernel to follow their own defaults. This typically means that a graphical console is used if one is available, and a serial console otherwise.

The new defaults will depend on both the CPU architecture and platform. The exact configuration is in platform.yaml (next-devel branch). In summary:

  • On many architecture/platform pairs, Fedora CoreOS will allow GRUB and the kernel to follow their own defaults. On x86_64, this causes the graphical console to be selected, even if no video card is available. In particular, x86_64 bare metal installations will no longer use a serial console by default.

  • On platforms that expect specific system consoles to be used, such as AWS, Azure, and GCP, Fedora CoreOS will select those consoles by default.

  • On OpenStack, VirtualBox, and VMware, Fedora CoreOS will use a primary graphical console but continue providing a serial console for debugging.

  • The QEMU image will continue to select ttyS0 as the primary console and the graphical console as secondary.

If the new defaults aren’t appropriate for your environment, you can override them in several ways. See the Emergency console access documentation page for details.

Podman v4.0

The Podman container runtime will be upgraded from v3 to v4. This is a major release that introduces backward incompatible changes to configuration files and APIs.

See also the Fedora Change and the tracking issue.

Planificación

This change will be rolled out together with the rebase to Fedora 36.

Update Stream Targeted release date

next

2022-03-15

testing

2022-04-19

stable

Will follow testing as usual

Notas

The full release notes for Podman v4 are available on GitHub. Here is a summary of how this will impact Fedora CoreOS nodes:

  • Existing containers will be preserved without any change required.

  • Compatibility for the Docker API is fully preserved.

  • Users of the Podman remote API will need matching server/client versions: The Podman remote APIs for Manifest List and Network operations have been completely rewritten to address issues and inconsistencies in the previous APIs. Incompatible APIs should warn if they are used with an older Podman client. Clients and servers must thus use the same API version. This means that if you are currently using the v3 API from a client, you will need to upgrade it to v4 at the same time. If you are not using the remote API, no change is required.

  • Rollbacks to a version with Podman v3.x will require manual action: Podman v4.0 will perform several schema migrations in the Podman database when it is first run. These schema migrations will cause Podman v3.x and earlier to be unable to read certain network configuration information from the database. This means that it will not be possible to roll back to a release with Podman v3.x without losing some functionality in existing containers.

  • Only new installations will use the new network stack by default: Existing systems will keep using the CNI network stack with Podman v4.0. To benefit from the new network stack, you will have to remove all existing containers, images and network with the podman system reset command. It is recommended to reboot to apply the change.

To validate this change in advance in your deployment, you can use the following instructions to try Podman v4.0 on a node for testing purposes:

$ cat /etc/yum.repos.d/podman4.repo
[copr:copr.fedorainfracloud.org:rhcontainerbot:podman4]
name=Copr repo for podman4 owned by rhcontainerbot
baseurl=https://download.copr.fedorainfracloud.org/results/rhcontainerbot/podman4/fedora-$releasever-$basearch/
type=rpm-md
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://download.copr.fedorainfracloud.org/results/rhcontainerbot/podman4/pubkey.gpg
repo_gpgcheck=0
enabled=1
enabled_metadata=1
$ sudo rpm-ostree override replace --experimental podman containers-common catatonit --freeze --from repo=copr:copr.fedorainfracloud.org:rhcontainerbot:podman4 --install aardvark-dns --install netavark
$ sudo systemctl reboot

Moving to iptables-nft

All new and upgrading Fedora CoreOS nodes will migrate to the nft backend of iptables. This will be done by updating the relevant symbolic links in /etc/alternatives. The legacy backend is considered deprecated.

See also the tracking issue.

Planificación

This change will be rolled out together with the rebase to Fedora 36.

Update Stream Targeted release date

next

2022-03-15

testing

2022-04-19

stable

Will follow testing as usual

Notas

If you need to stay on the legacy backend, create an empty file at /etc/coreos/iptables-legacy.stamp. For existing nodes, you can manually create the file now:

$ sudo mkdir -m 755 /etc/coreos/
$ sudo touch /etc/coreos/iptables-legacy.stamp

For new nodes that get deployed between now and when the migration happens, you can create the /etc/coreos/iptables-legacy.stamp file using Ignition to ensure they don’t get migrated. After the migration, you can bring up new nodes on the legacy backend by manually setting the symbolic links via Ignition. Below is a Butane config that does both of these:

variant: fcos
version: 1.6.0
storage:
  files:
    - path: /etc/coreos/iptables-legacy.stamp
      mode: 0644
  links:
    - path: /etc/alternatives/iptables
      target: /usr/sbin/iptables-legacy
      overwrite: true
      hard: false
    - path: /etc/alternatives/iptables-restore
      target: /usr/sbin/iptables-legacy-restore
      overwrite: true
      hard: false
    - path: /etc/alternatives/iptables-save
      target: /usr/sbin/iptables-legacy-save
      overwrite: true
      hard: false
    - path: /etc/alternatives/ip6tables
      target: /usr/sbin/ip6tables-legacy
      overwrite: true
      hard: false
    - path: /etc/alternatives/ip6tables-restore
      target: /usr/sbin/ip6tables-legacy-restore
      overwrite: true
      hard: false
    - path: /etc/alternatives/ip6tables-save
      target: /usr/sbin/ip6tables-legacy-save
      overwrite: true
      hard: false

This will ensure that all new nodes will use the legacy backend whether before or after the migration. After all streams are based on Fedora 36, we recommend removing the stamp file from your Butane config.

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