Come Risolvere i Problemi Comuni di Gestione dei Pacchetti (APT/YUM)

I guasti del gestore di pacchetti tendono ad arrivare nel momento peggiore: durante un aggiornamento di sicurezza, una distribuzione o una sessione rapida "installa solo questo strumento" su un host che normalmente non tocchi. APT, YUM e DNF di solito ti dicono cosa non va, ma l'output può essere rumoroso. Il compito è rallentare, identificare quale livello ha fallito ed evitare di forzare il database in uno stato peggiore.

APT è comune sui sistemi Debian e Ubuntu. YUM e DNF sono comuni sui sistemi della famiglia Red Hat, con DNF che sostituisce YUM su molte versioni più recenti. Gli esempi seguenti si concentrano sui guasti che gli amministratori vedono effettivamente: transazioni interrotte, problemi di metadati del repository, conflitti di dipendenza, blocchi, errori GPG e problemi del database dei pacchetti.

Prima di modificare qualsiasi cosa, cattura il comando e l'errore esatti. Se questo è un server di produzione, controlla anche se è in esecuzione un altro processo di aggiornamento. Due gestori di pacchetti che combattono per lo stesso database possono trasformare un piccolo problema in una lunga riparazione.

Problemi Comuni di APT e Risoluzione

APT è noto per le sue complete capacità di risoluzione delle dipendenze. Tuttavia, possono ancora sorgere problemi, spesso relativi a dipendenze interrotte, download interrotti o problemi del repository.

1. Pacchetti Interrotti o Dipendenze Non Soddisfatte

Questo è forse l'errore APT più comune. Si verifica quando un pacchetto è installato, ma le sue dipendenze sono mancanti, interrotte o incompatibili. Il messaggio di errore spesso assomiglia a questo:

Errore: dpkg è stato interrotto, potresti dover eseguire 'sudo dpkg --configure -a' per correggere il problema.

Decompressione ... (lettura del database ... xxxx file e directory attualmente installati.)

Preparazione alla decompressione di .../some-package_version_arch.deb ...

Decompressione di some-package (versione) ...

dpkg: errore durante l'elaborazione dell'archivio /var/cache/apt/archives/some-package_version_arch.deb (--unpack):

 tentativo di sovrascrivere '/path/to/file', che è anche nel pacchetto other-package:amd64

Si sono verificati errori durante l'elaborazione:

 some-package
 E: Il sottoprocesso /usr/bin/dpkg ha restituito un codice di errore (1)

Passaggi per la Risoluzione:

• Configura i Pacchetti in Sospeso: Se dpkg è stato interrotto, il primo passo è provare a risolverlo:

  sudo dpkg --configure -a
  

  Questo comando tenta di configurare tutti i pacchetti che sono decompressi ma non ancora configurati.

• Ripara le Dipendenze Interrotte: Se quanto sopra non risolve il problema, puoi provare a riparare le dipendenze interrotte:

  sudo apt --fix-broken install
  

  Questo comando tenterà di scaricare e installare le dipendenze mancanti o rimuovere i pacchetti problematici.

• Rimuovi i Pacchetti Problematici: A volte, un pacchetto specifico potrebbe causare problemi persistenti. Puoi provare a rimuoverlo:

  sudo apt remove <nome-pacchetto>
  

  Se il pacchetto non può essere rimosso normalmente, potresti dover forzare la sua rimozione (usare con cautela):

  sudo dpkg --remove --force-remove-reinstreq <nome-pacchetto>
  

• Pulisci la Cache APT: Una cache corrotta può anche portare a errori:

  sudo apt clean
  sudo apt update
  

  apt clean rimuove i file dei pacchetti scaricati da /var/cache/apt/archives/, e apt update aggiorna l'elenco dei pacchetti.

2. Problemi del Repository

Possono verificarsi errori se gli elenchi dei pacchetti non possono essere recuperati dai repository configurati. Ciò potrebbe essere dovuto a problemi di rete, un URL del repository non valido o il repository temporaneamente non disponibile.

Esempi di Errore:

E: Impossibile recuperare http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease  Risoluzione temporanea non riuscita di 'archive.ubuntu.com'
E: Alcuni file di indice non sono stati scaricati. Sono stati ignorati o ne sono stati usati di vecchi.

Passaggi per la Risoluzione:

• Controlla DNS e connettività di rete: I guasti DNS sono comuni su server appena costruiti e percorsi VPN interrotti.

  getent hosts archive.ubuntu.com
  curl -I http://archive.ubuntu.com/ubuntu/
  

• Verifica le Fonti del Repository: Controlla il contenuto di /etc/apt/sources.list e i file in /etc/apt/sources.list.d/. Assicurati che gli URL siano corretti e accessibili.
  • Cerca errori di battitura.
  • Commenta o rimuovi le voci del repository sospette.
• Prova un Mirror Diverso: Se un mirror specifico è giù, APT potrebbe provare automaticamente un altro. In caso contrario, modifica manualmente sources.list per selezionare un mirror diverso.
• Aggiorna gli Elenchi dei Pacchetti: Dopo aver apportato qualsiasi modifica, esegui sempre:

  sudo apt update
  

Se apt update si lamenta delle firme, non disabilitare il controllo delle firme come scorciatoia. La firma del repository ti protegge dall'installazione di pacchetti manomessi. Controlla se il fornitore del repository ha cambiato la sua chiave, se il pacchetto keyring è obsoleto o se un vecchio repository di terze parti non è più mantenuto.

3. Installazioni o Aggiornamenti Interrotti

Se un processo apt install o apt upgrade viene interrotto (ad esempio, da un'interruzione di corrente o un riavvio del sistema), può lasciare il sistema in uno stato incoerente.

Passaggi per la Risoluzione:

• Esegui sudo dpkg --configure -a: Come accennato in precedenza, questo è il primo passo per provare a risolvere eventuali problemi di configurazione di dpkg.
• Esegui sudo apt --fix-broken install: Questo può risolvere i problemi di dipendenza derivanti dall'interruzione.
• Riesegui il Comando: A volte, semplicemente rieseguire il comando che ha fallito può risolvere il problema se era un problema transitorio.

Problemi Comuni di YUM/DNF e Risoluzione

YUM e DNF sono potenti strumenti per la gestione dei pacchetti nei sistemi basati su Red Hat. Simile ad APT, i guasti spesso derivano da problemi di dipendenza, problemi del repository o cache corrotta.

1. Errori di Dipendenza

Gli errori di dipendenza in YUM/DNF si verificano quando un pacchetto richiesto richiede un altro pacchetto che non è installato, è una versione incompatibile o non può essere trovato nei repository configurati.

Esempio di Errore (YUM):

Errore: Pacchetto: some-package-1.0-1.el8.x86_64 (epel)

 Richiede: another-package >= 2.0

Potresti provare: rpm -e --nodeps some-package

Esempio di Errore (DNF):

Errore: 
 Problema: impossibile installare il miglior candidato per questo pacchetto (root significa processo di installazione)
  - niente fornisce la dipendenza 'another-package >= 2.0' richiesta da 'some-package-1.0-1.el8.x86_64'

Passaggi per la Risoluzione:

• Aggiorna le Informazioni del Pacchetto: Assicurati che la cache locale dei pacchetti sia aggiornata:

  sudo yum makecache # Per YUM
  sudo dnf makecache # Per DNF
  

• Installa le Dipendenze Manualmente: Se conosci la dipendenza richiesta, prova a installarla esplicitamente:

  sudo yum install another-package # Per YUM
  sudo dnf install another-package # Per DNF
  

• Usa gli strumenti di pulizia con attenzione: Queste utilità possono talvolta aiutare a identificare pacchetti duplicati o obsoleti.

  sudo yum install yum-utils
  sudo package-cleanup --cleandupes # Pulisci i pacchetti duplicati
  sudo package-cleanup --orphans # Rimuovi i pacchetti orfani
  
  sudo dnf install dnf-plugins-core
  sudo dnf clean all
  

• Evita rpm -e --nodeps a meno che tu non abbia un piano di rollback: Può rimuovere un pacchetto lasciando installati i pacchetti dipendenti, il che potrebbe soddisfare il comando ma rompere il sistema.

2. Problemi di Configurazione del Repository

I problemi con i repository YUM/DNF possono impedire che i pacchetti vengano trovati o installati.

Passaggi per la Risoluzione:

• Controlla i File del Repository: Le definizioni del repository si trovano tipicamente in /etc/yum.repos.d/. Esamina questi file .repo per:
  • Voci baseurl o mirrorlist corrette.
  • Repository abilitati (enabled=1).
  • Problemi di verifica della chiave GPG (spesso indicati da gpgcheck=1).
• Verifica l'Accesso di Rete: Simile ad APT, assicurati che il tuo sistema possa raggiungere i server del repository.

  ping <indirizzo-server-repository>
  

• Controlla le Chiavi GPG: Se vedi errori relativi alle chiavi GPG, potresti dover importare o reimportare la chiave pubblica del repository.

  # Esempio per importare una chiave
  sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-tuo-repo
  

  Evita di impostare gpgcheck=0 sui sistemi di produzione. Scambia un'attività di riparazione con un rischio per la catena di approvvigionamento.
• Pulisci la Cache: Una cache corrotta può causare problemi:

  sudo yum clean all
  sudo dnf clean all
  

  Quindi, aggiorna i metadati:

  sudo yum makecache
  sudo dnf makecache
  

3. Errori di Transazione Incompleta

Questi errori si verificano quando un processo di installazione, aggiornamento o rimozione di un pacchetto viene interrotto.

Passaggi per la Risoluzione:

• Riesegui la Transazione: Spesso, semplicemente rieseguire il comando (yum update, dnf install, ecc.) può risolvere il problema se era un problema temporaneo.
• Pulisci la Cache: Come sopra, cancellare la cache può aiutare:

  sudo yum clean all
  sudo dnf clean all
  

• Controlla i Pacchetti Bloccati: Sebbene meno comune con YUM/DNF che con APT, alcune configurazioni potrebbero impedire l'aggiornamento dei pacchetti. Questo di solito è gestito dalle configurazioni dei plugin piuttosto che da comandi 'hold' diretti.
• Esamina i Log: Controlla /var/log/yum.log (per YUM) o /var/log/dnf.log (per DNF) per messaggi di errore dettagliati.

Blocchi e Processi di Pacchetti Bloccati

Gli errori di blocco non sono realmente errori di dipendenza. Di solito significano che un altro processo di pacchetto è in esecuzione o è morto senza pulire.

Su Debian o Ubuntu, potresti vedere messaggi su /var/lib/dpkg/lock-frontend o /var/lib/apt/lists/lock. Sui sistemi della famiglia Red Hat, potresti vedere un altro processo dnf o yum che tiene il blocco del database RPM.

Prima di tutto, controlla se c'è un processo attivo:

ps aux | grep -E 'apt|dpkg|dnf|yum|rpm' | grep -v grep

Se gli aggiornamenti automatici o cloud-init sono in esecuzione, aspetta. Uccidere una vera transazione di pacchetto può lasciare i pacchetti a metà configurazione. Se sei sicuro che il processo sia sparito e rimane solo un blocco obsoleto, allora ripara il database dei pacchetti con gli strumenti normali:

sudo dpkg --configure -a
sudo apt --fix-broken install

Per i sistemi basati su RPM:

sudo dnf clean all
sudo rpm --rebuilddb

rpm --rebuilddb non è una prima risposta a ogni problema DNF. Usalo quando il database RPM stesso appare danneggiato, non quando un URL del repository è sbagliato.

Conflitti di Versione da Repository di Terze Parti

Molti guasti difficili dei pacchetti provengono da repository misti: un repository del fornitore, EPEL, un repository runtime del linguaggio, un repository Kubernetes o un vecchio mirror interno. Il gestore di pacchetti potrebbe fare esattamente ciò che gli è stato detto, ma le versioni disponibili non possono soddisfarsi a vicenda.

Sui sistemi APT, ispeziona la politica:

apt-cache policy <nome-pacchetto>
apt-cache madison <nome-pacchetto>

Sui sistemi DNF:

dnf repoquery --show-duplicates <nome-pacchetto>
dnf repolist --enabled

Se un repository di terze parti è il problema, disabilitalo temporaneamente e riprova la transazione:

sudo dnf --disablerepo='nome-repo' update

Per APT, commenta la voce sospetta in /etc/apt/sources.list.d/, esegui sudo apt update e prova di nuovo. Non lasciare il sistema in uno stato misterioso; documenta quale repository è stato disabilitato e perché.

Quando un Aggiornamento di Versione o un Aggiornamento Importante Fallisce

Gli aggiornamenti importanti meritano più cautela di una normale installazione di pacchetti. Prima di riprovare, assicurati di sapere se il sistema è tra le versioni, se i vecchi repository sono ancora abilitati e se i prompt di configurazione sono stati interrotti.

Su Debian o Ubuntu, controlla i file di versione e i pacchetti bloccati:

cat /etc/os-release
apt-mark showhold
sudo dpkg --audit

Sui sistemi basati su DNF, controlla i repository abilitati e il comportamento di sincronizzazione della distribuzione:

cat /etc/os-release
dnf repolist --enabled
sudo dnf distro-sync

distro-sync può declassare o sostituire i pacchetti per corrispondere ai repository abilitati, quindi leggi la transazione proposta prima di accettarla. Su sistemi importanti, fai prima uno snapshot o un backup. I gestori di pacchetti sono bravi nella matematica delle dipendenze, ma non possono sapere da quali file di configurazione locali, moduli del kernel o agenti del fornitore dipende la tua attività.

Suggerimenti Generali per la Risoluzione

Indipendentemente dal gestore di pacchetti, alcune pratiche generali possono farti risparmiare tempo e mal di testa:

• Leggi Attentamente i Messaggi di Errore: L'output di apt o yum/dnf contiene spesso indizi specifici sul problema.
• Controlla i Log di Sistema: /var/log/apt/history.log e /var/log/apt/term.log per APT, e /var/log/yum.log o /var/log/dnf.log per YUM/DNF, possono fornire una cronologia dettagliata delle transazioni e informazioni sugli errori.
• Aggiorna Regolarmente: Mantieni il tuo sistema e gli elenchi dei pacchetti aggiornati per ridurre al minimo la possibilità di incontrare dipendenze obsolete o problemi del repository.
• Usa sudo: Esegui sempre i comandi di gestione dei pacchetti con privilegi di superutente.
• Esegui il Backup dei Dati Critici: Prima di eseguire importanti aggiornamenti o installazioni di sistema, esegui il backup di tutti i dati critici. Questa è una rete di sicurezza se qualcosa va terribilmente storto.
• Isola il Problema: Se più pacchetti falliscono, prova ad aggiornarli o installarli uno per uno per identificare il pacchetto specifico che causa il problema.
• Leggi la transazione proposta prima di digitare sì: Le rimozioni sono importanti. Se un gestore di pacchetti vuole rimuovere un server di database, un pacchetto del kernel, un server SSH o un runtime principale, fermati e capisci perché.
• Preferisci le correzioni del repository rispetto ai flag di forza: La maggior parte dei guasti dei pacchetti provengono da metadati, repository o stato delle dipendenze. I flag di forza possono nascondere il sintomo mentre rendono il sistema più difficile da mantenere.

L'ordine di risoluzione più sicuro è coerente: controlla se c'è un altro processo di pacchetto in esecuzione, aggiorna i metadati, ripara le transazioni interrotte, ispeziona i repository, quindi affronta i conflitti di dipendenza. Riserva le rimozioni forzate e i bypass delle firme per casi eccezionali in cui comprendi il raggio d'esplosione e hai un percorso di rollback.