Подробный гайд по ремонту APT-системы после сломанных зависимостей Часть 2
Начало в Части 1
20. Если сломаны зависимости из-за ручной установки .deb
Ручная установка .deb-пакетов через dpkg -i часто приводит к проблемам, если зависимости не были установлены автоматически или пакет рассчитан на другую версию дистрибутива.
Типичные симптомы:
dpkg: dependency problems prevent configuration of package-name
или:
package-name depends on some-package; however:
Package some-package is not installed.
20.1. Найти вручную установленный пакет
Посмотрите историю команд:
grep "dpkg -i" ~/.bash_history
Или историю root:
grep "dpkg -i" /root/.bash_history
Также полезно проверить логи:
less /var/log/dpkg.log
less /var/log/apt/history.log
20.2. Проверить состояние пакета
dpkg -s package-name
Если пакет в состоянии half-configured или unpacked, попробуйте сначала завершить настройку:
dpkg --configure -a
20.3. Попробовать автоматически доставить зависимости
apt --fix-broken install
Если APT знает, какие зависимости нужны, он попробует их установить.
20.4. Удалить проблемный пакет
Если пакет не нужен или его можно установить позже корректно:
dpkg --remove package-name
Если не удаляется из-за состояния:
dpkg --remove --force-remove-reinstreq package-name
Или, если мешают зависимости:
dpkg --purge --force-depends package-name
После этого обязательно выполните:
apt --fix-broken install
dpkg --configure -a
20.5. Установить .deb правильно
Если нужно установить локальный .deb, лучше использовать APT, а не чистый dpkg:
apt-get install ./package.deb
Эта команда постарается автоматически установить зависимости из репозиториев.
21. Если после ремонта не работает сеть
Если APT восстановлен, но нет сети, дальнейший ремонт может быть невозможен без ручного переноса пакетов.
21.1. Проверить сетевые интерфейсы
ip a
Если интерфейс есть, но нет адреса, попробуйте получить его по DHCP:
dhclient -v eth0
Замените eth0 на имя вашего интерфейса, например enp3s0.
21.2. Проверить маршруты
ip route
Должен быть маршрут по умолчанию, например:
default via 192.168.1.1 dev eth0
Если его нет:
ip route add default via 192.168.1.1
21.3. Проверить DNS
cat /etc/resolv.conf
Если файл пустой или неверный, временно укажите публичный DNS:
echo nameserver 1.1.1.1 > /etc/resolv.conf
или:
echo nameserver 8.8.8.8 > /etc/resolv.conf
Проверить разрешение имён:
getent hosts deb.debian.org
21.4. Проверить доступность репозитория
ping -c 3 deb.debian.org
curl -I http://deb.debian.org/debian
Для Ubuntu:
curl -I http://archive.ubuntu.com/ubuntu
21.5. Проверить и закомментируйте прокси-настройки APT. В России он вам не нужен.
Если раньше использовался, посмотрите и закомментируйте :
cat /etc/apt/apt.conf
ls /etc/apt/apt.conf.d/
grep -r Proxy /etc/apt/apt.conf.d/
Если прокси не нужен, удалите или закомментируйте соответствующие строки.
21.6. Если сломаны сертификаты
Ошибка может выглядеть так:
certificate verification failed
или:
The following signatures couldn't be verified
Если проблема именно в ca-certificates, попробуйте установить пакет из кэша или скачать его вручную на другой машине:
apt-get install --reinstall ca-certificates
Если APT не может скачать пакет, используйте ручной перенос .deb.
22. Если нет интернета
Если сломанная машина не имеет доступа в сеть, можно восстановить пакеты с другого компьютера.
22.1. Скачать пакет на рабочей системе
На рабочей машине с той же версией дистрибутива:
apt-get download package-name
Например:
apt-get download apt
Затем перенести файл .deb на флешке или по локальной сети.
22.2. Скачать пакет вместе с зависимостями
Простой вариант:
apt-get download package-name dependency1 dependency2
Более продвинутый вариант — рекурсивно получить список зависимостей:
apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances package-name | grep '^\w' | sort -u > deps.txt
Затем:
xargs -a deps.txt apt-get download
После этого все .deb-файлы нужно перенести на сломанную систему.
22.3. Установить локальные .deb
В каталоге с пакетами:
apt-get install ./*.deb
Если APT не может работать, используйте:
dpkg -i *.deb
Но второй вариант хуже, потому что не решает зависимости автоматически.
22.4. Создать локальный репозиторий на флешке
Это удобно, если пакетов много.
На флешке или внешнем диске создайте каталог:
mkdir /media/usb/packages
Скопируйте туда .deb-файлы.
Затем создайте индекс:
cd /media/usb/packages
dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
Добавьте локальный репозиторий:
echo "deb [trusted=yes] file:/media/usb/packages ./" > /etc/apt/sources.list.d/local.list
Обновите APT:
apt-get update
Теперь можно ставить пакеты:
apt-get install package-name
22.5. Использовать apt-offline
Если на сломанной машине установлен apt-offline, можно сформировать список нужных файлов:
apt-offline set /root/apt-offline.sig
Перенести файл apt-offline.sig на рабочую машину и выполнить:
apt-offline get apt-offline.sig --bundle /root/apt-offline.zip
Затем вернуть архив на сломанную машину и установить:
apt-offline install /root/apt-offline.zip
После этого:
apt-get update
apt-get upgrade
23. Проверка целостности системы после ремонта
После восстановления нужно убедиться, что система снова согласована.
23.1. Проверка зависимостей
apt-get check
Если вывод пустой или не содержит ошибок — хорошо.
23.2. Проверка проблемных пакетов
dpkg --audit
В норме вывод должен быть пустым.
23.3. Проверка пакетов не в состоянии ii
dpkg -l | grep -v '^ii'
Если вывод содержит пакеты в состояниях iU, iF, rc, iH, нужно разобрать каждый из них.
23.4. Обновление системы
apt-get update
apt-get upgrade
Если нужно полное обновление:
apt full-upgrade
23.5. Удаление ненужных пакетов
apt-get autoremove --purge
Перед подтверждением обязательно прочитайте список пакетов, которые будут удалены.
23.6. Проверка файлов пакетов
Можно установить debsums и проверить контрольные суммы файлов:
apt-get install debsums
Проверка:
debsums --silent
Если вывод пустой, файлы пакетов не изменены.
Проверка только конфигурационных файлов:
debsums --config-silent
23.7. Проверка журналов
Посмотрите последние операции:
tail -n 100 /var/log/apt/history.log
tail -n 100 /var/log/dpkg.log
Если там нет ошибок — ремонт завершён успешно.
24. Практический алгоритм восстановления
Короткая последовательность для большинства случаев:
apt-get update
dpkg --configure -a
apt --fix-broken install
apt-get upgrade
apt-get check
Если проблема не решена:
dpkg --audit
dpkg -l | grep -v '^ii'
apt-cache policy package-name
Если виноват конкретный пакет:
apt-get install --reinstall package-name
или:
dpkg --remove package-name
apt --fix-broken install
Если проблема в PPA:
mkdir /etc/apt/sources.list.d.disabled
mv /etc/apt/sources.list.d/* /etc/apt/sources.list.d.disabled/
apt-get update
apt --fix-broken install
Если система не загружается:
chroot /mnt
dpkg --configure -a
apt --fix-broken install
25. Пример разбора реальной поломки
Допустим, после попытки установить пакет из стороннего PPA появляется ошибка:
The following packages have unmet dependencies:
libgtk-3-0 : Depends: libgtk-3-common but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
Шаг 1. Посмотреть версии пакетов
apt-cache policy libgtk-3-0 libgtk-3-common
Если видно, что один пакет установлен из PPA, а другой доступен только из официального репозитория, причина в конфликте версий.
Шаг 2. Отключить PPA
mkdir /etc/apt/sources.list.d.disabled
mv /etc/apt/sources.list.d/* /etc/apt/sources.list.d.disabled/
Обновить списки:
apt-get update
Шаг 3. Попробовать исправить зависимости
apt --fix-broken install
Если APT предлагает удалить слишком много, используйте симуляцию:
apt-get -s --fix-broken install
Шаг 4. Установить официальную версию пакета
Сначала узнайте доступную версию:
apt-cache policy libgtk-3-0
Затем установите её:
apt-get install libgtk-3-0=версия libgtk-3-common=версия
Пример:
apt-get install libgtk-3-0=3.24.33-3ubuntu3 libgtk-3-common=3.24.33-3ubuntu3
Шаг 5. Завершить ремонт
dpkg --configure -a
apt-get check
Если вывод пустой, система восстановлена.
26. Профилактика
Чтобы не ломать APT в будущем, соблюдайте несколько правил.
26.1. Не смешивайте репозитории разных выпусков
Не добавляйте в стабильную систему репозитории testing, sid, unstable без понимания последствий.
Для Debian не стоит просто так подключать:
testing
sid
unstable
Для Ubuntu не стоит смешивать разные релизы:
jammy
noble
proposed
26.2. Используйте pinning
Если нужно подключить testing только для некоторых пакетов, создайте файл приоритетов.
Например:
nano /etc/apt/preferences.d/testing
Содержимое:
Package: *
Pin: release a=stable
Pin-Priority: 900
Package: *
Pin: release a=testing
Pin-Priority: 100
Это не позволит пакетам из testing автоматически вытеснить стабильные версии.
26.3. Делайте резервные копии перед крупными обновлениями
Перед full-upgrade, сменой релиза или установкой драйверов сделайте:
- snapshot Timeshift;
- Btrfs snapshot;
- LVM snapshot;
- резервную копию /etc, /var/lib/dpkg, /var/lib/apt.
Пример архива:
tar czf /root/apt-dpkg-backup-$(date +%F).tar.gz /etc/apt /var/lib/apt /var/lib/dpkg
26.4. Не устанавливайте системные пакеты через pip
Для Python-библиотек лучше использовать виртуальные окружения:
python3 -m venv ~/venv
source ~/venv/bin/activate
pip install package
Не используйте pip install для замены системных модулей, если не понимаете последствия.
26.5. Читайте список удаления
Перед подтверждением Y проверяйте, не удаляются ли:
apt
dpkg
bash
coreutils
libc6
systemd
init
util-linux
Если такие пакеты есть в списке на удаление — остановитесь.
26.6. Используйте симуляцию перед опасными командами
apt-get -s full-upgrade
apt-get -s --fix-broken install
apt-get -s install package-name
Это позволяет увидеть, что произойдёт, без реального изменения системы.
27. Минимальная шпаргалка
Диагностика
apt-get check
dpkg --audit
apt-mark showhold
dpkg -l | grep -v '^ii'
apt-cache policy package-name
Обновление и восстановление
apt-get update
dpkg --configure -a
apt --fix-broken install
apt-get upgrade
apt full-upgrade
Переустановка пакета
apt-get install --reinstall package-name
Установка локального .deb
apt-get install ./package.deb
Принудительное удаление проблемного пакета
dpkg --remove --force-remove-reinstreq package-name
Очистка кэша
apt-get clean
apt-get autoclean
Удаление остатков конфигураций
dpkg -l | grep '^rc'
apt-get purge package-name
Проверка после ремонта
apt-get check
dpkg --audit
dpkg -l | grep -v '^ii'
28. Когда лучше переустановить систему
Ремонт APT имеет смысл, если: - сломано несколько пакетов; - причина понятна; - есть резервная копия; - система серверная или важна её конфигурация; - нужно сохранить установленное окружение; - восстановление занимает меньше времени, чем переустановка.
Переустановка может быть быстрее и надёжнее, если:
- одновременно сломаны dpkg, apt, libc6;
- удалены критические системные пакеты;
- система собрана из пакетов разных релизов;
- нет понимания, какие пакеты установлены;
- нет резервной копии;
- система нестабильна после восстановления;
- восстановление уже заняло слишком много времени.
В таком случае безопаснее:
1. Загрузиться с Live USB.
2. Смонтировать диск.
3. Скопировать /home, /etc, важные данные.
4. Переустановить систему.
5. Восстановить пользовательские файлы и настройки.
Итог
Базовая цепочка ремонта APT почти всегда такая:
apt-get update
dpkg --configure -a
apt --fix-broken install
apt-get upgrade
apt-get check
Если это не помогает, нужно:
- Найти конкретный проблемный пакет:
dpkg --audit
dpkg -l | grep -v '^ii'
apt-cache policy package-name
- Переустановить или удалить виновника:
apt-get install --reinstall package-name
или:
dpkg --remove package-name
- Если проблема в PPA или стороннем репозитории — отключить его.
- Если система не загружается — восстановить через Live USB и
chroot. - Если APT предлагает удалить критические пакеты — не соглашаться сразу, а использовать
aptitude, симуляцию-sи точечную установку нужных версий.
Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.