Linux: apt / dnf / pacman са повредени — причини и решения

В Linux apt, dnf и pacman са в основата на инсталирането и обновяването на софтуер. Когато изглеждат „счупени“, проблемът не е само в това, че не могат да се инсталират нови програми. Често спират и обновленията по сигурността, а поддръжката на системата става много по-трудна. Най-честите причини са прекъснати обновления, проблемни mirror-и, несъгласувана пакетна база, грешки в подписите, счупени зависимости или останали lock файлове. Най-важното е човек да не започва веднага да трие cache и конфигурации на сляпо, а първо да разбере коя част всъщност е повредена.

Понякога изглежда, че самият пакетен мениджър е развален, докато реалната причина е в мрежата, DNS, настройките на repository или липсата на свободно дисково пространство. Затова диагностиката трябва да започне с разграничаване дали проблемът е в комуникацията, repository, локалната база или зависимостите.

Чести симптоми

• apt update, dnf update или pacman -Syu спират с грешка
• Появяват се съобщения за неразрешими зависимости или повредени пакети
• Repository не могат да се използват заради GPG или signature грешки
• Базата е заключена и не могат да се изпълняват пакетни операции
• Mirror-ите връщат 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, невалидни mirrors или остатъци след upgrade на дистрибуцията могат да направят пакетните източници невалидни. Типичните симптоми са 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, signature или Release file грешки, трябва да се проверят /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

Ако информацията за mirror-и или metadata е повредена, това често е полезна първа стъпка.

Проверка на зависимости и консистентност на системата

sudo dnf check
sudo dnf distro-sync

Това помага да се установи дали системата все още съответства на очакваното състояние на дистрибуцията.

Преглед на историята

sudo dnf history
sudo dnf history info last

Историята често показва след кое обновление са започнали проблемите.

Какво да се провери, когато pacman не работи

При Arch Linux особено важно е да се проверят синхронизационните бази, ключовете, mirror-ите и наличието на частични обновления.

Повторна синхронизация на базите

sudo pacman -Syy

Ако локалната синхронизационна база не съвпада с repository, това обикновено е първата стъпка.

Пълно обновление

sudo pacman -Syu

При Arch частичните обновления трябва да се избягват. Обновяване само на част от пакетите и оставяне на останалите стари е класически начин за въвеждане на несъответствия.

Проверка на проблеми с ключове

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

Ако проблемът е в signatures или 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.