En VPN-pakke som melder Installed: (none) mangler ikke; den er bare ikke installert. Linjen som avgjør om du kan installere den, er Candidate, som APT utleder fra indeksene, suite-navnet, arkitekturen og gjeldende pin-regler. De fleste rapporter om en forsvunnet VPN-pakke er egentlig et kandidatproblem, ikke et pakkeproblem. Les begge linjene før du endrer én eneste kildeoppføring.

Jeg sjekker kandidaten først fordi det koster én kommando og fjerner halvparten av de vanlige gjetningene.

Hva utskriften fra apt-cache policy viser

apt-cache policy leser den lokale pakkebufferen, ikke nettet. Den viser installert versjon, kandidatversjon og en tabell over hver indeks som tilbyr pakken, sammen med prioriteten.

apt-cache policy openvpn
apt-cache madison openvpn
apt list -a network-manager-openvpn

Kandidaten er versjonen APT ville valgt nå. madison viser hva hver kilde tilbyr med prioriteten sin, og slik oppdager du en pakke som finnes i en indeks, men taper pin-konkurransen. Håndboken for apt-cache beskriver begge som bufferlesinger, så ingen av dem beviser at speilet er tilgjengelig akkurat nå.

Er kandidatlinjen tom eller viser (none), er ingenting i de konfigurerte kildene kvalifisert for dette systemet slik det er konfigurert.

Fire årsaker til at en kandidat forsvinner

I praksis er årsaken nesten alltid én av fire ting, og hver har sin egen løsning.

Suite-navnet i kildene må samsvare med distribusjonen pakken ble bygget for. Et Debian bookworm-system rettet mot et trixie-speil, eller en Ubuntu-utgave som ble omdøpt i en sources.list.d-fil under en oppgradering, løser ingenting for pakker som bare finnes i den andre suiten. Sammenlign lsb_release -cs med suite-feltet i hver oppføring.

APT ser bare pakker bygget for arkitekturene dpkg kjenner. En 32-bits container, et arm64-image eller en Raspberry Pi-installasjon som ber om en pakke som bare leveres for amd64, får en tom kandidat i stedet for en feilmelding. dpkg --print-architecture og dpkg --print-foreign-architectures viser hvilket sett du faktisk er i.

Komponenter spiller også inn. En pakke i contrib eller non-free er usynlig når bare main er slått på, og Ubuntus universe oppfører seg likt. Indeksen finnes, og pakken ligger i den; listen over påslåtte komponenter inneholder den bare ikke.

Pinning er den stille årsaken. En fil i /etc/apt/preferences.d kan holde en pakke under installasjonsterskelen, og da forsvinner en helt fin kandidat fra utskriften mens indeksen fortsatt viser den. Siden policy skriver prioritetene ved siden av hver kilde, er en pakke der hver kilde har et lavt pinnummer det tydelige tegnet.

Utdaterte indekser ser ut som manglende pakker

Bufferen er et øyeblikksbilde. Hvis forrige apt update feilet på én indeks, fortsetter spørringene å svare fra den eldre kopien, og pakken du forventer er kanskje ikke der.

apt update skriver feil per indeks, så les dem i stedet for å rulle rett til siste linje.

En oppdatering som feiler på grunn av signaturfeil, utløpt release-fil eller utilgjengelig speil, lar den forrige indeksen bli stående. Det er en fornuftig løsning, fordi den beholder en fungerende buffer når et speil er kort nede. Bivirkningen er at et søk kan lykkes mens depotet er frakoblet. Det betyr også at fravær av en pakke ikke beviser noe før du vet når indeksen sist ble hentet. Sjekk fildatoene under /var/lib/apt/lists før du gir pakkenavnet skylden.

Navngi pakken du faktisk trenger

OpenVPN er en daemon, og delene folk flest vil ha, er egne pakker.

Motoren, NetworkManager-pluginen og skrivebordseditoren er tre pakker med tre navn, og pluginen har en GTK-variant med ulikt navn i ulike distribusjoner. apt-cache search --names-only openvpn matcher navn og oppgitte navn i stedet for beskrivelser, og det er det du vil når du omtrent vet hva tingen heter.

Er navnet virkelig ukjent, søk i beskrivelsene én gang, og gå så tilbake til eksakte navn. Ikke legg på en -gui-endelse lånt fra en annen distribusjon og konkluder med at pakken ikke finnes lenger.

Endre kilder til slutt, og verifiser deretter transaksjonen

Å legge til et depot endrer hvem som leverer oppdateringene dine, så det hører til slutten av undersøkelsen, ikke begynnelsen.

Før det, bekreft utgave, arkitektur, komponent og pin-status. Noter hvilke av de fire du sjekket, så neste person ikke gjentar gjennomgangen. Hvis alle fire stemmer og kandidaten fortsatt mangler, er den ærlige konklusjonen at denne utgaven ikke leverer den pakken. De gjenværende valgene er en backport, en leverandørpakke eller en annen støttet utgave, og hvert av dem er et bevisst valg og ikke en gjetning.

Når kandidaten dukker opp, simuler før du bekrefter: apt-get install --simulate med pakkenavnet viser hva som ville blitt hentet og hva som ville blitt fjernet. Pakketilgjengelighet, installasjon og en fungerende tunnel er fortsatt tre separate trinn, og tunnelen trenger fortsatt profilen, påloggingsinformasjonen, rutene og DNS før den bærer trafikk.

Relaterte artikler