Cambiamenti principali in Fedora CoreOS

Questo è un elenco delle principali modifiche introdotte in Fedora CoreOS con le relative note. Tali modifiche sono annunciate anche sulla mailing list coreos-status. Nota che questo non è un elenco esaustivo delle modifiche in Fedora CoreOS e include solo le modifiche principali che potrebbero richiedere azioni manuali. L’elenco è in ordine cronologico inverso per tenere le modifiche recenti in cima.

Passa agli aggiornamenti OCI

A partire da Fedora 42, Fedora CoreOS verrà aggiornato tramite immagini OCI invece del repository OSTree. Richiesta di modifica di Fedora: [Fedora CoreOS Change (https://fedoraproject.org/wiki/Changes/CoreOSOstree2OCIUpdates). Ulteriori discussioni: [GitHub Issue](https://github.com/coreos/fedora-coreos-tracker/issues/1823).

Pianificazione

Questo cambiamento è stato introdotto inizialmente nelle nuove immagini disco per il canale next, come parte del rebase a Fedora 42. I canali `testing`e `next`seguiranno non appena effettueranno il rebase a Fedora 42. Dopo alcuni rilasci, migreremo le macchine esistenti tramite un rilascio barriera (barrier release).

Canale di aggiornamento Data di rilascio

next

42.20250316.1.0 (18-03-2025)

testing

42.20250705.2.0 (06-07-2025)

stable

42.20250803.3.0 (19-08-2025)

Note

Attualmente, gli host Fedora CoreOS scaricano gli aggiornamenti dal repository OSTree. Con questo cambiamento, gli host scaricheranno invece gli aggiornamenti dal registro dei contenitori Quay.io. Questa modifica dovrebbe risultare trasparente, sebbene gli ambienti configurati con un proxy richiedano particolare attenzione, poiché i nodi si collegheranno a un indirizzo diverso per ottenere gli aggiornamenti.

Nota: le immagini disco verranno aggiornate per prime, quindi le nuove installazioni di Fedora CoreOS basate su Fedora 42 utilizzeranno le immagini OCI. Dopo alcuni rilasci, migreremo i nodi esistenti.

Questo cambiamento è limitato esclusivamente al passaggio a OCI come mezzo di trasporto per i contenuti di Fedora CoreOS. Il supporto alla derivazione (derivation) è ancora in fase di sviluppo; per maggiori dettagli, consulta il ticket di tracciamento: https://github.com/coreos/fedora-coreos-tracker/issues/1726

Supporto cgroups v1 disabilitato

In systemd v256, il supporto a cgroups v1 è stato disabilitato. Se in passato hai scelto di non effettuare la migrazione a cgroups v2, il tuo sistema non si avvierà dopo l’aggiornamento. È necessario aggiornare i parametri del kernel prima di procedere con l’aggiornamento.

Aggiornare un sistema esistente da cgroupsv1 a cgroupsv2 e riavviare immediatamente
$ sudo rpm-ostree kargs --delete=systemd.unified_cgroup_hierarchy --reboot

Pianificazione

Questo cambiamento è stato distribuito come parte del rebase a Fedora 41.

Canale di aggiornamento Data di rilascio prevista

next

41.20240916.1.0 (16 set 2024)

testing

41.20241027.2.0 (28 ott 2024)

stable

41.20241027.3.0 (08 nov 2024)

Note

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

Descrizione dettagliata del cambiamento, degli impatti, delle modalità di test, delle azioni manuali necessarie, ecc.

Podman v5.0

Il runtime dei contenitori Podman verrà aggiornato dalla versione v4 alla v5. Si tratta di un major release che rimuove il supporto alla rete CNI in favore di Netavark.

See also the Fedora Change and the tracking issue.

Pianificazione

Questo cambiamento verrà distribuito insieme al rebase a Fedora 40.

Canale di aggiornamento Data di rilascio prevista

next

40.20240322.1.0 (24 mar 2024)

testing

40.20240416.2.0 (22 apr 2024)

stable

40.20240416.3.1 (07 mag 2024)

Note

Le note di rilascio complete per Podman v5 sono disponibili su GitHub e le modifiche con rottura della retrocompatibilità (breaking changes) sono spiegate in Podman 5.0 breaking changes in detail. Ecco un riassunto di come questo influirà sui nodi Fedora CoreOS:

  • Il supporto alla rete CNI è stato rimosso e Netavark è ora l’unica opzione supportata.

  • Pasta è ora il backend di rete predefinito per gli utenti non radice (rootless).

  • Nel caso (improbabile) in cui tu stia utilizzando podman machine all’interno di Fedora CoreOS, dovrai eliminare e ricreare la tua podman machine. Vedi Migration of Podman 4 to Podman 5 machines per maggiori dettagli.

  • Il supporto per cgroups v1 è deprecato e verrà rimosso in una versione futura.

  • I ripristini (rollback) a una versione precedente con Podman v4.x richiederanno probabilmente un’azione manuale.

La console di sistema passa ai valori predefiniti specifici della piattaforma

La configurazione della console di sistema verrà modificata per offrire un’esperienza utente migliore per impostazione predefinita. I nuovi valori predefiniti dipenderanno sia dall’architettura della CPU sia dalla piattaforma.

Le modifiche interesseranno solo le nuove installazioni di Fedora CoreOS. I sistemi aggiornati manterranno le loro attuali impostazioni della console.

Vedi anche l’annuncio su coreos-status.

Pianificazione

Questo cambiamento verrà distribuito progressivamente:

Canale di aggiornamento Data di rilascio prevista

next

03 ott 2022 (37.20221003.1.0)

testing

28 nov 2022

stable

Seguirà il canale testing come di consueto

Note

Il valore predefinito attuale dipende dall’architettura della CPU:

  • Su x86_64, la prima porta seriale ttyS0 è la console principale e la console grafica è quella secondaria.

  • Su altre architetture, Fedora CoreOS generalmente non configura una console specifica, lasciando che il bootloader e il kernel seguano i propri valori predefiniti. Questo in genere significa che, se disponibile, viene utilizzata una console grafica, altrimenti una console seriale.

I nuovi valori predefiniti dipenderanno sia dall’architettura della CPU sia dalla piattaforma. La configurazione esatta si trova in platform.yaml(ramo next-devel). In sintesi:

  • Su molte combinazioni di architettura/piattaforma, Fedora CoreOS consentirà a GRUB e al kernel di seguire i propri valori predefiniti. Su x86_64, questo comporta la selezione della console grafica, anche se non è disponibile alcuna scheda video. In particolare, le installazioni bare metal su x86_64 non utilizzeranno più una console seriale per impostazione predefinita.

  • Su piattaforme che richiedono l’uso di console di sistema specifiche, come AWS, Azure e GCP, Fedora CoreOS selezionerà tali console per impostazione predefinita.

  • Su OpenStack, VirtualBox e VMware, Fedora CoreOS utilizzerà una console grafica principale, ma continuerà a fornire una console seriale per il debug.

  • L’immagine QEMU continuerà a selezionare ttyS0 come console principale e la console grafica come secondaria.

Se i nuovi valori predefiniti non sono adatti al tuo ambiente, puoi sovrascriverli in diversi modi. Vedi la pagina di documentazione Emergency console access per ulteriori dettagli.

Podman v4.0

Il runtime dei container Podman verrà aggiornato dalla versione v3 alla v4. Si tratta di un major release (rilascio principale) che introduce modifiche retrocompatibili e non alle API e ai file di configurazione.

Vedi anche la modifica di Fedora e il ticket di tracciamento.

Pianificazione

Questo cambiamento sarà distribuito insieme al rebase a Fedora 36.

Canale di aggiornamento Data di rilascio prevista

next

15 mar 2022

testing

19 apr 2022

stable

Seguirà il canale testing come di consueto

Note

Le note di rilascio complete per Podman v4 sono disponibili su GitHub. Ecco un riepilogo di come questo impatterà sui nodi Fedora CoreOS:

  • I container esistenti verranno preservati senza che sia richiesta alcuna modifica.

  • La compatibilità per l’API di Docker è completamente preservata.

  • Gli utenti dell’API remota di Podman dovranno utilizzare versioni corrispondenti per server e client: le API remote di Podman per le operazioni sui Manifest List e sulla rete sono state completamente riscritte per correggere problemi e incongruenze delle versioni precedenti. Le API incompatibili dovrebbero mostrare un avviso se utilizzate con un client Podman più datato. Client e server devono quindi utilizzare la stessa versione dell’API. Ciò significa che se attualmente stai utilizzando l’API v3 da un client, dovrai aggiornarlo alla v4 contemporaneamente. Se non utilizzi l’API remota, non è richiesta alcuna modifica.

  • I ripristini (rollback) a una versione con Podman v3.x richiederanno un intervento manuale: al suo primo avvio, Podman v4.0 eseguirà diverse migrazioni dello schema nel database di Podman. Queste migrazioni dello schema impediranno a Podman v3.x e versioni precedenti di leggere alcune informazioni di configurazione di rete dal database. Ciò significa che non sarà possibile effettuare un rollback a una versione con Podman v3.x senza perdere alcune funzionalità nei container esistenti.

  • Solo le nuove installazioni utilizzeranno il nuovo stack di rete per impostazione predefinita: i sistemi esistenti continueranno a utilizzare lo stack di rete CNI con Podman v4.0. Per poter beneficiare del nuovo stack di rete, sarà necessario rimuovere tutti i container, le immagini e le reti esistenti tramite il comando podman system reset. Si raccomanda inoltre un riavvio per applicare correttamente la modifica.

Per convalidare questa modifica in anticipo nella tua infrastruttura, puoi seguire le seguenti istruzioni per provare Podman v4.0 su un nodo a scopo di test:

$ 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

Passaggio a iptables-nft

Tutti i nodi Fedora CoreOS, sia nuovi che aggiornati, migreranno al backend nft di iptables. Questo avverrà tramite l’aggiornamento dei relativi collegamenti simbolici in /etc/alternatives. Il backend legacy è considerato deprecato.

Vedi anche il ticket di tracciamento.

Pianificazione

Questo cambiamento sarà distribuito insieme al rebase a Fedora 36.

Canale di aggiornamento Data di rilascio prevista

next

15 mar 2022

testing

19 apr 2022

stable

Seguirà il canale testing come di consueto

Note

Se hai la necessità di rimanere sul backend legacy, crea un file vuoto in /etc/coreos/iptables-legacy.stamp. Per i nodi esistenti, puoi creare manualmente il file ora:

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

Per i nuovi nodi che vengono distribuiti da ora fino al momento in cui avverrà la migrazione, puoi creare il file /etc/coreos/iptables-legacy.stamp utilizzando Ignition per assicurarti che non vengano migrati. Dopo la migrazione, potrai avviare i nuovi nodi sul backend legacy impostando manualmente i collegamenti simbolici tramite Ignition. Di seguito è riportata una configurazione Butane che esegue entrambe le operazioni:

variante: fcos
versione: 1.7.0
magazzinaggio:
  collegamenti:
    - percorso: /etc/alternatives/iptables
      destinazione: /usr/sbin/iptables-legacy
      sovrascrivere: vero
      difficile: falso
    - percorso: /etc/alternatives/iptables-restore
      destinazione: /usr/sbin/iptables-legacy-restore
      sovrascrivere: vero
      difficile: falso
    - percorso: /etc/alternatives/iptables-save
      destinazione: /usr/sbin/iptables-legacy-save
      sovrascrivere: vero
      difficile: falso
    - percorso: /etc/alternatives/ip6tables
      destinazione: /usr/sbin/ip6tables-legacy
      sovrascrivere: vero
      difficile: falso
    - percorso: /etc/alternatives/ip6tables-restore
      destinazione: /usr/sbin/ip6tables-legacy-restore
      sovrascrivere: vero
      difficile: falso
    - percorso: /etc/alternatives/ip6tables-save
      destinazione: /usr/sbin/ip6tables-legacy-save
      sovrascrivere: vero
      difficile: falso

Questo assicurerà che tutti i nuovi nodi utilizzino il backend legacy, sia prima che dopo la migrazione. Dopo che tutti gli stream saranno basati su Fedora 36, raccomandiamo di rimuovere il file stamp dalla tua configurazione Butane.

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