Cambios importantes en Fedora CoreOS

Esto es un listado 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 primero ha sido introducido en las imágenes de disco nuevas para el flujo next, como parte de la actualización a Fedora 42. Los flujos testing y next se implementarán posteriormente cuando se modernice a Fedora 42. Tras algunas versiones, migraremos las máquinas existentes mediante una versión de barrera.

Transmisión de actualizaciones Fecha de lanzamiento

next

41.20240916.1.0 (13 mar, 2025)

testing

41.20241027.2.0 (6 jul 2025)

stable

41.20241027.3.0 (19 ago, 2025)

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. Esto sería un cambio 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 modernización 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

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

Descripción detallada del cambio, los impactos, como probar, que acciones del manual son necesarios, etc.

Podman v5.0

El contenedor Podman en tiempo de ejecución será modernizado desde la v4 a la v5. Esto es un lanzamiento mayor que retira el mantenimiento para red CNI en favor de Netavark.

Además consulte el Canal Fedora y el seguimiento de fallos.

Planificación

Este cambio se implementará junto con la modernización a Fedora 40.

Actualización de flujo Fecha de lanzamiento prevista

next

40.20240322.1.0 (24 mar, 2024)

testing

40.20240416.2.0 (22 abr, 2024)

stable

40.20240416.3.1 (7 may, 2024)

Notas

Las notas de la versión completa de Podman v5 están disponibles en en GitHub y los cambios importantes se explican en Cambios importantes de Podman 5.0 en detalle. A continuación, se presenta un resumen de cómo esto afectará a los nodos de Fedora CoreOS:

  • Se ha eliminado el mantenimiento de red CNI y Netavark ahora es la única opción compatible.

  • Pasta ahora es el backend de red sin raíz predeterminado.

  • En el improbable caso de que usara una máquina Podman dentro de Fedora CoreOS, deberá eliminarla y volver a crearla. Consulte Migración de máquinas Podman 4 a Podman 5 para obtener más información.

  • El mantenimiento para cgroups v1 está obsoleto y será eliminado en una versión futura.

  • Para volver a una versión anterior con Podman v4.x probablemente será necesario realizar una acción manual.

La consola del sistema cambia a los valores predeterminados específicos de la plataforma

La configuración de la consola del sistema se modificará para ofrecer una mejor experiencia de usuario por defecto. Los nuevos valores predeterminados dependerán tanto de la arquitectura de la CPU como de la plataforma.

Los cambios solo afectarán a las nuevas instalaciones de Fedora CoreOS. Los sistemas modernizados conservarán los ajustes actuales de la consola.

Consulte también anuncio de coreos-status.

Planificación

Este cambio se implementará progresivamente:

Flujo de actualizaciones Fecha de lanzamiento prevista

next

2022-10-03 (37.20221003.1.0)

testing

2022-11-28

stable

Seguirla con los testing como usual

Notas

El valor predeterminado actual depende de la arquitectura de la CPU:

  • En x86_64, el primer puerto serie ttyS0 es la consola principal y la consola gráfica es secundaria.

  • En otras arquitecturas, Fedora CoreOS generalmente no configura una consola específica, dejando que el gestor de arranque y el kernel sigan sus propios valores predeterminados. Esto suele significar que se utiliza una consola gráfica si está disponible y una consola serie en caso contrario.

Los nuevos valores predeterminados dependerán tanto de la arquitectura de la CPU como de la plataforma. La configuración exacta se encuentra en platform.yaml (rama next-devel). En resumen:

  • En muchas combinaciones de arquitectura y plataforma, Fedora CoreOS permite que GRUB y el kernel sigan sus propios valores predeterminados. En x86_64, esto hace que se seleccione la consola gráfica, incluso si no hay ninguna tarjeta de vídeo disponible. En particular, las instalaciones x86_64 sin sistema operativo ya no usarán una consola serie por defecto.

  • En las plataformas que esperan que se utilicen consolas de sistema específicas, como AWS, Azure y GCP, Fedora CoreOS seleccionará esas consolas de forma predeterminada.

  • En OpenStack, VirtualBox y VMware, Fedora CoreOS utilizará una consola gráfica principal pero continuará proporcionando una consola serial para depuración.

  • La imagen QEMU continuará seleccionando ttyS0 como consola principal y la consola gráfica como secundaria.

Si los nuevos valores predeterminados no son adecuados para su entorno, puede anularlos de varias maneras. Consulte la página de documentación de Acceso a la consola de emergencia para obtener más información.

Podman 4.0

El entorno de ejecución del contenedor Podman se actualizará de la versión 3 a la 4. Esta es una versión principal que introduce cambios incompatibles con versiones anteriores en los archivos de configuración y las API.

Consulte además Cambios de Fedora y el seguimiento de asuntos.

Planificación

Este cambio se implementará junto con la modernización a Fedora 36.

Actualizar Flujo Fecha de Lanzamiento Revisto

next

2025-03-15

testing

2022-04-19

stable

Seguirá el testing como usual

Notas

Las notas de la versión completa de Podman v4 están disponibles en en GitHub. A continuación, se presenta un resumen de cómo afectará esto a los nodos de Fedora CoreOS:

  • Los contenedores existentes se conservarán sin necesidad de realizar ninguna modificación.

  • La compatibilidad con la API de Docker se conserva completamente.

  • Los usuarios de la API remota de Podman necesitarán versiones compatibles de servidor/cliente: Las API remotas de Podman para las operaciones de lista de manifiestos y red se han reescrito por completo para solucionar problemas e inconsistencias en las API anteriores. Las API incompatibles deberían mostrar una advertencia si se utilizan con un cliente Podman anterior. Por lo tanto, los clientes y servidores deben usar la misma versión de la API. Esto significa que si actualmente utiliza la API v3 desde un cliente, deberá actualizarla a la v4 simultáneamente. Si no utiliza la API remota, no es necesario realizar ningún cambio.

  • Las reversiones a una versión con Podman v3.x requieren una acción manual: Podman v4.0 realizará varias migraciones de esquema en la base de datos de Podman durante su primera ejecución. Estas migraciones de esquema impedirán que Podman v3.x y versiones anteriores puedan leer cierta información de configuración de red de la base de datos. Esto significa que no será posible revertir a una versión con Podman v3.x sin perder funcionalidad en los contenedores existentes.

  • Solo las nuevas instalaciones usarán la nueva pila de red de forma predeterminada: los sistemas existentes seguirán usando la pila de red CNI con Podman v4.0. Para aprovecharla, deberá eliminar todos los contenedores, imágenes y redes existentes con el comando podman system reset. Se recomienda reiniciar para aplicar el cambio.

Para validar este cambio con anticipación en su implementación, puede utilizar las siguientes instrucciones para probar Podman v4.0 en un nodo con fines de prueba:

$ 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

Traslado a iptables-nft

Todos los nodos nuevos y actualizados de Fedora CoreOS migrarán al backend NFT de iptables. Esto se realizará actualizando los enlaces simbólicos relevantes en /etc/alternatives. El backend heredado se considera obsoleto.

Consulte también los asuntos de seguimiento.

Planificación

Este cambio se implementará junto con la modernización a Fedora 36.

Actualizar Flujo Fecha de Lanzamiento Revisto

next

2025-03-15

testing

2022-04-19

stable

Seguirá el testing como usual

Notas

Si necesita permanecer en el backend heredado, cree un archivo vacío en /etc/coreos/iptables-legacy.stamp. Para los nodos existentes, puede crear el archivo manualmente ahora:

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

Para los nodos nuevos que se implementen entre ahora y cuando suceda la migración, puede crear el archivo /etc/coreos/iptables-legacy.stamp con Ignition para garantizar que no se migren. Después de la migración, puede activar los nuevos nodos en el backend heredado configurando manualmente los enlaces simbólicos mediante Ignition. A continuación, se muestra una configuración de Butane que realiza ambas tareas:

variant: fcos
version: 1.7.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

Esto garantizará que todos los nodos nuevos utilicen el backend heredado, tanto antes como después de la migración. Una vez que todos los flujos se basen en Fedora 36, recomendamos eliminar el archivo de sello de la configuración de Butane.

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