Debian 13 «Unable to locate package»: пастки репозиторіїв, архітектури та sources.list (та виправлення)

October 3, 2025 • February 3, 2026 • Читання: 6 хв • Views: 7

Було корисно?

Ви вводите apt install, натискаєте Enter, і Debian спокійно відповідає: “Unable to locate package …”. Пакунок існує. Ваш колега встановив його минулого тижня. М’язова пам’ять каже, що все має працювати.

Ця помилка — не одинична річ. Це сімейство конфігураційних проблем та застарілих припущень — імена suite, компоненти, архітектури, дзеркала, ключі, pinning і іноді просто ваша оптимістична надія. Давайте відшукаємо джерело як дорослі.

Швидкий план діагностики (робіть це спочатку)

Коли в виробництві чекають і у вас немає часу на філософські дебати з APT, виконайте це по порядку. Мета — визначити, чи вузьке місце у метаданих, репозиторіях, архітектурі або політиці.

1) Підтвердіть, як APT бачить світ (свіжість метаданих)

Запустіть apt-get update і читайте помилки, не лише код виходу.
Якщо бачите NO_PUBKEY, 403, 404 або проблеми з Release file, зупиніться. Спочатку виправте це.

2) Запитайте APT, чи знає він ім’я пакунка взагалі

apt-cache show pkg та apt-cache policy pkg покажуть, чи пакет є в налаштованих репозиторіях.
Якщо APT його не знає, проблема в джерелах/компонентах/suite/arch/синхронізації дзеркала.

3) Перевірте suite і компоненти (найпоширеніша пастка в Debian 13)

Переконайтеся, що ваш suite відповідає дійсності (наприклад, trixie vs stable vs testing).
Переконайтеся, що non-free-firmware присутній, якщо ви очікуєте прошивки.

4) Перевірте архітектуру та multiarch

Підтвердіть dpkg --print-architecture.
Якщо ви намагаєтесь встановити :i386 на amd64, додайте архітектуру і оновіть індекси.

5) Перевірте pinning / preferences

apt-cache policy покаже pin-правила і вибір кандидатів.
Pinning рідко дає «Unable to locate package», але часто дає «no installation candidate» і потім квитки неправильно класифікують проблему.

Якщо ви зробите ці п’ять кроків, причину зазвичай знайдете менше ніж за десять хвилин. Якщо ні — швидше за все, ви в ада дзеркалної синхронізації або маєте справу з репозиторієм, який перестав публікувати для вашого suite/arch.

Що насправді означає «Unable to locate package»

APT не каже вам «пакет не існує в Debian». Він каже дещо вже вузьке й набридливіше:

Локальний індекс пакунків APT не містить цього імені пакунка для жодної з увімкнених комбінацій репозиторію, suite, компонента та архітектури.
Або ви просите ім’я пакунка, яке не збігається з жодним пакетом в тих індексах (опечатка, перейменування пакунка, видалений перехідний пакет).

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

Suite (наприклад, trixie, stable, testing)
Компонент (наприклад, main, contrib, non-free, non-free-firmware)
Архітектура (наприклад, amd64, arm64, i386)

Пропустіть хоча б одну з цих «пластин», і пакет зникне з універсуму APT.

Також: Debian 13 штовхає більше людей до «нового формату джерел» і суворішої роботи з ключами. Це добрий інженерний крок. Але це також нове джерело способів якісно вистрілити собі в ногу — чисто, детерміністично й маштабовано.

Факти та контекст, що пояснюють дивні випадки

Факт 1: Debian розділяє репозиторії на suite і компоненти, щоб розділити цілі стабільності та ліцензійні обмеження; ваша конфігурація визначає, що APT може «бачити».
Факт 2: Debian ввів компонент non-free-firmware (відмінний від non-free), щоб прошивки можна було явно увімкнути без додавання всього іншого.
Факт 3: Multiarch у Debian дозволяє встановлювати пакети чужої архітектури (наприклад, :i386 на amd64), але APT не завантажить ці індекси, якщо ви не додасте архітектуру.
Факт 4: Повідомлення APT точні, але не завжди дружні: “Unable to locate package” стосується відсутніх записів індексу, а не доступності мережі чи DNS (вони зазвичай проявляються під час apt update).
Факт 5: Метадані репозиторіїв Debian підписані; сучасні налаштування віддають перевагу окремим keyring для кожного репозиторію з signed-by=, а не розкиданню ключів у глобальний кошик довіри.
Факт 6: Дзеркала можуть тимчасово не синхронізуватися; під час переходів ви справді можете бачити пакети відсутніми на одному дзеркалі і присутніми на іншому.
Факт 7: Debian підтримує і sources.list, і deb822-стиль .sources файлів; їх довільне змішування може створити дублювання, конфліктні suite або несподівану поведінку pin.
Факт 8: Пакети перейменовують, розділяють або видаляють між релізами; ім’я, яке ви пам’ятаєте зі старішої Debian, може бути зараз перехідним або взагалі зникнути.

Одна цитата, яку варто мати на моніторі:

«Надія — не стратегія.» — Джин Кранц (парафраз)

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

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

Завдання 1: Підтвердіть версію Debian і кодову назву (не вгадуйте)

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/"

Значення: Ви на trixie. Якщо ваші джерела вказують на bookworm або stable в системі з pinning, очікуйте сюрпризів.

Рішення: Узгодьте джерела з trixie (або свідомо оберіть stable/testing з pinning, який ви зможете пояснити своєму майбутньому собі).

Завдання 2: Запустіть update і реально його прочитайте

cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://security.debian.org/debian-security trixie-security InRelease
Get:3 http://deb.debian.org/debian trixie-updates InRelease [55.4 kB]
Reading package lists... Done

Значення: Індекси завантажено успішно. Якщо ви все ще не можете знайти пакет, швидше за все, причина — suite/component/arch/name, а не підключення.

Рішення: Перейдіть до завдань з пошуку пакунка (policy/show/search) замість налагодження DNS.

Завдання 3: Вловіть проблеми з підписами/ключами на ранньому етапі

cr0x@server:~$ sudo apt-get update
Get:1 https://repo.vendor.example/debian trixie InRelease [3,214 B]
Err:1 https://repo.vendor.example/debian trixie InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0123456789ABCDEF
Reading package lists... Done
W: GPG error: https://repo.vendor.example/debian trixie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0123456789ABCDEF
E: The repository 'https://repo.vendor.example/debian trixie InRelease' is not signed.

Значення: APT відмовляється довіряти репозиторію; пакети з нього фактично невидимі.

Рішення: Встановіть ключ постачальника в окремий keyring і вкажіть його через signed-by= у записі джерела (не використовуйте застаріле розкидання ключів у глобальний сховок).

Завдання 4: Друк налаштованих джерел (обидва формати)

cr0x@server:~$ grep -R --no-filename -nE '^(deb|Types:)' /etc/apt/sources.list /etc/apt/sources.list.d/* 2>/dev/null
1:deb http://deb.debian.org/debian trixie main
2:deb http://deb.debian.org/debian trixie-updates main
3:deb http://security.debian.org/debian-security trixie-security main
/etc/apt/sources.list.d/vendor.sources:1:Types: deb

Значення: У вас є класичні записи в sources.list і принаймні один deb822 .sources файл.

Рішення: Перевірте також deb822-файли; багато випадків «відсутнього пакета» — це просто «неправильний suite в іншому файлі, про який ви забули».

Завдання 5: Проінспектуйте deb822-файл на помилки suite/component

cr0x@server:~$ sed -n '1,120p' /etc/apt/sources.list.d/vendor.sources
Types: deb
URIs: https://repo.vendor.example/debian
Suites: stable
Components: main
Signed-By: /usr/share/keyrings/vendor-archive-keyring.gpg

Значення: Цей репозиторій прив’язаний до stable. На Debian 13 це може бути нормально, а може й ні — залежно від того, чи публікує вендор пакети під конкретні кодові назви.

Рішення: Якщо документація вендора очікує trixie, змініть suite. Якщо вони публікують лише під bookworm, зупиніться і переосмисліть — змішування релізів це ризик, який треба обґрунтувати.

Завдання 6: Переконайтеся, що APT знає ім’я пакунка

cr0x@server:~$ apt-cache show zfsutils-linux
N: Can't select versions from package 'zfsutils-linux' as it is purely virtual

Значення: Ім’я існує, але воно віртуальне; можливо, потрібен пакет-постачальник або ім’я змінилося в вашому suite.

Рішення: Використайте apt-cache showpkg або apt-cache policy, щоб знайти постачальників; не повторюйте apt install, як на автоматі.

Завдання 7: Перевірте кандидатів за версіями та походженням

cr0x@server:~$ apt-cache policy openssl
openssl:
  Installed: 3.3.1-1
  Candidate: 3.3.1-1
  Version table:
 *** 3.3.1-1 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages
        100 /var/lib/dpkg/status

Значення: APT бачить пакет, бачить його походження і має кандидата. Так виглядає «здоровий» стан.

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

Завдання 8: Використайте apt-cache search для виявлення перейменувань

cr0x@server:~$ apt-cache search --names-only '^python3-venv$'
python3-venv - venv module for python3 (default python3 version)

Значення: Точний пакет існує. Якщо встановлення все ще не вдається, ви маєте іншу проблему (можливо, pinning або утримувані пакети).

Рішення: Встановіть його; якщо виникає «no installation candidate», переходьте до завдань з pinning/переваг.

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

cr0x@server:~$ dpkg --print-architecture
amd64

Значення: Рідна архітектура — amd64.

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

Завдання 10: Перевірте увімкнені foreign architectures (multiarch)

cr0x@server:~$ dpkg --print-foreign-architectures

Значення: Жодної додаткової архітектури не увімкнено.

Рішення: Якщо потрібний пакет існує лише як i386, увімкніть цю архітектуру.

Завдання 11: Правильно ввімкніть i386 multiarch

cr0x@server:~$ sudo dpkg --add-architecture i386
cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Get:2 http://deb.debian.org/debian trixie/main i386 Packages [9,112 kB]
Fetched 9,112 kB in 2s (4,230 kB/s)
Reading package lists... Done

Значення: APT тепер завантажує індекси i386.

Рішення: Спробуйте apt install pkg:i386. Якщо все ще немає — пакет не опублікований для i386 у цьому suite.

Завдання 12: Підтвердіть, що компоненти включають потрібне (non-free-firmware — часта пропуск)

cr0x@server:~$ grep -n '^deb ' /etc/apt/sources.list
1:deb http://deb.debian.org/debian trixie main
2:deb http://security.debian.org/debian-security trixie-security main

Значення: Увімкнено лише main. Пакети прошивки з non-free-firmware будуть невидимі.

Рішення: Додайте non-free-firmware (і non-free/contrib лише за явною потребою).

Завдання 13: Оновіть джерела, щоб включити non-free-firmware

cr0x@server:~$ sudo sed -i 's/ main$/ main non-free-firmware/' /etc/apt/sources.list
cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Get:2 http://deb.debian.org/debian trixie/non-free-firmware amd64 Packages [32.1 kB]
Fetched 32.1 kB in 1s (35.7 kB/s)
Reading package lists... Done

Значення: Ви тепер індексуєте цей компонент.

Рішення: Повторіть встановлення прошивки; якщо вдалось — задокументуйте, чому non-free-firmware було увімкнено (щоб наступний аудит не вважав це випадковістю).

Завдання 14: Виявіть дублікати/протилежні записи (класичне зіткнення з deb822)

cr0x@server:~$ apt-get -o Debug::pkgAcquire::Auth=true update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://deb.debian.org/debian stable InRelease
W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:1 and /etc/apt/sources.list.d/debian.sources:1
Reading package lists... Done

Значення: Ви індексуєте два suite (trixie і stable) і дублюєте цілі. Це не «резервування». Це «майбутній інцидент».

Рішення: Виберіть один підхід. Віддавайте перевагу одному deb822-файлу для офіційних репозиторіїв Debian на нових системах або тримайте чистий класичний файл — просто не комбінуйте їх наполовину.

Завдання 15: Підтвердіть, що пакет існує в увімкнених компонентах

cr0x@server:~$ apt-cache policy firmware-iwlwifi
firmware-iwlwifi:
  Installed: (none)
  Candidate: 20240811-1
  Version table:
     20240811-1 500
        500 http://deb.debian.org/debian trixie/non-free-firmware amd64 Packages

Значення: Пакунок прошивки присутній і походить з очікуваного компонента.

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

Завдання 16: Доведіть, що мережа/проксі псує вид APT

cr0x@server:~$ sudo apt-get update
Ign:1 http://deb.debian.org/debian trixie InRelease
Err:1 http://deb.debian.org/debian trixie InRelease
  Could not connect to deb.debian.org:80 (199.232.138.132), connection timed out
Reading package lists... Done
W: Failed to fetch http://deb.debian.org/debian/dists/trixie/InRelease  Could not connect to deb.debian.org:80 (199.232.138.132), connection timed out
W: Some index files failed to download. They have been ignored, or old ones used instead.

Значення: Ви працюєте зі застарілими індексами. «Unable to locate package» може просто означати, що списки пакетів старі або неповні.

Рішення: Виправте підключення/проксі/фаєрвол. Поки update не чистий, вважайте результати наявності пакетів недостовірними.

Жарт 1: APT не «втрачaє» пакети. Він просто газлайтить вас, поки ви не згадаєте, що минулого місяця змінили дзеркало.

Пастки sources.list і deb822 у Debian 13

Налаштування Debian 13 часто містять суміш старого /etc/apt/sources.list і новіших /etc/apt/sources.list.d/*.sources (deb822) файлів. Обидва підходи працюють. Пастка виникає, коли вони не погоджуються.

Плутанина suite: stable/testing vs кодові назви

Використовувати stable або testing зручно доти, доки не перестає бути зручно. Коли Debian рухається, ці мітки рухаються разом з ним. Для робочих станцій це нормально. У продакшні це шлях прокинутися з іншою libc ніж учора.

Якщо ваша проблема — «unable to locate package», плутанина suite проявляється так:

Ви на Debian 13 (trixie), але джерела вказують на bookworm. Пакети, додані в trixie, не існуватимуть.
Ви на Debian 13, але сторонній репозиторій публікує лише для bookworm, а ви помилково вказали trixie. APT не бачить індексу Packages для вашого suite і тихо втрачає доступ до цих пакетів.

Пропуск компоненту: «main» — це не весь дистрибутив

«main» містить багато чого. Він не містить усього, що люди очікують як «просто Linux». Прошивки — класичний приклад, особливо на ноутбуках, Wi‑Fi і деяких контролерах зберігання.

У Debian 13, якщо вам потрібні прошивки і ви не маєте non-free-firmware, ви побачите «unable to locate package firmware-…». Це не поломка Debian. Це його прозорість.

Помилки Signed-by: репозиторій є, але ви йому не довіряєте

Сучасний APT віддає перевагу обмеженню довіри. Добре. Але це означає, що легко отримати ситуації:

Signed-By вказує на файл, якого немає
keyring встановлено, але запис репозиторію його не посилає
запис репозиторію посилається на неправильний ключ (поширено при ротації ключів)

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

deb822 підступ: один файл може містити кілька записів

Формат deb822 зручніший для автоматизації, але легше сховати складнощі. Файл може містити декілька секцій. Люди пробігають очима першу і пропускають другу, яка прикріплює інший suite або відключає компонент.

Пастки архітектури: amd64 vs i386 vs arm64

Проблеми з архітектурою нудні, саме тому вони виживають у корпоративних парках. Ви можете годину дивитися на конфіг репозиторію і не помітити, що система на arm64.

Поширені сценарії

Неправильна апаратна архітектура: Ви на arm64 (хмарні інстанси, деякі ноутбуки), але вважаєте, що amd64. Деякі сторонні репозиторії не публікують arm64 пакети.
Multiarch не увімкнено: Ви хочете :i386, але ніколи не додавали i386. APT не завантажує i386 індекси. Пакет «відсутній».
Пакет не збудовано для вашої архітектури: Офіційні репозиторії Debian можуть не будувати кожен пакет для кожної архітектури (особливо вузькі або рідкі пакети). Пакет існує, але не для вас.

Як швидко це довести

Подивіться на вивід apt-cache policy. Якщо бачите рядок походження на кшталт:

... trixie/main amd64 Packages — то ви дивитесь метадані для amd64.
Якщо в репозиторних рядках ніколи не видно вашої архітектури, вам бракує метаданих (неправильний suite, неправильний репо або update не виконується).

Компоненти: main, contrib, non-free, non-free-firmware

Тут «unable to locate package» перестає бути загадкою і перетворюється на паперову роботу.

Що кожен компонент означає операційно

main: Сумісне з Debian Free Software Guidelines. Підтримується у звичному сенсі Debian. Тут краще жити.
contrib: Вільне ПЗ, яке залежить від невільного. Це ознака компромісу, який ви збираєтесь зробити.
non-free: Невільне ПЗ. Іноді необхідне, часто жалкуване, завжди варто документувати.
non-free-firmware: Невільна прошивка. Часто необхідна для роботи апаратного забезпечення. Тримають окремо, щоб можна було увімкнути лише її без відкриття всього non-free.

Найпрактичніша порада: увімкнюйте non-free-firmware лише якщо потрібно, але не прикидайтеся, що воно не потрібне. Напівпрацюючі мережеві інтерфейси не роблять вас морально вищими; вони роблять вас запізнілими.

Дзеркала та мережеві проблеми, що маскуються під відсутні пакети

Іноді пакет справді відсутній — на вашому вибраному дзеркалі, прямо зараз. Дзеркала відстають. Проксі кешують неправильно. Шлюзи безпеки переписують трафік. І іноді внутрішнє дзеркало тихо видає індекси вчорашнього дня, бо його rsync-завдання впало.

Симптоми несинхронного дзеркала

apt-get update успішний, але ви не можете знайти пакети, які бачать колеги.
apt-cache policy показує несподівано старі версії по всьому фонду.
Одне середовище (dev) бачить пакети, інше (prod) — ні, незважаючи на «одну й ту саму конфігурацію».

Як з цим поводитися

У виробництві не перемикайте дзеркала наосліп на одному хості. Вирішіть, чи ви використовуєте:

офіційне дзеркало (добре для ноутбуків і невеликих сетів), або
контрольоване внутрішнє дзеркало (добре для відтворюваності), або
кешуючий проксі (добре доти, доки не почне брехати).

Потім моніторте це. Так, моніторте постачання пакетів так само, як сервіс. Це й є сервіс.

Pinning і змішані suite: тихий вбивця пакунків

Pinning потужний. Це також спосіб створити систему, яку може оновлювати лише одна людина, і ця людина — у відпустці.

Pinning зазвичай викликає «no installation candidate» або проблеми розв’язувача залежностей, але воно сприяє «unable to locate package», коли блокує APT від розгляду suite, в якому пакет існує — або коли ви думаєте, що ввімкнули suite, але pinning фактично його нейтралізує.

Де ховається pinning

/etc/apt/preferences
/etc/apt/preferences.d/*.pref
автоматизація, що кидає файли туди (скрипти збірки образів, системи керування конфігурацією)

Що робити

Використовуйте apt-cache policy, щоб зрозуміти вибір кандидата. Потім вирішіть, чи у вас:

система з одним suite (рекомендовано для більшості серверів), або
змішана система suite (тільки якщо ви можете пояснити історію залежностей і маєте м’язи для відкату).

Три корпоративні історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Платформна команда розгорнула образи Debian 13 для нової партії шлюзів зберігання. Пайплайн збірки «уніфікував» APT-джерела, використавши stable скрізь. Ця мітка працювала в CI. Вона навіть працювала в staging. Усім здавалося, що все гаразд.

Через два тижні знадобився вендорський пакет для телеметрії NVMe. Інженер on-call спробував його встановити. «Unable to locate package». Він припустив, що репо вендора впало, і ескалував. Підтримка вендора відповіла ввічливо, що репо в порядку і має пакети для trixie.

Твіст: репо вендора було сконфігуроване з Suites: stable, але вендор не публікував під рухому мітку — лише під кодовими назвами. APT запитував dists/stable, отримував 404 і тихо вважав репо неіснуючим після того, як під час оновлень проскочили попередження.

Інцидент був не в пакеті. Інцидентом стала затримка розгортання й паніка під час перебудови образів, поки команди зберігання чекали. Корінь — «stable означає Debian stable скрізь», розумне людське припущення, яке виявилося операційно неправильним для сторонніх репозиторіїв.

Виправлення банальне: використовувати кодові назви для сторонніх репозиторіїв і примусово забороняти попередження в apt-get update в CI. Останнє важливе: попередження — це місце, де APT каже правду, у своїй емоційно віддаленій манері.

Міні-історія 2: Оптимізація, яка відбилася боком

В іншій організації хотіли швидше провізіонування. Хтось додав внутрішній кешуючий проксі перед дзеркалами Debian. Час встановлення впав різко. Квитків стало менше. Керівництво посміхалося. Потім масштабувалися на більше регіонів і більше сегментації мережі.

Через три місяці потрібно було розгорнути оновлений пакет у відповіді на вразливість. Половина хостів повідомляла «Unable to locate package», інша половина успішно оновлювалася, і нічого не корелювало з версією ОС. On-call почав звинувачувати дзеркала Debian, тому що люди так роблять при непослідовній наявності пакетів.

Справжня проблема: проксі агресивно кешував метадані репозиторію і не враховував змін у release-файлах при переході дзеркала. Він давав застарілі списки пакетів деяким сегментам і нові — іншим, залежно від часу виключення кешу. APT не ламався; йому просто брехали.

Вони «вирішили» проблему очищенням кешів під час оновлень, що допомогло одноразово. Але це не вирішило системний ризик. Зрештою правильним рішенням стало ставлення до проксі як до продуктивного сервісу: оновити його, налаштувати правильні правила кешування для метаданих APT і додати моніторинг, який порівнює очікувані timestamps файлу Release з тим, що отримують клієнти.

Оптимізація — це добре, поки ви не оптимізуєте детермінізм. Платіж приходить пізніше, зазвичай о 2 ранку.

Міні-історія 3: Нудна практика, що врятувала день

Фінансова компанія використовувала Debian у регульованих середовищах. У них було правило: кожен базовий образ має містити один версіонований deb822-файл для репозиторіїв Debian, і збірка образу падає, якщо apt-get update виводить попередження або помилки.

Це було непопулярно. Розробники хотіли додавати репозиторії ad hoc. Декому з команд це здавалося, ніби гальмує експерименти. Безпека полюбляла це. Операції таємно любили.

Одного дня сторонній репозиторій провів ротацію ключа підпису. Багато організацій дізналися про це, коли продакшн-розгортання почали падати. У цій компанії це виявили під час збірки образів, бо apt-get update негайно зафейлив пайплайн. Виправлення застосували один раз (оновили keyring + посилання Signed-By), зашили в базовий образ і розгортання відновилися з мінімальною драмою.

Вони не уникнули еволюції екосистеми. Вони уникнули великої площі ураження. Практика була нудною, бо працювала, і працювала тому, що була нудною.

Жарт 2: Якщо ви змішаєте stable, testing і unstable без pinning — вітаємо, ви винайшли новий дистрибутив. Будь ласка, не надсилайте про це баги.

Типові помилки: симптом → корінь проблеми → виправлення

1) «Unable to locate package …» після свіжої інсталяції

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

Корінь: Джерела включають лише main, або джерела не налаштовані (мінімальна інсталяція, кастомний образ).

Виправлення: Переконайтеся, що репозиторії Debian існують і включають потрібні компоненти (main плюс non-free-firmware, якщо потрібні прошивки). Запустіть apt-get update і перевірте, що індекси компонентів завантажені.

2) Пакет існує на іншому хості, але не на цьому

Симптом: Та сама версія ОС, різні результати.

Корінь: Різні мітки suite (stable vs trixie), різні дзеркала або один хост має застарілі індекси через попередження під час оновлення.

Виправлення: Порівняйте /etc/apt/sources.list* і вивід apt-get update. Домагайтесь відсутності попереджень. Вирішіть стратегію дзеркал.

3) Пакети стороннього репозиторію «зникають» після зміни suite

Симптом: Після переходу на Debian 13 пакети вендора не знаходяться.

Корінь: Репо вендора не публікує для trixie (або публікує лише під кодовими назвами, а не під stable).

Виправлення: Встановіть у репозиторії Suites: кодову назву, яку підтримує вендор; якщо не підтримує, не примушуйте — використайте правильний реліз або ізолюйте через контейнери.

4) «Unable to locate package pkg:i386» на amd64

Симптом: APT не може знайти пакети чужої архітектури.

Корінь: Архітектура i386 не додана; i386 індекси не завантажені.

Виправлення: dpkg --add-architecture i386, потім apt-get update. Перевірте, що i386 Packages завантажено.

5) Опечатка в назві пакунка або застаріле ім’я

Симптом: Всі клянуться, що ім’я пакунка вірне. Насправді — ні.

Корінь: Пакет перейменували/розділили/видалили між suite.

Виправлення: Використовуйте apt-cache search --names-only і apt-cache showpkg. Оновіть автоматизацію на нові імена.

6) Репозиторій є, але ігнорується через проблеми підпису

Симптом: Лінії репозиторію є; встановлення каже, що пакунок не знайдено.

Корінь: GPG-ключ відсутній або неправильний; signed-by конфігуровано неправильно; репозиторій вважається недовіреним.

Виправлення: Виправте keyring і шлях Signed-By; перезапустіть apt-get update до чистого стану.

7) Дубльовані записи / змішані формати викликають плутанину

Симптом: Попередження про те, що ціль сконфігурована кілька разів; непослідовні кандидати.

Корінь: І класичні, і deb822 записи визначають перекриваючі репозиторії/suite.

Виправлення: Консолідуйте в один підхід конфігурації. Видаліть дублікати. Заново виконайте update і підтвердіть відсутність попереджень.

8) Внутрішнє дзеркало або кешуючий проксі видає застарілі метадані

Симптом: Update «працює», але доступність пакетів непослідовна між мережами.

Корінь: Збій синхронізації дзеркала або неправильні правила кешування для Release/Packages файлів.

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

Контрольні списки / покроковий план

Контрольний список A: Повернути довіру до APT (базова гігієна)

Запустіть sudo apt-get update. Якщо є попередження/помилки — зупиніться і виправте їх.
Пошукайте дублікати і конфлікти в конфігурації джерел:
- grep -R по /etc/apt/sources.list*
Уніфікуйте стратегію іменування suite:
- Використовуйте кодові назви для продакшн-стабільних середовищ, особливо для сторонніх репозиторіїв.
Використовуйте окремі keyring для кожного репозиторію з signed-by (або Signed-By у deb822).
Документуйте, чому увімкнено будь-який нестандартний компонент (non-free-firmware, non-free, contrib).

Контрольний список B: Діагностика конкретного відсутнього пакета

Підтвердіть кодову назву ОС: cat /etc/os-release.
Оновіть індекси чисто: sudo apt-get update.
Перевірте видимість пакунка:
- apt-cache policy <pkg>
- apt-cache show <pkg>
- apt-cache search --names-only
Підтвердіть наявні компоненти у ваших Debian-записах (main, можливо non-free-firmware).
Підтвердіть архітектуру:
- dpkg --print-architecture
- dpkg --print-foreign-architectures
Якщо це стороннє репо — перевірте іменування suite і довіру підписів для цього репозиторію.

Контрольний список C: Запобігання повторному виникненню (флот/підприємство)

CI-шлюз: фейлити збірки образів, якщо apt-get update виводить попередження.
Один канонічний файл джерел, під контролем версій (deb822 переважно для прозорості).
Стратегія дзеркал:
- Або офіційні дзеркала на хості, або внутрішнє дзеркало/проксі з моніторингом — не «що сьогодні працює».
Відстежуйте multiarch як усвідомлений вибір; не дозволяйте випадковим аплікаціям додавати i386 непомітно.
Періодичний аудит: дамп джерел і pin-правил, порівняння по флоту.

Поширені питання

1) Чому `apt update` успішний, а `apt install` не може знайти пакет?

Тому що apt update лише повідомляє, що воно завантажило якісь індекси успішно. Може бракувати правильного suite/component/arch або індекси — застарілі після часткових помилок.

2) Який найшвидший спосіб перевірити, чи пакет у моїх налаштованих репозиторіях?

Запустіть apt-cache policy <pkg>. Якщо немає Version table, APT його не бачить у увімкнених метаданих.

3) Чи Debian 13 тут особливий, чи це просто APT такий?

APT залишається APT, але конфіги епохи Debian 13 частіше включають deb822-джерела, суворішу роботу з keyring і широке використання non-free-firmware — усе це додає нові режимі відмов.

4) Використовувати `stable` чи кодову назву (`trixie`) у джерелах?

Для продакшну: віддавайте перевагу кодовим назвам для детермінізму, особливо для сторонніх репозиторіїв. Мітки підходять для машин розробників, де «рух вперед» — це мета.

5) Я включив `non-free-firmware`. Потрібен також `non-free`?

Ні. Увімкніть мінімальне, що потрібно. Прошивка часто достатня; non-free — ширше відро з іншими компромісами.

6) Я на amd64, але потребую i386 пакет. Чому APT його не знаходить?

Бо APT не завантажить індекси i386, поки ви не ввімкнете multiarch через dpkg --add-architecture i386 і не виконаєте apt-get update.

7) Чому я бачу попередження про дублікати, і чи це може спричинити відсутні пакети?

Дублікати ускладнюють вибір кандидатів і можуть приховати реальні невідповідності suite. Вони також вводять людей в оману. Виправте їх; ставте «configured multiple times» як баг.

8) Який правильний спосіб роботи з ключами підпису третьої сторони зараз?

Використовуйте виділений keyring-файл і посилайтеся на нього для кожного репозиторію через signed-by= (класично) або Signed-By: (deb822). Уникайте глобальних кошиків довіри та застарілих практик управління ключами.

9) Чи може пакет бути відсутнім через те, що моє дзеркало не синхронізовано?

Так. Це менш поширено у щоденній роботі, частіше під час переходів. Якщо інше дзеркало бачить пакет і ваш update чистий, підозрюйте синхронізацію дзеркала або кешуючий проксі зі застарілими метаданими.

10) Коли «Unable to locate package» — це насправді опечатка?

Частіше, ніж кому хотілося б зізнатися. Перевірте через apt-cache search --names-only і не покладайтеся на напівпам’ять назв зі старих релізів.

Висновок: наступні кроки, які можна зробити вже сьогодні

Виправлення «Unable to locate package» у Debian 13 рідко про сам пакет. Це про виправлення вхідних даних APT: suite, компонент, архітектура, підписи та свіжі метадані.

Зробіть наступне:

Зробіть apt-get update без попереджень. Не «майже нормально». Чисто.
Консолідуйте джерела в єдиний узгоджений набір (уникайте тихих конфліктів між класичними і deb822).
Явно увімкніть компоненти, які вам потрібні, особливо non-free-firmware для апаратної прошивки.
Перевірте архітектуру і multiarch, перш ніж звинувачувати репозиторій.
Якщо у вас внутрішнє дзеркало/проксі — ставтеся до нього як до продуктивної інфраструктури: моніторьте свіжість, а не «настрій».

Коли ви зможете пояснити, чому APT бачить світ саме так, «Unable to locate package» перестане бути сюрпризом і перетвориться на те, чим вона завжди була: аудит конфігурації з коротким терміном придушення.