Debian 13: APT ламається («незадоволені залежності») — виправте це без перевстановлення

Що насправді означає «незадоволені залежності» (і чого це не означає)

APT не «зламався» просто через те, що вивів помилку. Він не може знайти узгоджений набір версій пакунків, які задовольняють:

• Чого ви попросили (встановити/оновити/видалити),
• Що вже встановлено,
• Що пропонують ваші репозиторії,
• І що ваша політика дозволяє (pin’и, пріоритети, «утримувані» пакунки).

На практиці «незадоволені залежності» зазвичай зводяться до одного з наведених:

1. Змішані репозиторії: у вас одночасно Debian stable + testing + unstable або сторонній репозиторій для іншого випуску. APT — не терапевт; він не може примирити суперечливі вимоги.
2. Часткове оновлення: деякі пакунки перейшли на новіші версії, але їх ланцюжки залежностей — ні, часто через перервані оновлення, утримання або зміну доступності репозиторіїв.
3. Неконсистентний стан dpkg: пакунки залишилися неконфігурованими, напіввстановленими або пошкоджені diversions. APT делегує фактичне розпакування та конфігурацію dpkg; якщо dpkg заблокований, APT безсилий.
4. Утримання пакунків: базова бібліотека утримується, тож усе, що від неї залежить, не може оновитися.
5. Pin’инг (preferences) змусив систему «вибрати» версію, якої немає у ввімкнених зараз репозиторіях.
6. Архітектурні й multiarch невідповідності: випадкове змішування i386/amd64 або залишкові пакунки іноземної архітектури.

Чого це не є: приводом перевстановлювати систему, приводом починати видаляти випадкові пакунки або запрошенням натискати apt --fix-broken install до нескінченності. Ми скористаємося цим інструментом, але лише коли зрозуміємо, що саме він зробить.

Швидкий план діагностики (перший/другий/третій)

Якщо це продакшн-система, треба швидко отримати сигнал. Ось порядок тріажу, який працює, бо відокремлює «APT не може обчислити рішення» від «dpkg не може застосувати рішення».

Перший крок: підтвердьте режим відмови

• Чи може APT обчислити план, але dpkg не вдається його застосувати? (блокування dpkg, перерване налаштування, зламані maintainer-скрипти)
• Або APT взагалі не може обчислити план? (змішані репозиторії, pin’и, утримання, відсутні версії)

Другий крок: перевірте репозиторії й вирівнювання релізів

• Переконайтесь, що ви справді на Debian 13 і джерела орієнтовані на Debian 13 (або його кодову назву) послідовно.
• Шукайте сторонні репозиторії, які вказують на невірний дистрибутив.
• Перевіряйте, чи випадково не ввімкнено testing/unstable.

Третій крок: ідентифікуйте, що блокує граф залежностей

• Утримувані пакунки.
• Pin’и / preferences (включно з pin’ами за «origin» від сторонніх репозиторіїв).
• Один «ключовий» пакунок (часто libc6, libstdc++, openssl, systemd), що застряг у несумісній версії.

Четвертий крок: виправте стан dpkg, якщо потрібно

• Сконфігуруйте розпаковані пакунки.
• Виправте зламані maintainer-скрипти.
• Обережно очистіть блокування (трапляється рідко, але іноді необхідно).

П’ятий крок: застосуйте контрольоване повне оновлення

• Коли репозиторії й політика в порядку, зробіть full-upgrade (або сучасний еквівалент), щоб APT міг виконати необхідні видалення/встановлення.
• Переглядайте пропоновані видалення, наче ви підписуєте дозвіл на закупівлю.

Цікаві факти й контекст (те, що має значення о 2-й ночі)

1. APT старіший за більшість інструментів для хмари. Проект APT існує з кінця 1990-х; його дизайн враховував ненадійні мережі та повільні дзеркала, тож він вимогливий до консистентності й метаданих.
2. dpkg старший за APT. dpkg виконує фактичне встановлення/розпакування/конфігурацію; APT — планувальник і завантажувач. Якщо dpkg застряг, APT може лише ввічливо поскаржитися.
3. «Depends» — це не вся історія. Debian-пакунки також використовують Pre-Depends, що примушує порядок встановлення і може «заблокувати» систему, якщо базовий пакунок не може перейти.
4. «Stable» — це обіцянка, а не чарівна властивість. Debian stable прагне сумісності, але якщо ви міксуєте релізи (stable/testing/unstable), ви втрачаєте цю обіцянку.
5. Pin’и — це одночасно скальпель і бензопила. Preferences APT дозволяють контролювати змішування (наприклад, backports), але один неправильний pin може заморозити півсистеми.
6. Сторонні репозиторії часто орієнтуються на Ubuntu перш за все. Багато вендорів публікують пакунки для Debian, але їх очікування щодо залежностей часто ближчі до Ubuntu, і саме так виникають повідомлення «Depends: libsslX (>= …) але його неможливо встановити.»
7. Файли Release — це межа довіри. APT використовує підписані метадані репозиторію. Коли підписи ламаються (прострочений ключ, неправильний suite), APT відмовиться оновлювати — що опосередковано може спричинити незадоволені залежності при оновленнях.
8. Multiarch з’явився не одразу. Змішування архітектур стало масовим пізніше; залишкові i386-пакунки на amd64 можуть створювати обмеження залежностей, що виглядають не пов’язаними.
9. «Kept back» зазвичай означає, що APT обережний. APT за замовчуванням уникає видалень; оновлення може вимагати переходів пакунків, які приймає лише full-upgrade.

Перед тим як щось чіпати: запобіжні заходи

Якщо це ноутбук, ваш «радіус ураження» — здебільшого ваш власний вечір. Якщо це сервер, ви хочете оборотних дій.

• Запустіть root-shell з логом. Потрібен транскрипт, щоб пізніше пояснити, що змінювалося.
• Зробіть snapshot, якщо можете. LVM-снапшот, ZFS-снапшот або сніпшот VM. Якщо їх немає, хоча б зробіть резервні копії /etc/apt та /var/lib/dpkg.
• Не видаляйте критичні пакунки без роздуму. Якщо APT пропонує видалити systemd, ssh, libc6 або ваш метапакет ядра, зупиніться і з’ясуйте причину.

Одна холодна істина з операцій: «швидкі» виправлення, які ви не можете пояснити — це просто інцидент, доставлений завчасно.

Парафраз ідеї від Richard Cook (resilience engineering): «Успіх і невдача часто походять з однієї щоденної роботи; це не різні світи.»

Практичні завдання для відновлення (команди, виводи, рішення)

Нижче — конкретні завдання. Кожне містить: команду, реалістичний вивід, що це означає, і яке рішення ухвалювати далі. Виконуйте їх у порядку, якщо ви не знаєте точного режиму відмови.

Завдання 1: Підтвердьте реліз ОС і кодову назву

cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Значення: Ви на Debian 13, кодова назва trixie. Репозиторії мають відповідати Debian 13 (зазвичай trixie, trixie-updates, trixie-security).

Рішення: Якщо ваші джерела вказують іншу кодову назву (наприклад, bookworm, sid або імена Ubuntu), спочатку виправте sources. Не намагайтесь «примусово встановити» пакунки.

Завдання 2: Перелічіть джерела APT, включно з deb822 і старими файлами

cr0x@server:~$ find /etc/apt/sources.list /etc/apt/sources.list.d -maxdepth 1 -type f -print -exec sed -n '1,160p' {} \;
/etc/apt/sources.list
deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
/etc/apt/sources.list.d/vendor.list
deb http://packages.vendor.example/debian bookworm main

Значення: У вас є сторонній репозиторій, орієнтований на bookworm (Debian 12) у системі Debian 13. Це типова причина незадоволених залежностей або спроб пониження версій.

Рішення: Вимкніть або виправте цей репозиторій перед будь-якими іншими діями. Якщо вендор не підтримує Debian 13, вам доведеться замінити програмне забезпечення або погодитися на небезпечні маніпуляції з залежностями.

Завдання 3: Оновіть списки пакунків і читайте помилки як доказ

cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://deb.debian.org/debian trixie-updates InRelease
Hit:3 http://security.debian.org/debian-security trixie-security InRelease
Get:4 http://packages.vendor.example/debian bookworm InRelease [3,215 B]
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

Значення: APT успішно отримав метадані як для Debian 13, так і для вендорського репозиторію Debian 12. «All packages are up to date» означає лише, що метадані свіжі, а не що система консистентна.

Рішення: Продовжуйте інспекцію політики. Не оновлюйте поки не вирівняли політику.

Завдання 4: Перевірте, з яких suite APT вважає можливим встановлення (огляд політики)

cr0x@server:~$ apt-cache policy | sed -n '1,80p'
Package files:
 100 /var/lib/dpkg/status
     release a=now
 500 http://packages.vendor.example/debian bookworm InRelease
     release o=Vendor,a=bookworm,n=bookworm,l=Vendor,c=main,b=amd64
 500 http://security.debian.org/debian-security trixie-security InRelease
     release o=Debian,a=trixie-security,n=trixie-security,l=Debian,c=main,b=amd64
 500 http://deb.debian.org/debian trixie-updates InRelease
     release o=Debian,a=trixie-updates,n=trixie-updates,l=Debian,c=main,b=amd64
 500 http://deb.debian.org/debian trixie InRelease
     release o=Debian,a=trixie,n=trixie,l=Debian,c=main,b=amd64

Значення: Вендорський репозиторій має ту саму пріоритетність (500), що й Debian. Це означає, що APT може обирати пакунки від вендора, якщо їх версії виглядають «привабливішими», підтягувавши залежності, відсутні в Debian 13.

Рішення: Якщо вендорський репозиторій не відповідає релізу, вимкніть його; якщо він коректний, але занадто «привабливий», зменшіть його пріоритет або зафіксуйте лише для окремих пакунків.

Завдання 5: З’ясуйте точний конфлікт залежностей

cr0x@server:~$ sudo apt install vendor-agent
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 vendor-agent : Depends: libssl3 (>= 3.0.0) but it is not installable
               Depends: libc6 (>= 2.37) but 2.36-9 is to be installed
E: Unable to correct problems, you have held broken packages.

Значення: Пакунок вимагає libc6 новішої версії, ніж та, яку APT готовий встановити, і вважає, що libssl3 не встановлюваний за поточної конфігурації репозиторіїв/пінів.

Рішення: Не намагайтесь примусово інсталювати. Дізнайтесь, який репозиторій пропонує версії libc6 і libssl3, і чи блокує вас утримання/pin або часткове оновлення.

Завдання 6: Перевірте наявність утримуваних пакунків (класична пастка)

cr0x@server:~$ apt-mark showhold
libc6
linux-image-amd64

Значення: Наявність libc6 у списку утримуваних — велика справа. Утримання libc6 може заморозити усе, бо багато пакунків прямо або опосередковано від нього залежать.

Рішення: Якщо утримання встановлене навмисно для вікна змін, заплануйте вікно і зніміть утримання. Якщо воно випадкове (або успадковане від золотого образу), зніміть його зараз.

Завдання 7: Зніміть утримання пакунків (тільки після розуміння причин)

cr0x@server:~$ sudo apt-mark unhold libc6 linux-image-amd64
Canceled hold on libc6.
Canceled hold on linux-image-amd64.

Значення: APT тепер може оновити ці пакунки.

Рішення: Перерахувати обчислення залежностей. Якщо це був єдиний блокатор, повідомлення про «незадоволені залежності» може зникнути.

Завдання 8: Шукайте pin’и й preferences, що змушують дивні вибори

cr0x@server:~$ grep -R --line-number --no-messages '' /etc/apt/preferences /etc/apt/preferences.d 2>/dev/null
/etc/apt/preferences.d/00-local-pin:1:Package: *
/etc/apt/preferences.d/00-local-pin:2:Pin: release a=bookworm
/etc/apt/preferences.d/00-local-pin:3:Pin-Priority: 990

Значення: Хтось зафіксував всю систему під bookworm. На Debian 13 це практично наказувати APT віддавати перевагу пакетам з Debian 12. Ось як утворюється FrankenDebian.

Рішення: Видаліть або відкоригуйте pin. Якщо потрібно пінити, пінте тільки конкретні пакунки, а не Package: *.

Жарт #1: Пінити Package: * — це як відремонтувати скрипучі двері, посунувши цілий будинок на два дюйми вліво.

Завдання 9: Перевірте кандидатські версії для конфліктних пакунків

cr0x@server:~$ apt-cache policy libc6 libssl3 vendor-agent
libc6:
  Installed: 2.36-9
  Candidate: 2.39-5
  Version table:
     2.39-5 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages
 *** 2.36-9 100
        100 /var/lib/dpkg/status
libssl3:
  Installed: (none)
  Candidate: 3.3.1-1
  Version table:
     3.3.1-1 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages
vendor-agent:
  Installed: (none)
  Candidate: 1.8.2-4
  Version table:
     1.8.2-4 500
        500 http://packages.vendor.example/debian bookworm/main amd64 Packages

Значення: Debian 13 пропонує новіші libc6 і libssl3. Вендорський агент походить з репозиторію Debian 12, але його залежності можуть бути задоволені, якщо APT не зафіксовано на старих версіях.

Рішення: Виправте suite в вендорському репозиторії (або вимкніть його). Потім виконайте контрольоване повне оновлення, щоб libc6 перейшов коректно.

Завдання 10: Тимчасово вимкніть невідповідний сторонній репозиторій

cr0x@server:~$ sudo mv /etc/apt/sources.list.d/vendor.list /etc/apt/sources.list.d/vendor.list.disabled
cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://deb.debian.org/debian trixie-updates InRelease
Hit:3 http://security.debian.org/debian-security trixie-security InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done

Значення: Ви прибрали невідповідний набір пакунків із розгляду. Часто це саме по собі усуває помилки «неможливо вирішити ситуацію».

Рішення: Тепер вирівняйте встановлені пакунки з Debian 13, виконавши повне оновлення. Пізніше знову ввімкніть вендорський репозиторій тільки якщо він має suite для Debian 13.

Завдання 11: Перевірте dpkg на напівсконфігуровані/напіввстановлені пакунки

cr0x@server:~$ dpkg -C
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 systemd 252.22-1  system and service manager

Значення: dpkg повідомляє про неконсистентний стан. Навіть якщо APT може обчислити план, він може зазнати невдачі, поки dpkg не завершить конфігурацію.

Рішення: Виправте стан dpkg до масштабніших оновлень.

Завдання 12: Сконфігуруйте очікувані пакунки

cr0x@server:~$ sudo dpkg --configure -a
Setting up systemd (252.22-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/cron.service → /lib/systemd/system/cron.service.
Processing triggers for dbus (1.14.10-1) ...
Processing triggers for libc-bin (2.36-9) ...

Значення: dpkg завершив очікувану конфігурацію й виконав тригери. Це фундаментальний крок.

Рішення: Заново запустіть планування оновлення. Якщо dpkg видає помилку, зупиніться й виправте конкретну помилку (зазвичай зламаний maintainer-скрипт або відсутній файл).

Завдання 13: Дозвольте APT виправити відсутні залежності (пильнуйте зміни)

cr0x@server:~$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  libpam-systemd systemd-sysv
The following packages will be upgraded:
  libpam-systemd systemd-sysv
2 upgraded, 0 newly installed, 0 to remove and 17 not upgraded.
Need to get 1,214 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
...

Значення: APT знайшов мінімальний набір оновлень для відновлення консистентності. Зверніть увагу, що воно не пропонує видалень — хороший знак.

Рішення: Погодьтеся, якщо зміни розумні. Якщо пропонуються видалення ключових служб, зупиніться й перегляньте вирівнювання репозиторіїв і pin’и.

Завдання 14: Виконайте повне оновлення, щоб дозволити переходи

cr0x@server:~$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  base-files libc6 libc-bin libssl3 openssh-client openssh-server
The following packages will be installed:
  linux-image-6.12.0-1-amd64 linux-headers-6.12.0-1-amd64
The following packages will be removed:
  linux-image-6.1.0-18-amd64
8 upgraded, 2 newly installed, 1 to remove and 0 not upgraded.
Need to get 76.4 MB of archives.
After this operation, 312 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
...

Значення: Це нормальний перехід ядра: встановлення нового ядра й видалення старого. Оновлення libc6 та libssl3 узгоджені з Debian 13.

Рішення: Продовжуйте. Якщо ви працюєте віддалено, переконайтесь, що не втратите SSH: тримайте активну сесію, розгляньте відкриття другої сесії й не перебивайте мережу під час оновлення.

Завдання 15: Якщо APT досі не може вирішити, попросіть його пояснити чому

cr0x@server:~$ apt -o Debug::pkgProblemResolver=yes install vendor-agent
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Starting pkgProblemResolver with broken count: 0
Investigating (0) vendor-agent:amd64 < none -> 1.8.2-4 @un puN Ib >
Broken vendor-agent:amd64 Depends on libc6:amd64 >= 2.37
  Considering libc6:amd64 100 as a solution to vendor-agent:amd64 9999
  Rejected libc6:amd64 100 because of held packages or policy
E: Unable to correct problems, you have held broken packages.

Значення: Налагоджувальний вивід показує відхилення через «policy» (pin’и/preferences) або утримання. Тепер ви знаєте, куди дивитись: apt-mark showhold та файли /etc/apt/preferences*.

Рішення: Приберіть політичне обмеження й спробуйте знову. Не встановлюйте навмання старі версії, щоб задовольнити резольвер.

Завдання 16: Проінспектуйте ланцюжок залежностей для конкретного пакунка

cr0x@server:~$ apt-cache depends vendor-agent | sed -n '1,80p'
vendor-agent
  Depends: libc6
  Depends: libssl3
  Depends: systemd
  Depends: adduser
  Depends: ca-certificates

Значення: Нічого екзотичного; це типовий агент, що покладається на базові бібліотеки й systemd.

Рішення: Якщо базові бібліотеки заблоковані, виправте їх першими. Не вважайте агент проблемою сам по собі — він лише посланець.

Завдання 17: Очистіть застарілі пакунки й кеші (після відновлення)

cr0x@server:~$ sudo apt autoremove --purge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  linux-image-6.1.0-18-amd64*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 287 MB disk space will be freed.
Do you want to continue? [Y/n] y
...

Значення: Ви чистите старі ядра або сирітські залежності. Це не вирішує конфліктів залежностей; це зменшує «сміття» після їх усунення.

Рішення: Безпечно виконувати після того, як ви впевнились у завантажуваності нового ядра. На серверах зберігайте принаймні одне відоме робоче старе ядро до перезавантаження.

Завдання 18: Перевірте стан системи після оновлення

cr0x@server:~$ sudo systemctl is-system-running
running

Значення: systemd вважає систему здоровою. Якщо повертає degraded, перегляньте невдалі юніти.

Рішення: Якщо degraded, запустіть systemctl --failed, виправте проблемні служби, а потім перезавантажте систему у зручний час (оновлення ядра/libc зазвичай вимагають перезавантаження).

Жарт #2: «Незадоволені залежності» — це спосіб APT сказати: «Я можу все… окрім погодитися з твоїм минулим «я».»

Три короткі історії з корпоративного світу (чому так трапляється у дорослих середовищах)

Інцидент №1: Хибне припущення («Це ж лише одна рядок репозиторію»)

У них був флот серверів Debian, зібраних із золотого образу, який жив роками. Образ був «переважно стабільний», що корпоративною мовою означає: ніхто не хотів бути тим, хто торкається. Потрібен був новий агент для аудиту, і вендор дав уривок репозиторію. Хтось додав його, запустив apt update і встановив агент. На одній машині все запрацювало.

Через два тижні автоматична задача безпеки запустила apt upgrade по флоту. APT почав підтягувати нову бібліотеку з вендорського репозиторію на деяких хостах — тільки там, де був встановлений певний опційний пакунок. Ті машини отримали часткове оновлення: кілька бібліотек оновилися, але базові пакунки залишилися завдяки утриманням, введеним роки тому, щоб зафіксувати ядра під час проблем з драйверами.

Симптом був типовий: «Depends: libc6 (>= …) але … буде встановлено». SSH ще працював, але агент не встановився на половині флоту, і звіт відповідності позначив відсутню телеметрію. Так незадоволені залежності перетворюються на бізнес-проблему.

Хибне припущення: що один рядок вендорського репозиторію «локальний» для пакетів вендора. Ні. Репозиторії не мають областей видимості. Як тільки ви додаєте репозиторій, ви додаєте цілий універсум пакетів, які APT може розглядати для оновлень, якщо ви не задали pin.

Виправлення було нудним і правильним: вимкнути вендорський репозиторій за замовчуванням, потім додати pin, який дозволяв лише пакетам агента (і їх точним залежностям) приходити з того джерела. Решта лишилася чистим Debian. Також після запланованого вікна вони зняли утримання libc. Інцидент вирішили політикою і чеклістом, а не героїкою.

Інцидент №2: Оптимізація, що зіграла проти («Зробім локальний mirror, щоб кешувати пакети»)

Інша компанія вирішила «оптимізувати». Вони зробили локальний APT-проксі, щоб зменшити трафік і пришвидшити розгортання. Гарна ідея. Але потім вони «оптимізували» далі, підмірами лише підмножину репозиторіїв: main, без security і лише amd64. Мотив: «Ми встановлюємо лише з main, а security буде пізніше.» Security, як відомо, не буває «пізніше».

Під час рутинної хвилі оновлень деякі машини були спрямовані на локальний mirror, інші — на публічні дзеркала Debian. Деякі пакунки мали новіші версії в security та updates, і ці версії вимагали переходів бібліотек, яких не було у скороченому mirror. Результат — роздвоєний світ пакунків: однакові хости в різних стойках, але з різними кандидатськими версіями. Розв’язання залежностей зазнало невдачі на хостах із локального mirror.

Команда намагалася «виправити» примусово індивідуальні пакунки через apt install package=version. Це працювало доти, доки не переставало: зафіксовані версії відходили від актуальних, і наступний цикл оновлень знову породжував конфлікти. Оптимізація породила новий клас аварій: mirror сам став ненадійним джерелом істини.

Зрештою відновили: mirror повної множини suite, які використовуються в продакшні (включно з security), тримати метадані консистентними та керувати конфігураціями джерел через конфігураційний менеджмент. Це коштувало додаткового місця на диску, але оновлення перестали бути лотереєю.

Інцидент №3: Нудна практика, що врятувала ситуацію («Ми робимо snapshot перед оновленнями»)

Середовище з великим обсягом зберігання (наприклад, вузли обробки даних) використовувало Debian з ZFS-on-root. У них була проста правило: перед будь-яким OS-оновленням робити boot-environment snapshot. Це було не видовищно. Це була рядок у їхньому runbook і pre-upgrade hook в автоматизації.

Однієї ночі все ж стався частковий апгрейд: мережевий збій під час завантаження пакетів. dpkg опинився з розпакованим, але не сконфігурованим критичним пакунком. Помилки APT послідували каскадом. Вузол ще був доступний, але служби застрягли в циклі рестарту, і on-call людина була завалена сповіщеннями.

Замість імпровізації вони пішли нудним шляхом. Виконали dpkg для конфігурації очікуваних пакунків, запустили apt-get -f install і повторили повне оновлення. Коли maintainer-скрипт упав через локальну кастомізацію, вони не чинили хаотичних правок; вони відкотилися до snapshot, виправили кастомізацію і повторили оновлення.

Це не виглядало героїчно — і в цьому був сенс. Snapshot перетворив «незадоволені залежності» з «можливо, треба перебудувати вузол» у «повторюване відновлення». Вони все одно виправили основну проблему, але без паніки.

Поширені помилки: симптом → причина → виправлення

1) Симптом: «Depends: X but it is not installable» одразу після додавання вендорського репозиторію

Причина: Репозиторій орієнтований на інший реліз Debian (або Ubuntu), або вам бракує потрібних компонентів (наприклад, contrib, non-free-firmware).

Виправлення: Вимкніть репозиторій; підтвердьте правильність suite/codename; знову ввімкніть тільки якщо він відповідає Debian 13. Якщо потрібно залишити репозиторій, піньте лише конкретні пакунки, а не весь універсум.

2) Симптом: «You have held broken packages»

Причина: Явні утримання через apt-mark hold або pin’и, що фактично утримують версію.

Виправлення: apt-mark showhold, потім зніміть утримання свідомо. Перевірте /etc/apt/preferences* на широкі pin’и.

3) Симптом: APT пропонує видалити половину десктопа / ваш SSH-сервер

Причина: Змішані suite (stable + testing + unstable), сторонній репозиторій, що замінює базові пакунки, або випадкове змішування архітектур.

Виправлення: Зробіть джерела консистентними. Якщо ви хочете Debian 13 stable, використовуйте тільки suite Debian 13 (плюс backports, якщо це навмисно). Видаліть пакунки чужої архітектури, якщо вони випадкові.

4) Симптом: «dpkg was interrupted, you must manually run dpkg –configure -a»

Причина: Перерване встановлення/оновлення, раптове перезавантаження, вбите apt-процес або завислий maintainer-скрипт.

Виправлення: Запустіть sudo dpkg --configure -a. Якщо це не працює, прочитайте точну помилку, виправте файл/службу, на яку вона вказує, і запустіть знову. Не повторюйте спроби без змін.

5) Симптом: «E: Could not get lock /var/lib/dpkg/lock-frontend»

Причина: Інший apt/dpkg процес виконується (або один упав і лишив стан).

Виправлення: Знайдіть процес через ps, зачекайте, якщо він легітимний, або зупиніть його, якщо він завис. Не видаляйте lock-файли як перший крок; це ризикує пошкодити стан.

6) Симптом: «Packages have been kept back» для критичних компонентів

Причина: Оновлення вимагає встановлення нових пакунків/видалення старих; консервативне apt upgrade цього не зробить.

Виправлення: Використайте apt full-upgrade і перегляньте план. Якщо план абсурдний, джерела або pin’и ще неправильні.

7) Симптом: переходи libc6 або openssl не проходять

Причина: Відсутній репозиторій (security/updates), сторонні пакунки вимагають версій з іншого suite, або ви зафіксували старі libc/openssl.

Виправлення: Переконайтесь, що Debian-репозиторії повні й вирівняні, зніміть утримання/pin’и, тимчасово видаліть сторонні пакунки, якщо потрібно, завершіть базовий перехід ОС, потім додайте сторонні пакунки назад.

8) Симптом: «The following signatures were invalid» і потім оновлення ламається пізніше

Причина: Ви перестали отримувати оновлення, тож система відстала. Потім ви намагаєтесь встановити щось, що очікує новіших залежностей.

Виправлення: Виправте підписування/ключі репозиторіїв спочатку, запустіть apt update, а потім повне оновлення для синхронізації.

Чеклісти / покроковий план

Чекліст A: Повернути APT до консистентності (безпечна база)

1. Підтвердіть реліз: /etc/os-release має відповідати кодовій назві Debian 13.
2. Перевірте джерела: видаліть/вимкніть невідповідні suite і випадкові сторонні репозиторії.
3. Запустіть apt update і переконайтесь, що він завершується без помилок репозиторіїв.
4. Перевірте утримання: apt-mark showhold; знімайте утримання з критичних пакунків, якщо нема письмового обґрунтування.
5. Перевірте pin’и: перегляньте /etc/apt/preferences* на широкі pin’и; видаліть або обмежте їх.
6. Виправте стан dpkg: dpkg -C, потім dpkg --configure -a.
7. Запустіть apt-get -f install для відновлення залежностей.
8. Запустіть apt full-upgrade для завершення переходів.
9. Перезавантажте, якщо змінилася версія ядра/libc/systemd (зазвичай так). Потім перевірте служби.

Чекліст B: Якщо потрібно зберегти сторонній репозиторій

1. Переконайтесь, що репозиторій орієнтований на Debian 13 suite (не на Debian 12 і не на Ubuntu).
2. Віддавайте перевагу обмеженню впливу репозиторію через pin’и:
   • Піньте за origin та іменем пакунка, а не глобально.
   • Тримайте вендорські пакунки з нижчим пріоритетом, якщо вони не встановлені явно.
3. Документуйте виняток: які пакунки походять від вендора, навіщо і як відкотитися, якщо вони зникнуть.
4. Перевіряйте оновлення у стенді, який точно відображає production джерела.

Чекліст C: Коли ви вже в пастці часткового оновлення

1. Зупиніть фонова автоматику (unattended-upgrades, задачі конфігураційного менеджменту) поки не завершите відновлення.
2. Спочатку відновіть конфігурацію dpkg (dpkg --configure -a).
3. Потім відновіть залежності (apt-get -f install).
4. Після цього виконайте повне оновлення (apt full-upgrade).
5. Лише коли базова ОС стане консистентною, знову ввімкніть сторонні репозиторії і при потребі перевстановіть їхні пакунки.

Питання й відповіді

1) Чи справді мені потрібен apt full-upgrade? Звучить страшно.

Іноді так. Якщо перехід вимагає встановлення нових пакунків або видалення застарілих, apt upgrade відмовиться. full-upgrade не безрозсудний; він чесно показує, що потрібно змінити. Завжди читайте план перед погодженням.

2) У чому різниця між APT і dpkg у цій ситуації?

APT вирішує, що має статися; dpkg виконує це. Якщо APT не може знайти дійсного рішення — це питання політики/джерел/версій. Якщо dpkg не може сконфігурувати пакунки — це перерване встановлення або зломаний скрипт/конфігурація.

3) Чи можна видаляти lock-файли dpkg?

Майже ніколи. Спочатку переконайтесь, що немає легітимного apt/dpkg процесу. Видалення lock-файлів під час активності dpkg — чудовий спосіб пошкодити стан. Якщо хочеться так зробити — зупиніться й інспектуйте процеси.

4) Чому APT каже, що пакунок «не встановлюваний», коли він є в репозиторії?

Бо «встановлюваний» означає «встановлюваний за поточних обмежень»: suite, архітектура, pin’и й версії залежностей. Пакунок може бути в репозиторії, але виключений через pin, неправильний suite або відсутні компоненти.

5) Чи можна виправити незадоволені залежності, скачавши випадкові .deb файли?

Можна тимчасово залатати дірку жуйкою. Це може протривати достатньо довго, щоб зіпсувати вам вихідні плани. Віддавайте перевагу консистентним репозиторіям і дозвольте APT керувати версіями, якщо ви не робите контрольоване одноразове втручання.

6) Як зрозуміти, чи у мене змішані релізи Debian?

apt-cache policy показує рядки релізів. Якщо ви бачите кілька suite (наприклад, trixie і bookworm або sid) з подібним пріоритетом, у вас змішування. Також перегляньте /etc/apt/sources.list* на назви suite.

7) Що, якщо єдиний спосіб задовольнити залежності — видалити ключову службу?

Зазвичай це ознака неправильних репозиторіїв або того, що ви себе загнали в кут через pin’и. Спочатку виправте джерела й pin’и. Якщо сторонній пакунок викликає конфлікти, тимчасово видаліть його, завершіть оновлення ОС, а потім встановіть сторонній пакунок з сумісного репозиторію.

8) Чи варто використовувати aptitude замість APT?

Воно може запропонувати альтернативні рішення інтерактивно, що корисно, якщо ви розумієте систему. Але це не замінить правильні репозиторії й pin’и. Якщо джерела неправильні, aptitude теж запропонує погані варіанти — просто більш креативно.

9) Чому це трапляється під час оновлень релізів частіше, ніж у «звичайні дні»?

Переходи релізів і точкові оновлення запускають скоординовані зміни: libc, openssl, systemd, ядра. Якщо у вас є утримання, pin’и або відсутні suite (наприклад, security), ці переходи голосно провалюються.

10) Коли перевстановлення справді виправдане?

Коли у вас є незадокументовані ручні правки, невідомі сторонні репозиторії і роки дрейфу — плюс відсутні snapshot-и й немає часу розбиратися. Перевстановлення — це операційне рішення, а не технічна необхідність. Більшість випадків можна відновити швидше, ніж безпечно перебудувати систему.

Висновок: наступні кроки, які вам справді варто виконати

Якщо APT кричить про незадоволені залежності в Debian 13, ставтеся до цього як до проблеми консистентності, а не проблеми сили волі.

1. Приведіть джерела до ладу. Один реліз Debian, повні suite (main + updates + security) і без невідповідних вендорських репозиторіїв.
2. Приберіть політичні пастки. Зніміть утримання з критичних пакунків, відмініть широкі pin’и і не змішуйте релізи, якщо ви не робите це навмисно з жорсткими обмеженнями.
3. Відновіть стан dpkg. dpkg -C, потім dpkg --configure -a перед великими оновленнями.
4. Дозвольте APT завершити переходи. Використайте apt-get -f install для відновлення консистентності, потім apt full-upgrade для завершення роботи.
5. Після цього зафіксуйте нудну правильність. Керуйте файлами репозиторіїв через конфігураційний менеджмент, документуйте сторонні репозиторії і робіть snapshot-и перед оновленнями, якщо можете.

Мета не в тому, щоб «просто прибрати помилку». Мета — відновити систему, в якій у кожної версії пакунка є чітке походження і шлях оновлення, що не потребує молитов.