Come aggiornare Fedora dalla versione 33 alla 34 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 20/10/2026 Pubblicato il: 20/10/2026 06:00 Tempo di lettura: 8 min

Aggiornare Fedora 33 a Fedora 34 non è un semplice cambio di versione: è un passaggio di release che va trattato come un change controllato. La strada corretta, nel caso tipico, è usare DNF System Upgrade, dopo aver verificato che il sistema sia sano, che ci sia spazio sufficiente e che i repository siano allineati. L’obiettivo non è solo arrivare alla nuova release, ma farlo con un rollback ragionato se qualcosa non torna.

Prima di iniziare: cosa controllare davvero

Lo stato atteso è semplice: sistema Fedora 33 aggiornato, pacchetti coerenti, boot funzionante, rete disponibile e spazio disco sufficiente per scaricare e installare centinaia di RPM. Lo stato osservato, quando l’upgrade fallisce, è quasi sempre uno di questi: repository di terze parti incompatibili, spazio insufficiente in /boot o /var, pacchetti trattenuti da conflitti, oppure problemi emersi solo al primo riavvio nel nuovo kernel.

Prima di toccare la release, fai queste verifiche minime. Sono rapide e ti evitano il classico upgrade che si interrompe a metà per motivi banali.

Controlla la release in uso:
```
cat /etc/fedora-release
uname -r
```
Atteso: Fedora 33 e kernel coerente con il sistema installato.
Verifica lo spazio libero:
```
df -h /
df -h /boot
df -h /var
```
Atteso: margine sufficiente su root e, soprattutto, su /boot se hai kernel vecchi accumulati.
Controlla che il sistema sia aggiornato prima del salto di release:
```
sudo dnf upgrade --refresh
```
Atteso: nessun errore di dipendenze e nessun pacchetto bloccato.
Disabilita o rimuovi temporaneamente repository esterni che non sai per certo essere compatibili con Fedora 34.
Se usi repo di terze parti, controlla i file in /etc/yum.repos.d/. Questo è uno dei punti che più spesso manda in crisi la transizione.

Backup e blast radius: non saltare questo passaggio

Il blast radius di un upgrade di release è il sistema intero: kernel, librerie, servizi, configurazioni locali e applicazioni installate via DNF. Se tocchi una macchina di produzione, il rollback non è “cliccare indietro”: in pratica significa avere snapshot, backup o almeno una strategia di ritorno coerente prima di iniziare.

Se il sistema gira su VM, la scelta migliore è uno snapshot del disco prima del reboot di upgrade. Se è una macchina fisica, fai almeno un backup dei dati applicativi e delle configurazioni personalizzate. In particolare, salva i file in /etc che hai modificato a mano, i virtual host, le unità systemd custom e i file di configurazione dei servizi esposti.

Un controllo utile è questo:

sudo rpmconf -a

Se il pacchetto rpmconf è disponibile, aiuta a gestire i file di configurazione modificati localmente dopo gli aggiornamenti. Non sostituisce il backup, ma riduce gli errori di merge nelle config.

Metodo consigliato: DNF System Upgrade

Per Fedora 33 → 34, il metodo supportato è il plugin dnf system-upgrade. Il flusso è lineare: aggiorni tutto, scarichi i pacchetti della nuova release, poi riavvii nel processo di upgrade dedicato. È molto più affidabile del tentare di cambiare repository a mano e forzare un upgrade “classico”.

Installa il plugin se non è presente:
```
sudo dnf install dnf-plugin-system-upgrade
```
Atteso: il pacchetto viene installato senza conflitti.
Scarica i pacchetti della nuova release:
```
sudo dnf system-upgrade download --releasever=34
```
Atteso: il download completa senza errori di dipendenze. Se compaiono conflitti, non forzare subito: prima identifica il pacchetto che blocca l’upgrade.
Se il sistema segnala pacchetti problematici, usa la verifica dettagliata prima di procedere:
```
sudo dnf system-upgrade download --releasever=34 --best --allowerasing
```
Questo va usato con criterio: --allowerasing può rimuovere pacchetti incompatibili. Prima di accettarlo, verifica l’elenco di ciò che verrebbe eliminato.
Quando il download è completato, avvia l’upgrade al reboot:
```
sudo dnf system-upgrade reboot
```
Atteso: il sistema si riavvia e parte la fase di upgrade offline.

Durante la fase offline non devi intervenire sul sistema. Lascia completare la transizione. Se la macchina è remota, assicurati di avere accesso console/IPMI/KVM o equivalente: se il boot si interrompe, la shell SSH potrebbe non essere disponibile abbastanza presto da risolvere il problema comodamente.

Se l’upgrade si blocca: come leggere il problema

Le cause più probabili, in ordine pratico, sono tre: conflitti tra repository, spazio insufficiente, pacchetti di terze parti non compatibili con la nuova release. In meno di cinque minuti puoi falsificare ciascuna ipotesi con pochi controlli.

Repository incompatibili: se il download si ferma su dipendenze strane, controlla i repo abilitati.
```
dnf repolist --enabled
```
Atteso: solo i repository necessari e compatibili con Fedora 34. Se vedi repo esterni non aggiornati, disabilitali temporaneamente in /etc/yum.repos.d/.
Spazio insufficiente: se /boot è pieno, l’upgrade può fallire o lasciare il sistema in uno stato incoerente.
```
df -h /boot
rpm -q kernel
```
Atteso: almeno un margine utile per installare il nuovo kernel. Se hai troppi kernel vecchi, rimuovi quelli obsoleti con criterio, lasciandone almeno uno noto funzionante.
Pacchetti bloccati: alcune applicazioni esterne possono impedire il passaggio di release.
```
sudo dnf repoquery --unsatisfied
```
Atteso: nessuna dipendenza rotta. Se emergono pacchetti non soddisfatti, identifica prima il software che li porta dentro e valuta se disinstallarlo temporaneamente.

Dopo il reboot: controlli tecnici da fare subito

Il fatto che il sistema si avvii non basta. Devi verificare che il nuovo ambiente sia coerente e che i servizi critici siano partiti con le configurazioni corrette. Qui l’obiettivo è intercettare problemi di boot, servizi falliti e residui di configurazione vecchia.

Verifica la release effettiva:
```
cat /etc/fedora-release
hostnamectl
```
Atteso: Fedora 34 e sistema avviato correttamente.
Controlla i servizi falliti:
```
systemctl --failed
```
Atteso: nessun servizio in failed. Se ce ne sono, annota il nome e controlla i log con journalctl -u NOME_SERVIZIO -b.
Controlla i log del boot corrente:
```
journalctl -p err -b
```
Atteso: assenza di errori gravi ripetuti. Un errore isolato non è sempre un problema, ma gli errori su storage, SELinux, network o systemd meritano attenzione immediata.
Verifica che la rete sia operativa e che il DNS risponda:
```
ping -c 3 1.1.1.1
getent hosts fedoraproject.org
```
Atteso: connettività e risoluzione nomi funzionanti. Se manca il DNS, il sistema può sembrare “rotto” anche quando il resto è sano.

Problemi tipici dopo l’upgrade e come gestirli

Su Fedora, alcuni problemi post-upgrade sono ricorrenti. Non tutti dipendono dall’upgrade in sé: spesso emergono perché un servizio che prima era tollerato da una vecchia libreria diventa più rigido nella nuova release.

Servizi che non partono: se un demone custom o un web stack non si avvia, verifica prima il log del servizio e il file unit. Un controllo rapido è:

journalctl -u nome-servizio -b
systemctl status nome-servizio

Se il problema è una config non più valida, il fix corretto è ripristinare il file precedente o correggerlo in modo puntuale, non riscrivere tutto a memoria.

SELinux: dopo il cambio di release, alcune etichette possono richiedere una ricostruzione. Se un servizio funziona male senza errori evidenti, controlla i denial con:

sudo ausearch -m avc -ts recent
sudo journalctl -t setroubleshoot --since today

Atteso: nessun denial recente per il servizio interessato. Se ci sono, correggi il contesto o la policy, non disabilitare SELinux come scorciatoia.

Moduli o software esterni: driver, repository di terze parti, agent di monitoraggio o software proprietario possono essere la vera causa del problema. Se un componente è fuori supporto per Fedora 34, il fix strutturale è aggiornare quel componente o rimuoverlo, non congelare il sistema in una release vecchia.

Pulizia finale: lascia il sistema in uno stato coerente

Quando l’upgrade è riuscito, conviene ripulire i residui della transizione. Questo riduce il rumore nei controlli futuri e ti aiuta a distinguere problemi nuovi da quelli vecchi.

Rimuovi i vecchi kernel non più necessari, ma conserva almeno un kernel noto funzionante.
Se vuoi evitare errori manuali, usa gli strumenti standard di DNF per la gestione dei kernel installati, verificando sempre cosa rimane prima di confermare la rimozione.
Controlla i pacchetti obsoleti:
```
sudo dnf repoquery --extras
```
Atteso: nessun pacchetto “extra” non voluto. Quelli rimasti possono essere software installato fuori dai repository normali o residui di vecchie dipendenze.
Verifica eventuali file di configurazione con conflitti e risolvi i merge manualmente se necessario.
Le configurazioni in /etc sono il punto in cui si annidano i problemi più subdoli: meglio confrontarle subito che scoprirle alla prima manutenzione successiva.

Rollback realistico se qualcosa va storto

Il rollback di un major/minor release upgrade non è un comando magico. Se hai uno snapshot, il rollback serio è ripristinare quello snapshot. Se non ce l’hai, devi almeno rimettere in piedi i servizi e i dati applicativi partendo dai backup.

Se il sistema non boota dopo l’upgrade, la prima mossa è usare la console locale o remota per accedere al boot menu e selezionare un kernel precedente, se ancora disponibile. Se il problema è nel nuovo kernel o in un servizio che si avvia male, questo può darti il tempo necessario per intervenire senza fermare tutto.

Se invece il sistema è avviato ma instabile, non fare modifiche a cascata. Ripristina prima il servizio colpito, poi valuta se il problema deriva da un pacchetto incompatibile o da una configurazione migrata male. In caso di dubbio, conserva i log di boot e di servizio prima di cambiare altro: sono la base per capire cosa è successo davvero.

Checklist operativa compatta

Se devi fare l’upgrade in modo ordinato, la sequenza da tenere in testa è questa: sistema aggiornato, repository compatibili, backup disponibile, download della nuova release, reboot controllato, verifica post-boot, pulizia finale. Saltare uno di questi passaggi aumenta molto la probabilità di dover intervenire a mano nel momento peggiore.

In sintesi: Fedora 33 a 34 si aggiorna bene con il percorso supportato da Fedora, ma la parte importante non è il comando finale. È la preparazione, la verifica dei repository, la gestione dei pacchetti incompatibili e il controllo post-reboot. Se tratti l’upgrade come un cambio controllato e non come un click meccanico, riduci parecchio i tempi morti e gli interventi d’emergenza.