Ubuntu APT-probleemoplossing: gebroken pakketten, holds en GPG-fouten oplossen

Apt-fouten komen veel voor op Ubuntu-systemen die al langere tijd draaien, en ze treden meestal op na een versie-upgrade, een wijziging in een extern repository, een verwijderde PPA, een handmatig geïnstalleerde .deb-bestand of een onderbroken pakketinstallatie.

De foutmelding kan dramatisch overkomen, maar de meeste APT-problemen zijn niet mysterieus — het zijn statusproblemen waarbij het beeld dat APT heeft van repositories, versies en geïnstalleerde pakketten niet meer klopt.

APT probeert vier vragen te beantwoorden:

1. Welke repositories zijn ingeschakeld?
2. Welke pakketversies zijn beschikbaar?
3. Welke pakketten zijn al geïnstalleerd?
4. Welke pakketwijzigingen zijn toegestaan?

Wanneer deze antwoorden met elkaar in conflict komen, krijg je vastgehouden pakketten, gebroken afhankelijkheden, ontbrekende openbare sleutels, fouten met slechte PPAs of pakketten die tijdens een upgrade achterblijven. Deze handleiding biedt je een praktische stappenplan voor het oplossen van Ubuntu APT-problemen, geschreven voor ontwikkelaars, DevOps-engineers en Linux-gebruikers die het systeem willen repareren zonder willekeurig commando’s van forumthreads over te nemen. Combineer dit met onze Ubuntu APT en dpkg cheat sheet voor dagelijkse installatie- en upgrade-commando’s, en bekijk de bredere Developer Tools-collectie voor gerelateerde Linux-workflows.

De korte versie

Als je systeem slechts licht beschadigd is, begin hier:

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

Als pakketten achterblijven:

apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Als een PPA of extern repository faalt:

ls /etc/apt/sources.list.d/
sudo apt update

Lees de regel van het faalende repository, en schakel dat repository dan uit of repareer het. Als je NO_PUBKEY ziet, importeer dan niet blindelings willekeurige sleutels van een keyserver — zoek de officiële instructies van het repository, installeer de repository-sleutel in /etc/apt/keyrings en koppel deze aan dat repository met signed-by.

Voordat je iets repareert: lees eerst de APT-fout

Voer dit eerst uit:

sudo apt update

Sla het niet over. apt update verfrist de pakketmetadata. Het upgradet geen pakketten. Het vertelt je of Ubuntu alle geconfigureerde repositories kan lezen en de metadata ervan kan verifiëren.

Controleer vervolgens je Ubuntu-versie en codenaam — een verouderde release-naam in /etc/apt/sources.list.d/ is een veelvoorkomende oorzaak van 404- en Release-bestandfouten. Als je niet zeker weet welke release je gebruikt, zie hoe je je Ubuntu-versie kunt controleren:

lsb_release -a

Of:

cat /etc/os-release

Controleer ook wat upgradable is:

apt list --upgradable

En controleer of er pakketten vastgehouden worden:

apt-mark showhold

Dit geeft je de eerste splitsing in de beslissingsboom — het identificeren van de klasse van het probleem maakt het oplossen makkelijker, omdat elke klasse een andere eerste reparatie heeft:

• Repository-probleem: apt update faalt.
• Afhankelijkheidsprobleem: apt update werkt, maar installatie of upgrade faalt.
• Vastgehouden pakketprobleem: APT weigert specifieke pakketten te wijzigen.
• Gemengd bronprobleem: Een PPA, handmatig .deb of oud repository biedt incompatibele versies.
• Onderbroken installatieprobleem: dpkg heeft pakketten uitgepakt die nooit zijn geconfigureerd.

Veelvoorkomende Ubuntu APT-fouttypen

Achterblijvende pakketten

Een achterblijvend pakket is niet altijd een fout; het betekent dat APT heeft gekozen om een pakket niet te upgraden met het huidige commando. Dit gebeurt vaak wanneer de upgrade het installeren van nieuwe afhankelijkheden vereist, het verwijderen van oude pakketten, of het wijzigen van een pakket op een manier die een gewone apt upgrade niet zal uitvoeren.

Controleer details:

apt list --upgradable
apt-cache policy package-name

Probeer een volledige upgrade pas nadat je hebt gelezen wat APT wil doen:

sudo apt full-upgrade

full-upgrade is toegestaan om nieuwe pakketten te installeren en pakketten te verwijderen indien nodig om de upgrade te voltooien. Dat is handig, maar het is ook de reden waarom je de voorgestelde wijzigingen moet lezen voordat je accepteert. Op een werkstation is full-upgrade meestal prima na controle; op een server moet je de verwijderingen twee keer lezen.

Vastgehouden pakketten

Een vastgehouden pakket is anders dan een pakket dat slechts achterblijft. Een vasthouden is een expliciete instructie die APT voorkomt automatisch dat pakket te installeren, upgraden of verwijderen. Vasthouden is handig voor het vastpinnen van een kernel, database, driver of runtime-versie, en het is ook makkelijk te vergeten.

Lijst vastgehouden pakketten:

apt-mark showhold

Houd een pakket vast:

sudo apt-mark hold package-name

Verwijder een vasthouden:

sudo apt-mark unhold package-name

Als je afhankelijkheidsfouten ziet die betrekking hebben op een vastgehouden pakket, beslis dan of het vasthouden nog steeds opzettelijk is. Verwijder vasthoudingen niet automatisch. Ze kunnen een productiedienst, driver of compatibiliteitsgevoelige toolchain beschermen.

Gebroken afhankelijkheden

Gebroken afhankelijkheden betekenen dat APT geen geldige pakketset kan vinden, wat meestal wijst op een versieconflict in plaats van een beschadigde download.

Veelvoorkomende oorzaken zijn:

• Een pakket vereist een versie die niet beschikbaar is.
• Een PPA biedt een nieuwere bibliotheek dan Ubuntu verwacht.
• Een handmatig geïnstalleerde .deb is afhankelijk van pakketten van een andere release.
• Een pakketinstallatie is onderbroken.
• Een repository voor de verkeerde Ubuntu-release is ingeschakeld.
• Pakket-pinning of vasthoudingen verhinderen de benodigde versiewijziging.

Begin met:

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

Inspecteer vervolgens het pakket:

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Gebruik vervolgens die commando’s om het pakketversieconflict te vinden dat APT blokkeert, in plaats van elke reparatiecommando achter elkaar uit te voeren.

GPG-sleutel- en NO_PUBKEY-fouten

Een NO_PUBKEY-fout betekent dat APT repository-metadata heeft ontvangen, maar de handtekening niet kan verifiëren omdat de vereiste openbare sleutel ontbreekt — een vertrouwensprobleem, niet slechts een downloadprobleem.

Een typische fout ziet er zo uit:

The following signatures could not be verified because the public key is not available: NO_PUBKEY ABCD1234EF567890

Oude instructies gebruikten vaak apt-key add, maar vermijd dat voor nieuwe repository-instellingen. Moderne Ubuntu-systemen moeten een repository-specifieke keyring en signed-by gebruiken.

Een beter patroon ziet er zo uit:

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/repo-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Vervang de URL en repository-regel met de officiële instructies van de leverancier.

Het belangrijke deel is dit:

signed-by=/etc/apt/keyrings/example.gpg

Die signed-by-regel koppelt de sleutel aan één repository, wat schoner en veiliger is dan elke externe sleutel in een globale vertrouwensopslag te plaatsen.

Fouten met slechte PPAs of Release-bestanden

PPA-falen ziet er vaak zo uit:

The repository does not have a Release file.

Of:

404 Not Found

Veelvoorkomende oorzaken:

• De PPA ondersteunt je Ubuntu-release niet.
• Je hebt Ubuntu geüpgraded, maar de PPA verwijst nog steeds naar de oude codenaam.
• De PPA is verwijderd.
• De maintainer is gestopt met het publiceren van pakketten.
• Je hebt een PPA toegevoegd die bedoeld is voor een andere Ubuntu-versie.

Controleer je codenaam:

. /etc/os-release
echo "$VERSION_CODENAME"

Lijst externe bronbestanden:

ls /etc/apt/sources.list.d/

Inspecteer ze:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Schakel een verdachte bron uit door deze om te dopen:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Als APT werkt nadat je het bestand hebt uitgeschakeld, heb je de problematische bron gevonden en kun je deze permanent repareren of verwijderen.

Een veilig APT-troubleshooting-workflow

Stap 1: Verfris metadata

sudo apt update

Als dit faalt, repareer repositories voordat je pakketreparatie probeert. APT kan afhankelijkheden niet correct oplossen als zijn pakketindex verouderd of onvolledig is.

Zoek naar regels die bevatten:

NO_PUBKEY
Release file
404 Not Found
does not have a Release file
The repository is not signed

Dit zijn repository- of vertrouwensproblemen, en ze moeten worden opgelost voordat je enige pakketreparatie probeert.

Stap 2: Voltooi onderbroken pakketconfiguratie

Als een pakketinstallatie is onderbroken, kan dpkg bestanden hebben uitgepakt maar het pakket niet hebben geconfigureerd.

Voer uit:

sudo dpkg --configure -a

Als dit slaagt, ga door:

sudo apt --fix-broken install

Als het faalt, lees de pakketnaam en de fout zorgvuldig. Het pakket dat onderaan de fout wordt genoemd, is vaak belangrijker dan het pakket dat je oorspronkelijk probeerde te installeren.

Stap 3: Vraag APT om afhankelijkheden te repareren

sudo apt --fix-broken install

Dit commando vraagt APT om afhankelijkheidsproblemen te corrigeren door ontbrekende afhankelijkheden te installeren of pakketten te verwijderen die niet kunnen worden voldaan. Lees de voorgestelde actie zorgvuldig, vooral eventuele verwijderingen.

Wees voorzichtig als APT wil verwijderen:

• ubuntu-desktop
• ubuntu-server
• linux-generic
• display manager-pakketten
• netwerk-pakketten
• database-pakketten
• container runtime-pakketten
• desktopomgeving-pakketten

Soms is het verwijderen van een metapakket onschuldig. Soms is het een waarschuwingssignaal dat je pakketbronnen slecht zijn gemengd. Accepteer geen grote verwijderingen zonder ze te begrijpen.

Stap 4: Controleer vastgehouden pakketten

apt-mark showhold

Als een vastgehouden pakket de upgrade blokkeert, inspecteer het:

apt-cache policy package-name

Als het vasthouden niet langer nodig is:

sudo apt-mark unhold package-name
sudo apt update
sudo apt upgrade

Als het vasthouden opzettelijk is, vecht dan niet met APT — repareer het repository of de pakketselectie rond het vasthouden in plaats van de bescherming te verwijderen.

Stap 5: Inspecteer pakketversies

Voor een pakket met afhankelijkheidstrouble:

apt-cache policy package-name

Dit toont:

• Geïnstalleerde versie
• Kandidaatversie
• Beschikbare versies
• Welk repository elke versie biedt

apt-cache policy is een van de meest nuttige APT-debugcommando’s omdat het toont van waar elke beschikbare versie komt.

Voorbeeld:

apt-cache policy docker-ce

Als de kandidaatversie komt van een onverwachte PPA of oud repository, heb je de waarschijnlijke oorzaak van het afhankelijkheidsconflict gevonden.

Stap 6: Zoek naar gemengde repositories

Lijst ingeschakelde bronnen:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Zoek naar:

• Oude Ubuntu-codenames
• Debian-repositories op Ubuntu
• PPAs voor een andere Ubuntu-release
• Dubbele vendor-repositories
• Zowel Snap- als APT-instructies gemengd voor hetzelfde hulpmiddel
• Oude .list-bestanden die achterblijven na het verwijderen van software

Een veelvoorkomend anti-patroon is het installeren van een hulpmiddel uit een vendor-repository, en later het toevoegen van een PPA of handmatig .deb dat overlappende bibliotheken biedt. APT kan veel bronnen aan, maar het kan conflicterende intenties niet verzoenen tenzij je de repositories zelf uitlijnt.

Stap 7: Probeer een gesimuleerde installatie of upgrade

Voordat je wijzigingen maakt, simuleer:

apt -s install package-name

Of:

apt -s full-upgrade

De -s-optie simuleert de operatie. Het is nuttig wanneer je wilt zien wat APT zou doen zonder het systeem te wijzigen.

Vastgehouden pakketten repareren

Lijst vastgehouden pakketten

apt-mark showhold

Als er niets wordt afgedrukt, zijn er geen pakketten vastgehouden met apt-mark, en kun je doorgaan met afhankelijkheids- of repository-controles.

Houd een pakket opzettelijk vast

sudo apt-mark hold package-name

Goede redenen om een pakket vast te houden:

• Een kernelversie is bekend om te werken met je hardware.
• Een database-upgrade vereist planning.
• Een driver-update breekt je GPU.
• Een runtime-versie moet overeenkomen met productie.
• Een vendor-pakket is niet compatibel met de nieuwste afhankelijkheid.

Slechte redenen om een pakket vast te houden:

• Je hebt een commando gekopieerd uit een oude handleiding.
• Je bent vergeten waarom het vastgehouden werd.
• Je vermijdt een afhankelijkheidsfout zonder deze te begrijpen.

Verwijder een vasthouden

sudo apt-mark unhold package-name

Vervolgens updaten en upgraden:

sudo apt update
sudo apt upgrade

Als het pakket nog steeds niet upgradet, was het niet slechts een vasthoudprobleem. Controleer policy:

apt-cache policy package-name

Gebroken afhankelijkheden repareren

De standaard reparatievolgorde

Gebruik deze volgorde wanneer pakketinstallatie of upgrade halverwege faalde:

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

Deze volgorde is belangrijk omdat elke stap de grond bereidt voor de volgende: apt update verfrist repository-metadata, dpkg --configure -a voltooit het configureren van uitgepakte pakketten, apt --fix-broken install laat APT ontbrekende of conflicterende afhankelijkheden verzoenen, en apt upgrade hervat normale pakket-upgrades.

Verwijder een slecht geïnstalleerd lokaal pakket

Als het probleem begon na het installeren van een gedownload .deb, inspecteer het:

dpkg -l | grep package-name
apt-cache policy package-name

Verwijder het:

sudo apt remove package-name

Als configuratiebestanden ook problemen veroorzaken:

sudo apt purge package-name

Vervolgens repareren:

sudo apt --fix-broken install

Herstel een beschadigd pakket

Als een pakket is geïnstalleerd maar beschadigd is:

sudo apt install --reinstall package-name

Dit is nuttig wanneer bestanden ontbreken of beschadigd zijn, maar de pakketbronnen anders gezond zijn en je de geïnstalleerde bestanden wilt vernieuwen zonder versies te wijzigen.

PPA- en externe repository-problemen repareren

Vind PPAs en externe repositories

ls /etc/apt/sources.list.d/

Toon actieve repository-regels:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Op nieuwere Ubuntu-systemen kun je ook .sources-bestanden zien die het deb822-formaat gebruiken:

ls /etc/apt/sources.list.d/*.sources

Toon ze:

cat /etc/apt/sources.list.d/*.sources

Schakel een PPA veilig uit

Hernoem het bronbestand:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Voor deb822-bestanden:

sudo mv /etc/apt/sources.list.d/example.sources /etc/apt/sources.list.d/example.sources.disabled
sudo apt update

Het hernoemen van het bronbestand is omkeerbaar en veiliger dan het onmiddellijk verwijderen van repository-configuratie, omdat je het terug kunt hernoemen als je de verkeerde bron hebt uitgeschakeld.

Verwijder pakketten uit een PPA

Het uitschakelen van een PPA stopt toekomstige pakketdownloads ervan. Het downgradet niet automatisch pakketten die al van die PPA zijn geïnstalleerd.

Als de PPA bibliotheekconflicten veroorzaakte, moet je mogelijk pakketten terugdowngraden naar Ubuntu-versies.

Installeer ppa-purge:

sudo apt install ppa-purge

Vervolgens de PPA purgen:

sudo ppa-purge ppa:owner/name

Gebruik ppa-purge voorzichtig en lees de voorgestelde wijzigingen voordat je accepteert, omdat het meerdere gerelateerde pakketten kan verwijderen of downgraden.

Na een release-upgrade

Na het upgraden van Ubuntu zijn oude PPAs een veelvoorkomende bron van fouten.

Controleer op oude codenames:

grep -R "jammy\|noble\|oracular\|plucky" /etc/apt/sources.list /etc/apt/sources.list.d/

Pas de codenames aan voor je echte systeem. Bijvoorbeeld, als je op Ubuntu 24.04 zit, is je codenaam noble. Als een externe bron nog steeds verwijst naar een oudere codenaam, verifieer dan of die vendor je huidige Ubuntu-release ondersteunt. Als je een nieuwe machine instelt in plaats van een upgrade te repareren, loopt onze Ubuntu 24.04 installatiehandleiding door het toevoegen van vendor-repositories met signed-by vanaf het begin.

Wijzig niet zomaar de codenaam en hoop op het beste — sommige repositories publiceren geen pakketten voor elke Ubuntu-versie, dus verifieer eerst vendor-ondersteuning voor je release.

GPG- en NO_PUBKEY-fouten repareren

Wat NO_PUBKEY betekent

APT-repositories publiceren ondertekende metadata, en je machine heeft de overeenkomstige openbare sleutel nodig om die metadata te verifiëren. Als de sleutel ontbreekt, weigert APT het repository te vertrouwen, wat het gedrag is dat je wilt — schakel handtekeningcontroles niet uit om de fout te laten verdwijnen.

Het moderne keyring-patroon

Maak de keyring-map:

sudo install -d -m 0755 /etc/apt/keyrings

Download en dearmor de vendor-sleutel:

curl -fsSL https://example.com/repository-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

Stel leesbare rechten in:

sudo chmod 0644 /etc/apt/keyrings/example.gpg

Voeg het repository toe met signed-by:

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/example.list

Vervolgens updaten:

sudo apt update

Vervang noble met je Ubuntu-codenaam indien nodig:

. /etc/os-release
echo "$VERSION_CODENAME"

Waarom apt-key de verkeerde gewoonte is

Oude handleidingen gebruiken vaak:

curl -fsSL https://example.com/key.gpg | sudo apt-key add -

Vermijd apt-key add voor nieuwe setups. De oude apt-key-stijl voegt sleutels toe aan een breed vertrouwingsgebied, wat het moeilijker maakt te redeneren welke sleutel vertrouwd wordt voor welk repository, terwijl de moderne signed-by-stijl de sleutel beperkt tot een specifiek repository en basale supply-chain-hygiëne is.

Vind legacy vertrouwde sleutels

Je hebt mogelijk nog oude sleutels in:

/etc/apt/trusted.gpg
/etc/apt/trusted.gpg.d/

Lijst bestanden:

ls -l /etc/apt/trusted.gpg.d/

Verwijder sleutels niet willekeurig — map eerst elke sleutel naar een repository, migreer dan één repository tegelijk naar /etc/apt/keyrings en signed-by.

Veelvoorkomende GPG-fouten

Gebruik geen willekeurige keyservers als je eerste keuze bij het repareren van NO_PUBKEY-fouten.

Betere volgorde:

1. Gebruik de officiële installatiedocumentatie van de vendor.
2. Download de sleutel van de officiële HTTPS-URL van de vendor.
3. Bewaar deze in /etc/apt/keyrings.
4. Koppel deze met signed-by.
5. Voer sudo apt update uit.

Vermijd deze snelkoppelingen:

sudo apt update --allow-unauthenticated
sudo apt install --allow-unauthenticated package-name

Ze kunnen tijdelijk werken, maar ze verwijderen de handtekeningverificatie die je beschermt tegen gemanipuleerde repository-metadata.

“Het repository is niet ondertekend” repareren

Deze fout betekent meestal een van deze dingen:

• Het repository publiceert geen ondertekende metadata.
• De repository-URL is verkeerd.
• Het repository ondersteunt je Ubuntu-versie niet meer.
• Een proxy of mirror retourneert de verkeerde inhoud.
• Je gebruikt HTTP waar de vendor nu HTTPS verwacht.
• Het bronbestand heeft de verkeerde suite of component.

Vind de faalende bron:

sudo apt update

APT zal de URL afdrukken. Zoek er dan naar:

grep -R "example.com" /etc/apt/sources.list /etc/apt/sources.list.d/

Schakel het tijdelijk uit:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Als APT weer werkt nadat je het bestand hebt uitgeschakeld, installeer dat repository opnieuw vanuit de huidige officiële instructies van de vendor in plaats van de oude configuratie opnieuw in te schakelen.

Waarschuwingen voor dubbele repositories repareren

APT kan waarschuwen dat een doel meerdere keren is geconfigureerd.

Lijst overeenkomende entries:

grep -R "repo-url-or-domain" /etc/apt/sources.list /etc/apt/sources.list.d/

Dubbele repositories verschijnen vaak na het meerdere keren uitvoeren van vendor-installatiescripts.

Behoud één bronbestand. Schakel de anderen uit:

sudo mv /etc/apt/sources.list.d/duplicate.list /etc/apt/sources.list.d/duplicate.list.disabled
sudo apt update

Dubbele waarschuwingen zijn niet altijd fataal, maar ze zijn een teken van slordige configuratie, dus behoud één bronbestand en schakel de dubbele uit.

Pakketten van de verkeerde Ubuntu-release repareren

Een van de ergste APT-problemen is het mengen van Ubuntu-releases — bijvoorbeeld, een machine op Ubuntu 24.04 zou niet zomaar pakketten van Ubuntu 22.04 of Debian testing moeten ophalen. Soms werkt het een tijdje, maar uiteindelijk wordt het afhankelijkheidsgrafiek een puzzel die APT niet netjes kan oplossen.

Controleer je release:

. /etc/os-release
echo "$VERSION_CODENAME"

Zoek in bronnen:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Zoek naar vreemde codenames in de ingeschakelde bronnen, inspecteer dan het betreffende pakket:

apt-cache policy package-name

Als de geïnstalleerde versie afkomstig is van een oud of vreemd repository, schakel dat repository uit en downgrad of installeer het betreffende pakket opnieuw vanuit Ubuntu-repositories.

Een conservatieve reparatiepad is:

sudo apt update
sudo apt install --reinstall package-name

Voor diepere conflicten moet je mogelijk het pakket verwijderen en het opnieuw installeren vanuit de juiste bron in plaats van een upgrade te forceren over een vreemde versie.

APT-cache en ongebruikte pakketten opschonen

APT-cache-opruiming is geen afhankelijkheidsfix op zich, maar het kan helpen na veel mislukte installaties door schijfruimte terug te winnen en verouderde pakketbestanden te wissen.

Verwijder pakketten die automatisch zijn geïnstalleerd en niet langer nodig zijn:

sudo apt autoremove

Wis gedownloade pakketbestanden:

sudo apt clean

Of verwijder alleen verouderde pakketbestanden:

sudo apt autoclean

Gebruik autoremove voorzichtig op servers en desktops met handmatig geïnstalleerde driver-stacks, en lees de verwijderingslijst voordat je accepteert.

Praktische APT-troubleshooting-recepten

Recept: Pakket blijft achter

sudo apt update
apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Als APT redelijke wijzigingen voorstelt na simulatie, accepteer ze. Als het grote verwijderingen voorstelt, stop en inspecteer:

apt-cache policy package-name

Recept: Vastgehouden pakket blokkeert upgrade

apt-mark showhold
apt-cache policy package-name
sudo apt-mark unhold package-name
sudo apt upgrade

Maak alleen een pakket los als het vasthouden niet langer opzettelijk is, omdat het verwijderen van een vasthouden dat productsoftware beschermt, een brekende upgrade kan triggeren.

Recept: Onderbroken installatie

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

Recept: NO_PUBKEY-fout

1. Identificeer het repository van sudo apt update.
2. Vind de huidige officiële installatie-instructies van de vendor.
3. Installeer de sleutel in /etc/apt/keyrings.
4. Gebruik signed-by in het bronbestand.
5. Voer sudo apt update uit.

Voorbeeldstructuur:

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

sudo chmod 0644 /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/ubuntu noble main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Recept: PPA heeft geen Release-bestand

sudo apt update
ls /etc/apt/sources.list.d/
grep -R "ppa.launchpadcontent.net\|launchpad" /etc/apt/sources.list.d/

Schakel de PPA uit:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Beslis dan of je pakketten uit die PPA wilt verwijderen, vervangen of purgen.

Recept: Handmatig .deb brak afhankelijkheden

dpkg -l | grep package-name
apt-cache policy package-name
sudo apt remove package-name
sudo apt --fix-broken install

Als je de software nog steeds nodig hebt, geef dan de voorkeur aan het huidige APT-repository van de vendor boven herhaalde handmatige .deb-installaties, die neigen om afhankelijkheidsconflicten over tijd op te hopen.

Essentiële APT-troubleshooting-commando’s

Repository en metadata

sudo apt update
grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/
ls /etc/apt/sources.list.d/

Pakketstatus

apt list --installed
apt list --upgradable
apt-mark showhold
dpkg -l | grep package-name

Pakketpolicy en afhankelijkheden

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Reparatie

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt install --reinstall package-name
sudo apt full-upgrade

Opschonen

sudo apt autoremove
sudo apt autoclean
sudo apt clean

Simulatie

apt -s install package-name
apt -s full-upgrade

Wat je niet moet doen

Verwijder niet willekeurig /var/lib/dpkg

Als je advies ziet om dpkg-statusbestanden te verwijderen, wees dan sceptisch. De dpkg-database is het register van geïnstalleerde pakketten, en het verwijderen van delen ervan kan een repareerbaar pakketprobleem veranderen in een volledig systeemherstelproject.

Schakel handtekeningverificatie niet uit

Vermijd:

--allow-unauthenticated

Als een repository niet geverifieerd kan worden, repareer dan de sleutel of schakel het repository uit in plaats van authenticatie te omzeilen.

Meng Ubuntu-releases niet casually

Voeg geen repositories toe voor een andere Ubuntu-release tenzij je APT-pinning en de afhankelijkheidsgevolgen begrijpt.

Dit geldt vooral voor:

• desktopomgevingen
• grafische drivers
• Python-stacks
• container runtimes
• Kubernetes-pakketten
• database-pakketten

Behandel PPAs niet als onschuldig

PPAs zijn nuttig, maar ze zijn nog steeds repository’s die bibliotheken en systeem-pakketten kunnen vervangen — wat precies kan zijn wat je wilt, of precies waarom je volgende upgrade breekt. Geef de voorkeur aan PPAs voor specifieke applicaties, niet voor brede systeemfondamenten, tenzij je de maintainer vertrouwt en het upgrade-pad begrijpt.

APT-troubleshooting-beslissingsboom

Gebruik dit mentale model:

De meeste APT-problemen worden beheersbaar zodra je stopt met ze te behandelen als één grote fout en begint met het scheiden van repository-gezondheid, pakketstatus, afhankelijkheidsoplossing en vertrouwingsconfiguratie — de beslissingsboom hierboven is een afkorting voor die discipline.

Aanbevolen basis voor ontwikkelaarsmachines

Voor een schone Ubuntu-ontwikkelaarswerkstation, ik heb deze voorkeur:

• Houd Ubuntu-repositories standaard.
• Gebruik vendor APT-repositories alleen wanneer ze officieel en onderhouden zijn.
• Gebruik /etc/apt/keyrings en signed-by voor externe repositories.
• Vermijd oude apt-key-instructies.
• Vermijd het mengen van PPAs die kernsysteem-bibliotheken vervangen.
• Gebruik containers, uv, pipx, asdf, mise of taal-specifieke tools voor snel veranderende ontwikkelaarsafhankelijkheden.
• Houd APT verantwoordelijk voor het besturingssysteem, drivers, diensten en stabiele CLI-tools.

Voor desktopsoftware, geef de voorkeur aan Flatpak of Snap boven PPAs wanneer een sandboxed universeel pakket aan je behoeften voldoet. APT is uitstekend wanneer het het basissysteem beheert, maar het wordt pijnlijk wanneer het gedwongen wordt te fungeren als een universeel ontwikkelaarsafhankelijkheidsbeheerdersysteem voor snel veranderende taal-ecosystemen.

Eindcontrolelijst voor APT-troubleshooting

Wanneer APT gebroken is op Ubuntu, werk door deze controlelijst:

[ ] Voer sudo apt update uit en lees de eerste echte fout.
[ ] Controleer Ubuntu-codenaam met /etc/os-release.
[ ] Voltooi onderbroken installaties met dpkg --configure -a.
[ ] Repareer afhankelijkheden met apt --fix-broken install.
[ ] Controleer vastgehouden pakketten met apt-mark showhold.
[ ] Inspecteer pakketversies met apt-cache policy.
[ ] Schakel gebroken PPAs of externe repositories uit.
[ ] Vervang apt-key-stijl repositories met signed-by keyrings.
[ ] Simuleer riskante operaties met apt -s.
[ ] Lees verwijderingen voordat je full-upgrade of autoremove accepteert.

APT is niet breekbaar, maar het is streng, en die strengheid is een functie: het voorkomt dat niet-ondertekende repositories, onmogelijke afhankelijkheidssets en per ongeluk vervangen pakketten je systeem stil wijzigen. De kalmte manier om APT te repareren is om die strengheid te behouden, het conflicterende status te vinden, en het kleinst ding te repareren dat werkelijk fout is.