Ang VPN package na nag-uulat ng Installed: (none) ay hindi nawawala; hindi lamang ito naka-install. Ang linyang nagpapasya kung maaari mong i-install ito ay Candidate, na hinahango ng APT mula sa mga index, pangalan ng suite, arkitektura at anumang umiiral na panuntunan sa pag-pin. Karamihan sa mga ulat tungkol sa nawawalang VPN package ay lumalabas na problema sa kandidato at hindi problema sa packaging. Basahin ang dalawang linya bago hawakan kahit isang entry ng pinagmulan.

Sinusuri ko muna ang kandidato dahil isang utos lang ang kailangan at tinatanggal ang kalahati ng karaniwang haka-haka.

Ano ang sinasabi sa iyo ng output ng apt-cache policy

Binabasa ng apt-cache policy ang lokal na cache ng packages, hindi ang network. Ipinapakita nito ang naka-install na bersyon, ang bersyon ng kandidato at isang talahanayan ng bawat index na nag-aalok ng package kasama ang priyoridad na nakakabit dito.

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

Ang kandidato ay ang bersyon na pipiliin ng APT sa ngayon. Inililista ng madison kung ano ang inaalok ng bawat pinagmulan kasama ang priyoridad nito, at sa gayong paraan napapansin mo ang package na umiiral sa isang index ngunit natatalo sa kumpetisyon ng pag-pin. Dokumentado ng manwal ng apt-cache ang dalawa bilang pagbabasa ng cache, kaya wala sa kanila ang nagpapatunay na maaabot ang salamin sa sandaling ito.

Kung walang laman ang linyang kandidato o nagpapakita ng (none), wala sa mga naka-configure na pinagmulan ang karapat-dapat para sa sistemang ito ayon sa pagkaka-configure nito.

Apat na dahilan kung bakit nawawala ang kandidato

Sa pagsasagawa, ang dahilan ay halos palaging isa sa apat na bagay, at bawat isa ay may ibang lunas.

Ang pangalan ng suite sa iyong mga pinagmulan ay dapat tumugma sa distribusyon kung saan itinayo ang package. Ang sistemang Debian bookworm na nakaturo sa salamin na trixie, o isang release ng Ubuntu na pinangalanang muli sa isang file na sources.list.d habang nag-a-upgrade, ay walang nalulutas para sa mga package na umiiral lamang sa kabilang suite. Ihambing ang lsb_release -cs sa field ng suite sa bawat entry.

Nakikita lamang ng APT ang mga package na itinayo para sa mga arkitekturang kilala ng dpkg. Ang 32-bit na container, arm64 na imahe o pag-install sa Raspberry Pi na humihingi ng package na ipinapadala lamang para sa amd64 ay nakakakuha ng walang laman na kandidato sa halip na mensahe ng error. Sinasabi sa iyo ng dpkg --print-architecture at dpkg --print-foreign-architectures kung aling set ka talaga.

Mahalaga rin ang mga component. Ang package sa contrib o non-free ay hindi nakikita kapag main lamang ang pinagana, at ganoon din ang gawi ng universe ng Ubuntu. Umiiral ang index at naroon ang package; hindi lamang ito kasama sa iyong listahan ng mga pinaganang component.

Ang pag-pin ang tahimik na dahilan. Ang isang file sa /etc/apt/preferences.d ay maaaring magtakda ng package sa ibaba ng hangganan ng pag-install, at pagkatapos ay mawawala ang isang ganap na magandang kandidato sa output habang inililista pa rin ito ng index. Dahil ipinapakita ng policy ang mga priyoridad sa tabi ng bawat pinagmulan, ang package na ang bawat pinagmulan ay may mababang numero ng pin ang palatandaan.

Ang mga lumang index ay mukhang nawawalang package

Ang cache ay isang snapshot. Kung nabigo ang huling apt update sa isang index, patuloy na sumasagot ang mga query mula sa mas lumang kopya, at maaaring wala sa kopyang iyon ang package na inaasahan mo.

Nagpapakita ang apt update ng mga error bawat index, kaya basahin ang mga ito sa halip na dumiretso sa huling linya.

Ang refresh na nabigo dahil sa error sa pirma, nag-expire na file ng release o hindi maabot na salamin ay iniiwan ang nakaraang index sa kinaroroonan nito. Makatwirang disenyo iyon, dahil pinapanatili nito ang gumaganang cache kapag panandaliang bumaba ang salamin. Ang epekto ay maaaring magtagumpay ang paghahanap habang offline ang repository. Nangangahulugan din ito na walang pinatutunayan ang kawalan ng package hanggang malaman mo kung kailan huling nakuha ang index. Suriin ang mga petsa ng file sa ilalim ng /var/lib/apt/lists bago sisihin ang pangalan ng package.

Pangalanan ang package na talagang kailangan mo

OpenVPN ay isang daemon, at ang mga pirasong karaniwang kailangan ng mga tao ay hiwalay na package.

Ang engine, plugin ng NetworkManager at editor ng desktop ay tatlong package na may tatlong pangalan, at ang plugin ay may variant na GTK na iba ang pangalan sa iba't ibang distribusyon. Itinutugma ng apt-cache search --names-only openvpn ang mga pangalan at ibinigay na pangalan sa halip na mga paglalarawan, at iyon ang gusto mo kapag halos alam mo kung ano ang tawag sa bagay na iyon.

Kung talagang hindi kilala ang pangalan, maghanap nang isang beses sa mga paglalarawan, pagkatapos ay bumalik sa eksaktong mga pangalan. Huwag magdagdag ng hulaping -gui na hiniram mula sa ibang distribusyon at magpasya na wala nang package.

Baguhin ang mga pinagmulan sa huli, pagkatapos ay i-verify ang transaksyon

Ang pagdagdag ng repository ay nagbabago kung sino ang naghahatid ng iyong mga update, kaya kabilang ito sa dulo ng imbestigasyon, hindi sa simula.

Bago iyon, tiyakin ang release, arkitektura, component at katayuan ng pin. Isulat kung alin sa apat ang sinuri mo, upang hindi ulitin ng susunod na tao ang buong pagsusuri. Kung tama ang lahat ng apat at wala pa rin ang kandidato, ang tapat na konklusyon ay hindi ipinapadala ng release na ito ang package na iyon. Ang natitirang mga opsyon ay backport, package mula sa vendor o ibang sinusuportahang release, at bawat isa ay sadyang pagpili at hindi haka-haka.

Kapag lumitaw ang kandidato, gayahin muna bago ilapat: ipinapakita ng apt-get install --simulate kasama ang pangalan ng package kung ano ang hihilahin at kung ano ang aalisin. Ang pagiging available ng package, pag-install at gumaganang tunnel ay nananatiling tatlong magkakaibang yugto, at ang tunnel ay kailangan pa rin ng profile, kredensyal, ruta at DNS bago magdala ng trapiko.

Kaugnay na mga artikulo