Linux: apt / dnf / pacman зламаліся — прычыны і спосабы выпраўлення

У Linux такія менеджары пакетаў, як apt, dnf і pacman, з’яўляюцца асновай усталявання і абнаўлення праграм. Калі яны выглядаюць “зламанымі”, праблема не абмяжоўваецца толькі тым, што нельга ўсталяваць новыя праграмы. Часта спыняюцца і абнаўленні бяспекі, а абслугоўванне сістэмы становіцца значна цяжэйшым. Звычайныя прычыны — перарванае абнаўленне, няспраўнае люстэрка, несумяшчальная база пакетаў, памылкі подпісу, зламаныя залежнасці або lock-файлы, што засталіся пасля збою. Галоўнае — не пачынаць адразу выпадкова выдаляць cache або канфігурацыю, а спачатку зразумець, што менавіта насамрэч пашкоджана.

Часам здаецца, што зламаўся сам менеджар пакетаў, хоць сапраўдная прычына ў сетцы, DNS, наладах repository або недахопе месца на дыску. Таму праверку трэба пачынаць з разумення, ці гэта праблема сувязі, repository, лакальнай базы або залежнасцей.

Тыповыя сімптомы

• apt update, dnf update або pacman -Syu спыняюцца з памылкай
• З’яўляюцца паведамленні пра немагчымасць вырашыць залежнасці або пра пашкоджаныя пакеты
• Repository немагчыма выкарыстоўваць з-за GPG- або подпісных памылак
• База пакетаў заблакаваная, і ніякія аперацыі не працуюць
• Люстэркі вяртаюць 404 або timeout
• Пасля перарванага абнаўлення пакетныя аперацыі перастаюць нармальна працаваць
• Пасля абнаўлення некаторых бібліятэк сам менеджар пакетаў больш не запускаецца

Што трэба праверыць спачатку

Першы крок — высветліць, ці сапраўды праблема ў менеджары пакетаў, а не ў сетцы ці DNS.

ping -c 4 8.8.8.8
ping -c 4 google.com
ip addr
ip route

Калі сама сетка або DNS ужо няспраўныя, збой apt, dnf або pacman будзе толькі наступствам. Калі ж звычайная сетка працуе, а памылкі ёсць толькі ў пакетных аперацыях, трэба правяраць repository, ключы, lock-файлы, cache, базы і залежнасці.

Агульныя прычыны праблем з apt / dnf / pacman

1. Перарванае абнаўленне

Адна з самых частых прычын — абнаўленне, якое спынілася ў сярэдзіне працэсу. Адключэнне электрычнасці, закрыты тэрмінал, разарваная SSH-сесія або завісанне графічнага інтэрфейсу могуць пакінуць базу пакетаў або асобныя пакеты ў прамежкавым стане.

У такой сітуацыі лепш не пачынаць выдаляць файлы, а спачатку паспрабаваць карэктна завяршыць незакончаны стан.

2. Lock-файлы, што засталіся

Менеджары пакетаў выкарыстоўваюць lock, каб не запускаць некалькі аперацый адначасова. Калі яшчэ працуе іншы працэс, або пасля crash застаўся толькі lock-файл, сістэма паведаміць, што менеджар пакетаў ужо выкарыстоўваецца.

Але выдаляць lock-файлы ўсляпую нельга. Спачатку трэба пераканацца, што адпаведныя працэсы сапраўды ўжо не працуюць.

ps aux | grep -E 'apt|dpkg|dnf|yum|pacman'

3. Пашкоджаная канфігурацыя repository

Староннія repository, састарэлыя PPA, неактуальныя люстэркі або астаткі налад пасля абнаўлення дыстрыбутыва могуць зрабіць крыніцы пакетаў несапраўднымі. Тыповыя прыкметы — 404, адсутнасць Release file або памылкі загрузкі metadata.

4. Праблемы з GPG-ключамі і подпісамі

Repository звычайна праходзяць крыптаграфічную праверку. Калі ключ састарэў, не імпартаваны, змянілася сістэма кіравання ключамі або пашкоджаны лакальны keyring, менеджар пакетаў спыніцца з меркаванняў бяспекі.

5. Пашкоджаныя залежнасці

Залежнасці часта ламаюцца, калі прымусова ўсталёўваюцца несумяшчальныя версіі пакетаў, змешваюцца розныя repository, робяцца частковыя абнаўленні або ўручную перазапісваюцца сістэмныя бібліятэкі. Асабліва небяспечна гэта ў сістэмах з pacman, але apt і dnf таксама становяцца нестабільнымі пры змешванні крыніц без кантролю.

6. Пашкоджаны cache або metadata

Няпоўнасцю загружаныя пакеты, старыя metadata або пашкоджаныя базы сінхранізацыі могуць не даць карэктна прачытаць спісы пакетаў або завяршыць усталёўку.

7. Недахоп месца на дыску

Яшчэ адна частая, але часта недаацэненая прычына — недахоп вольнага месца. Калі раздзелы накшталт /var або /boot запоўненыя, распакоўка і запіс файлаў могуць сарвацца на паўдарозе і пакінуць сістэму пакетаў у некарэктным стане.

df -h
du -sh /var/cache/* 2>/dev/null

Што важна праверыць, калі не працуе apt

У Debian і Ubuntu трэба глядзець не толькі на apt, але і на стан dpkg, які працуе на ніжнім узроўні.

Выпраўленне пакетаў, што не былі сканфігураваныя

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

Пасля перарванага абнаўлення гэтыя дзве каманды часта з’яўляюцца першым і самым карысным крокам.

Паўторная загрузка спісаў пакетаў

sudo apt update

Калі тут узнікаюць 404, подпісныя памылкі або Release file error, трэба праверыць /etc/apt/sources.list і змесціва /etc/apt/sources.list.d/.

Ачыстка cache

sudo apt clean
sudo apt autoclean

Калі прычына ў пашкоджаным або старым cache, гэта можа дапамагчы.

Што важна праверыць, калі не працуе dnf

У сістэмах Fedora / RHEL галоўную ўвагу трэба звяртаць на metadata, гісторыю транзакцый і канфігурацыю repository.

Перастварэнне metadata

sudo dnf clean all
sudo dnf makecache

Калі пашкоджаны дадзеныя люстэркаў або metadata, гэта часта дапамагае.

Праверка залежнасцей і ўзгодненасці сістэмы

sudo dnf check
sudo dnf distro-sync

Гэта дапамагае зразумець, ці адпавядае сістэма ўзгодненаму стану пакетаў дыстрыбутыва.

Прагляд гісторыі

sudo dnf history
sudo dnf history info last

Гісторыя часта дазваляе хутка ўбачыць, пасля якога абнаўлення пачаліся праблемы.

Што важна праверыць, калі не працуе pacman

У Arch Linux асабліва важна правяраць базы сінхранізацыі, ключы, люстэркі і факт частковых абнаўленняў.

Паўторная сінхранізацыя баз

sudo pacman -Syy

Калі лакальная база сінхранізацыі больш не супадае з repository, гэта звычайна першы крок.

Поўнае абнаўленне

sudo pacman -Syu

У Arch варта пазбягаць частковых абнаўленняў. Абнаўленне толькі часткі пакетаў пры старых астатніх — адзін з найбольш тыповых шляхоў да неўзгодненага стану.

Праверка праблем з ключамі

sudo pacman-key --init
sudo pacman-key --populate

Калі праблема ў подпісах або keyring, можа спатрэбіцца паўторная ініцыялізацыя.

Логі вельмі важныя

Пры праблемах з менеджарам пакетаў адной апошняй радкі недастаткова. Толькі логі і падрабязны вывад паказваюць, ці гэта праблема подпісу, залежнасцей, сеткі або базы.

apt / dpkg

sudo tail -n 100 /var/log/apt/history.log
sudo tail -n 100 /var/log/dpkg.log

dnf

sudo dnf history
sudo journalctl -xe --no-pager | tail -n 100

pacman

sudo tail -n 100 /var/log/pacman.log

Практычны парадак праверкі

Крок 1: Праверыць сетку і DNS

ping -c 4 8.8.8.8
ping -c 4 google.com

Крок 2: Праверыць вольнае месца

df -h

Крок 3: Праверыць працэсы і lock-файлы

ps aux | grep -E 'apt|dpkg|dnf|yum|pacman'

Крок 4: Прачытайце логі

Спачатку трэба высветліць, якая апошняя канкрэтная аперацыя насамрэч завяршылася збоям.

Крок 5: Выкарыстаць правільныя каманды аднаўлення для свайго дыстрыбутыва

Для apt звычайна пачынаюць з dpkg --configure -a, для dnf — з ачысткі metadata, а для pacman — з поўнай сінхранізацыі і праверкі ключоў.

Чаго не варта рабіць

• Выдаляць lock-файлы, не разумеючы прычыны
• Усталёўваць выпадковыя .deb / .rpm / іншыя пакеты з ненадзейных крыніц
• Пастаянна рабіць частковыя абнаўленні ў Arch
• Бязладна змешваць apt з dpkg, dnf з rpm або pacman з ручнымі заменамі файлаў
• Выключаць праверку подпісаў, не разумеючы саму памылку

Як пазбегнуць паўтарэння праблемы

• Не дапускаць адключэння электрычнасці і прымусовых спыненняў падчас абнаўлення
• Не дадаваць занадта шмат старонніх repository
• Рабіць snapshot або backup перад вялікімі абнаўленнямі
• Прытрымлівацца рэкамендаванага спосабу абнаўлення для свайго дыстрыбутыва
• Асабліва ў Arch пазбягаць частковых абнаўленняў

Выснова

Нават калі здаецца, што зламаліся менавіта apt, dnf або pacman, сапраўдная прычына часта знаходзіцца ў сетцы, lock-файлах, подпісах, залежнасцях, cache, вольным месцы або канфігурацыі repository. Галоўнае — не спяшацца ўсё выдаляць або пераўсталёўваць, а спачатку з дапамогай логаў зразумець, на якім узроўні ўзнік збой. І толькі пасля гэтага выкарыстоўваць адпаведны метад: рамонт dpkg у сістэмах apt, праца з metadata і гісторыяй у dnf, а таксама поўная сінхранізацыя і праверка ключоў у pacman.