Репозиторій Proxmox без підписки: налаштування репозиторіїв без руйнування оновлень

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

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

Ця червона банерка «No valid subscription» дратує, але це не ваша реальна проблема. Справжня проблема — напівзаходи: переключення випадкових репозиторіїв, доки apt update не припинить скаржитися — і все це до моменту, коли наступне оновлення перетворить ваш вузол на музейний експонат.

Якщо ви запускаєте Proxmox в продакшні без підписки, це можна робити чисто. Але треба ставитися до APT-репозиторіїв як до управління змінами, а не як до примхи. Цей посібник точно показує, як правильно налаштувати no-subscription репозиторій, тримати Debian та Proxmox suites узгодженими та оновлюватись без рулетки.

Що ви фактично змінюєте (і чому це має значення)

Коли ви «переключаєтеся на no-subscription репозиторій», ви не натискаєте косметичний перемикач. Ви змінюєте джерело пакетів Proxmox (kernel, qemu, pve-manager, pve-kernel, corosync, часто пакети Ceph), а отже змінюється:

Частота оновлень: enterprise репозиторій куратований і відкладений; no-subscription ближчий до upstream-пайплайна пакування.
Граф залежностей: пакети Proxmox прив’язані до певного Debian suite (наприклад, Bullseye або Bookworm). Змішування suite — шлях до тихого дрейфу залежностей.
Безпека шляху оновлення: оновлення Proxmox — це фактично скоординовані оновлення Debian плюс компоненти Proxmox. Репозиторії — це дорожня карта; якщо їх неправильно налаштувати, ви їдете поза дорогою.

Цілком легітимно використовувати no-subscription в лабораторіях і в багатьох реальних бізнесах. Дисципліна, яка потрібна — така сама, як при оновленнях ядра в продакшні: узгоджені джерела, явні suites і ніякого «тільки цей пакет з testing».

Цитата, що досі актуальна (перефразована ідея): «В операціях автоматизація та обачні налаштування запобігають повторним людським помилкам.» — перефразована ідея, приписується темам DevOps від Gene Kim

Цікаві факти та історія, що пояснюють сьогоднішній безлад з репозиторіями

Конфігурація репозиторіїв у Proxmox здається дивною, поки не згадаєш, як проєкт розвивався: стек віртуалізації, Debian-база, опціональний Ceph і платний канал підтримки. Контекст допомагає зробити сьогоднішні конвенції менш довільними.

Proxmox з самого початку базований на Debian, а не просто «сумісний з Debian». Це означає, що APT — першокласний інструмент, і узгодження Debian suite є негайною вимогою.
Enterprise репозиторій існує передусім для підтримки: повільніші, куратовані оновлення, які відповідають очікуванням платних клієнтів щодо вікон змін.
No-subscription репозиторій не означає «нестабільний»; він просто менш відкладений. Пакети зазвичай потрапляють туди швидше після тестування, і ця різниця в часі важлива для ризику.
Банер підписки — це рівень UI (pve-manager перевіряє стан репозиторію/підписки). Це не означає, що ваш гіпервізор відмовляється працювати.
Основні версії Proxmox тісно відслідковують релізи Debian. Якщо ваша Debian-база — Bookworm, а репозиторії Proxmox все ще вказують на Bullseye, у вас «split-brain» ОС.
Ceph у Proxmox прив’язаний до версії Proxmox, бо кластерам потрібні сумісні версії на всіх вузлах. Невідповідність репозиторіїв може створити кластер, де половина вузлів «хоче» інший Ceph.
Історично Proxmox пакував кастомні ядра рано, щоб доставляти функції KVM/QEMU не чекаючи Debian stable. Це добре — поки випадково не витягнути ядро з невідповідного suite.
APT pinning існує з часів раннього Debian, щоб вирішувати саме цю проблему: кілька репозиторіїв, одна політика. Люди забувають, що воно є, і потім погано винаходять власні фікси з «hold» скрізь.

Модель репозиторіїв Proxmox: enterprise vs no-subscription vs Debian

1) Debian репозиторії

Ваш вузол — це Debian. Debian забезпечує базовий userland: libc, systemd, openssl, python, journald та багато «нудної інфраструктури», на якій стоїть Proxmox. Proxmox очікує конкретних Debian suites:

PVE 7.x → Debian 11 (bullseye)
PVE 8.x → Debian 12 (bookworm)

Коли ви робите мажорні оновлення PVE, фактично ви виконуєте мажорне оновлення Debian плюс пакети Proxmox. Це означає, що рядки deb Debian мають відповідати вашій мажорній версії PVE.

2) Proxmox enterprise репозиторій

Це платний канал. Якщо у вас немає підписки, залишення enterprise увімкненим зазвичай дає 401 Unauthorized або помилки apt. Найгірше — не сама помилка, а те, що люди роблять далі: додають зайві репозиторії, щоб «виправити» її, і випадково створюють Frankenstein-хост зі змішаними suites.

3) Proxmox no-subscription репозиторій

Це правильний репозиторій для систем без підписки. Його підтримує Proxmox, але без enterprise-обмежень. Ви все ще отримаєте оновлення безпеки; просто за іншим графіком.

4) Ceph репозиторії (якщо ви використовуєте Ceph)

Якщо ви запускаєте Proxmox з Ceph, ставтеся до Ceph-репозиторіїв як до частини платформи, а не як до опціонального доповнення. Proxmox зазвичай очікує конкретне мажорне релізне сімейство Ceph для певної версії PVE. Змішування Ceph-репозиторіїв — це рецепт перетворення кластера зберігання на перформанс-арт.

Жарт №1: Репозиторії APT — як офісні кавомашини: всі думають, що можуть «трохи підправити», а потім ніхто не може працювати.

Базова конфігурація: як виглядає правильне налаштування no-subscription

Правильна конфігурація має три ознаки:

Лише один канал Proxmox (enterprise АБО no-subscription, не обидва).
Debian suite відповідає мажорній версії PVE (bullseye для PVE7, bookworm для PVE8).
Ceph-репозиторії узгоджені (або Proxmox-підтримуваний Ceph-репо для вашого релізу PVE, або жодного, якщо ви не використовуєте Ceph пакети).

Proxmox використовує комбінацію /etc/apt/sources.list та /etc/apt/sources.list.d/*.list. Мета — ясність. Якщо ви не можете пояснити, що робить кожен рядок, йому не місце в продакшні.

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

Завдання 1: Визначте вашу версію Proxmox і Debian (не здогадуйтеся)

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2.2 (running kernel: 6.8.12-2-pve)
pve-manager: 8.2.4 (running version: 8.2.4/2f1f9a3d)
pve-kernel-6.8: 6.8.12-2
qemu-server: 8.2.2
pve-qemu-kvm: 9.0.2-3

Що це означає: Це PVE 8.x. Ваша Debian-база має бути Bookworm, а suite репозиторію Proxmox повинна бути bookworm.

Рішення: Якщо ви бачите PVE 7.x, використовуйте Bullseye suites. Якщо PVE 8.x — Bookworm. Будь-яка невідповідність — тривожний сигнал перед оновленнями.

cr0x@server:~$ cat /etc/debian_version
12.5

Що це означає: Debian 12 (Bookworm). Це відповідає PVE 8.x. Добре.

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

Завдання 2: Виведіть усі APT-джерела в один огляд (людям потрібна одна сторінка)

cr0x@server:~$ grep -R --line-number --no-messages '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list:1:deb http://deb.debian.org/debian bookworm main contrib
/etc/apt/sources.list:2:deb http://deb.debian.org/debian bookworm-updates main contrib
/etc/apt/sources.list:3:deb http://security.debian.org/debian-security bookworm-security main contrib
/etc/apt/sources.list.d/pve-no-subscription.list:1:deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Що це означає: Увімкнені і enterprise, і no-subscription. Це не «додаткова резервність», а конфліктна політика.

Рішення: Вимкніть enterprise, якщо у вас немає підписки. Залиште лише no-subscription.

Завдання 3: Чисто вимкніть enterprise репозиторій (не видаляйте історію без потреби)

cr0x@server:~$ sudo sed -i 's/^[[:space:]]*deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list

cr0x@server:~$ cat /etc/apt/sources.list.d/pve-enterprise.list
# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Що це означає: Рядок enterprise репозиторію закоментовано, збережено для аудиту.

Рішення: Якщо у вас є підписка, зробіть протилежне: тримайте enterprise і вимкніть no-subscription. Виберіть один.

Завдання 4: Переконайтеся, що no-subscription репозиторій існує і вказує на правильний suite

cr0x@server:~$ cat /etc/apt/sources.list.d/pve-no-subscription.list
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Що це означає: Правильно для PVE 8.x на Bookworm.

Рішення: Якщо тут ви бачите bullseye на хості Bookworm, виправте це перед оновленням.

Завдання 5: Запустіть apt update і інтерпретуйте невдачі як доросла людина

cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian bookworm-updates InRelease
Hit:3 http://security.debian.org/debian-security bookworm-security InRelease
Hit:4 http://download.proxmox.com/debian/pve bookworm InRelease
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Що це означає: Аутентифікація репозиторію в порядку, релізні файли дійсні, і APT задоволений.

Рішення: Якщо ви отримуєте 401 Unauthorized, у вас досі увімкнено enterprise або закешовані неправильні облікові дані. Якщо «Release file changed», підтвердіть, що ви на бажаному suite.

Завдання 6: Проінспектуйте candidate-версії, щоб виявити змішані suites (тихо-фатальні)

cr0x@server:~$ apt-cache policy pve-manager
pve-manager:
  Installed: 8.2.4
  Candidate: 8.2.4
  Version table:
 *** 8.2.4 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status

Що це означає: pve-manager надходить лише з очікуваного Proxmox-репозиторію.

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

Завдання 7: Виявляйте залежності між релізами Debian перед оновленням

cr0x@server:~$ apt-cache policy libc6 | sed -n '1,12p'
libc6:
  Installed: 2.36-9+deb12u9
  Candidate: 2.36-9+deb12u9
  Version table:
 *** 2.36-9+deb12u9 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages
        100 /var/lib/dpkg/status

Що це означає: libc6 строго з Bookworm. Добре.

Рішення: Якщо ви бачите кандидата з testing, sid або іншого релізу Debian, у вас дрейф репозиторіїв. Виправте джерела і за потреби застосуйте pinning.

Завдання 8: Перевірте налаштовані suites по всій системі (перевірка APT preferences)

cr0x@server:~$ apt-cache policy | sed -n '1,40p'
Package files:
 100 /var/lib/dpkg/status
 500 http://download.proxmox.com/debian/pve bookworm InRelease
 500 http://security.debian.org/debian-security bookworm-security InRelease
 500 http://deb.debian.org/debian bookworm-updates InRelease
 500 http://deb.debian.org/debian bookworm InRelease
Pinned packages:

Що це означає: Присутні лише Bookworm та Proxmox Bookworm репозиторії.

Рішення: Якщо ви бачите bullseye + bookworm одночасно — практично завжди неправильно, за винятком ретельно керованого вікна мажорного оновлення.

Завдання 9: Перевірте затримані пакети (іноді виправдані, часто забуті)

cr0x@server:~$ apt-mark showhold
pve-kernel-6.5.13-5-pve

Що це означає: Хтось утримав старе ядро. Можливо, через обхід драйвера. Можливо, без причини.

Рішення: Якщо це навмисно — задокументуйте і заплануйте видалення. Якщо випадково — зніміть hold, інакше майбутні оновлення злетять з дивними помилками залежностей.

cr0x@server:~$ sudo apt-mark unhold pve-kernel-6.5.13-5-pve
Canceled hold on pve-kernel-6.5.13-5-pve.

Завдання 10: Симулюйте оновлення перед тим, як робити його (дешева страховка)

cr0x@server:~$ sudo apt -o Debug::pkgProblemResolver=yes -s dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-manager pve-kernel-6.8.12-2-pve proxmox-ve qemu-server
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst pve-kernel-6.8.12-2-pve [6.8.12-1] (6.8.12-2 Proxmox bookworm/pve-no-subscription amd64)
Inst pve-manager [8.2.3] (8.2.4 Proxmox bookworm/pve-no-subscription amd64)
Inst proxmox-ve [8.2.1] (8.2.2 Proxmox bookworm/pve-no-subscription amd64)
Inst qemu-server [8.2.1] (8.2.2 Proxmox bookworm/pve-no-subscription amd64)
Conf proxmox-ve (8.2.2 Proxmox bookworm/pve-no-subscription amd64)

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

Рішення: Якщо симуляція пропонує видалити proxmox-ve, pve-manager або половину вашої мережевої підсистеми — зупиніться. Це свідчить про змішані репозиторії, pins або часткове оновлення.

Завдання 11: Підтвердіть запускане ядро та встановлені ядра (щоб уникнути сюрпризів при перезавантаженні)

cr0x@server:~$ uname -r
6.8.12-1-pve

cr0x@server:~$ dpkg -l 'pve-kernel-*' | awk '/^ii/ {print $2, $3}'
pve-kernel-6.8.12-1-pve 6.8.12-1
pve-kernel-6.8.12-2-pve 6.8.12-2

Що це означає: Нове ядро встановлено, але ще не запущено.

Рішення: Заплануйте вікно перезавантаження. Оновлення ядра без перезавантаження — як купити вогнегасник і залишити його в магазині.

Завдання 12: Перевірте здоров’я сервісів Proxmox після оновлень (не довіряйте «apt succeeded»)

cr0x@server:~$ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

Що це означає: Немає невдалих systemd-юнітів.

Рішення: Якщо ви бачите pveproxy або pvedaemon, які впали, ваше оновлення не «закінчене». Виправте це перед тим, як торкатися іншого вузла.

Завдання 13: Якщо ви використовуєте кластер, підтвердіть його здоров’я до і після змін репозиторіїв

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   27
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 26 14:03:41 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Що це означає: У вас є кворум. Ви не змінюєте репозиторії на вузлі, що вже горить.

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

Завдання 14: Якщо ви використовуєте Ceph, підтвердіть origin Ceph-пакетів та стан кластера

cr0x@server:~$ ceph -s
  cluster:
    id:     9a1b2c3d-1111-2222-3333-abcdefabcdef
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum a,b,c (age 5h)
    mgr: a(active, since 5h), standbys: b
    osd: 12 osds: 12 up (since 5h), 12 in (since 5h)

  data:
    pools:   4 pools, 128 pgs
    objects: 3.1M objects, 12 TiB
    usage:   36 TiB used, 72 TiB / 108 TiB avail
    pgs:     128 active+clean

Що це означає: Ceph зараз здоровий.

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

cr0x@server:~$ apt-cache policy ceph-common | sed -n '1,20p'
ceph-common:
  Installed: 18.2.2-pve1
  Candidate: 18.2.2-pve1
  Version table:
 *** 18.2.2-pve1 500
        500 http://download.proxmox.com/debian/ceph-reef bookworm InRelease
        100 /var/lib/dpkg/status

Що це означає: Ceph-пакети надходять із Proxmox-підтримуваного Ceph-репозиторію для цієї серії Ceph (приклад: Reef).

Рішення: Якщо Ceph-пакети походять з Debian main або якихось сторонніх репозиторіїв — зупиніться. Вирівняйте до Proxmox Ceph-репо, що відповідає вашій матриці підтримки PVE.

Завдання 15: Виявляйте і видаляйте «корисні» сторонні репозиторії

cr0x@server:~$ ls -1 /etc/apt/sources.list.d
pve-enterprise.list
pve-no-subscription.list
random-kernel-tuning.list

cr0x@server:~$ cat /etc/apt/sources.list.d/random-kernel-tuning.list
deb http://deb.debian.org/debian sid main

Що це означає: Хтось додав Debian sid. Ось як ви отримуєте новий libstdc++ о 14:00 і відмову о 14:05.

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

Завдання 16: Використовуйте APT pinning, якщо маєте виправдану виняткову потребу (і задокументуйте це)

Якщо вам справді потрібно тримати додатковий репозиторій (наприклад, для спеціального драйвера), встановіть pin, щоб він не «переміг» випадково. Мінімальний приклад, що віддає перевагу Bookworm і Proxmox, дозволяючи зовнішньому репо лише при явному запиті.

cr0x@server:~$ sudo tee /etc/apt/preferences.d/99-local-pinning >/dev/null <<'EOF'
Package: *
Pin: release n=bookworm
Pin-Priority: 990

Package: *
Pin: origin "download.proxmox.com"
Pin-Priority: 990

Package: *
Pin: release a=unstable
Pin-Priority: 50
EOF

cr0x@server:~$ apt-cache policy | sed -n '1,60p'
Package files:
 100 /var/lib/dpkg/status
 500 http://download.proxmox.com/debian/pve bookworm InRelease
 500 http://security.debian.org/debian-security bookworm-security InRelease
 500 http://deb.debian.org/debian bookworm InRelease
 500 http://deb.debian.org/debian sid InRelease
Pinned packages:
     release n=bookworm priority 990
     origin download.proxmox.com priority 990
     release a=unstable priority 50

Що це означає: APT майже завжди віддаватиме перевагу Bookworm та Proxmox. Unstable видно, але фактично «оптін».

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

Швидкий план діагностики

Коли оновлення йдуть не за планом, треба швидко знайти вузьке місце: неправильний репозиторій, невідповідний suite, зламані пакети або обмеження кластера. Ось порядок, що економить час.

Перший: доступність і аутентифікація репо

Запустіть apt update. Шукайте 401, помилки «Release file» або проблеми DNS/TLS.
Якщо 401 Unauthorized: enterprise репо увімкнено без облікових даних. Вимкніть його.
Якщо TLS або DNS падає: виправте мережу, синхронізацію часу або налаштування проксі до зміни репозиторіїв.

Другий: узгодження suite (Debian і Proxmox мають погоджуватися)

Перевірте pveversion -v і /etc/debian_version.
Виведіть всі deb-рядки grep-ом по джерелах.
Будь-яке змішання Bullseye/Bookworm поза вікном оновлення — негайний об’єкт для ролбеку.

Третій: попередній перегляд вирішувача залежностей

Симулюйте apt -s dist-upgrade.
Червоні прапорці: пропозиції видалити proxmox-ve, pve-manager, corosync, systemd, libc6, ifupdown2.
Стратегія вирішення: видаліть сторонні репозиторії; зніміть затримки; виправте pin; після цього знову симулюйте.

Четвертий: обмеження кластера та зберігання

Якщо кластер: підтвердіть кворум (pvecm status) перед будь-якими діями.
Якщо Ceph: перевірте ceph -s та походження Ceph-пакетів. Не змінюйте Ceph-репо під час інциденту.

Три корпоративні міні-історії з репозиторних польових боїв

Міні-історія 1: Інцидент через хибне припущення

Вони мали невеликий Proxmox-кластер для внутрішніх інструментів: CI-runner-и, тикетинг, моніторингова VM, про яку всі забули, поки вона не перестала бути критичною. Немає підписки. Хтось побачив банер підписки й вирішив «прибрати безлад».

Припущення: «Enterprise репо дає лише кращі оновлення; не зашкодить його лишити». Вони увімкнули enterprise, запустили apt update, отримали помилку автентифікації і «виправили» це, додавши ще один Debian-репозиторій з форуму. Він виявився з іншого Debian suite.

Оновлення на перший погляд пройшло нормально. Декілька пакетів оновились. Потім сервіси Proxmox почали перезавантажуватись дивним чином. Веб-інтерфейс флапав. Запуски VM інколи падали через те, що qemu-пакети і бібліотеки більше не відповідали очікуваному набору залежностей.

Постмортем був нудним у кращому сенсі: APT зробив саме те, що йому сказали. Джерела системи описували ОС, якої не існувало. Виправлення теж було нудним: вимкнули enterprise для ноду без підписки, повернули правильний Debian suite і прогнали оновлення в контролюваній послідовності з симуляціями перш ніж виконувати.

Що змінилося після: вони додали чекліст перед змінами репо і зробили «вивід усіх джерел APT» обов’язковим кроком перед будь-яким оновленням. Це не було красиво, але зупинило кровотечу.

Міні-історія 2: Оптимізація, що обернулась проти них

Інша команда хотіла швидших оновлень, швидшого CI, швидшого всього. Вони створили локальний кешуючий проксі APT і змережили «усе, що може знадобитись», щоб пришвидшити встановлення. Благородна мета. Помилка була тонкою: вони синхронізували кілька suites і не контролювали, який suite має використовуватись клієнтами.

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

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

Виправлення не полягало у відмові від кешування. Виправлення полягало у його обмеженні. Вони розділили кеші по suite (Bookworm vs Bullseye), примусили однакові рядки репо і використали pinning, щоб «найновіше» не означало «неправильне». Продуктивність повернулась. Разом з нею — і здоровий глузд.

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

Це спеціально нецікава історія. Фінансова організація вела Proxmox-кластер для VDI і кількох застарілих застосунків. Без підписки, але вони ставилися до оновлень як до продакшн-змін: поетапні оновлення вузлів, узгоджені репозиторії і правило, що жоден новий рядок репо не потрапляє в прод без тікета.

Одного дня рутинний цикл оновлень збігся з тим, що постачальник викотив зламаний пакет у сторонньому репозиторії, який вони використовували для одного агента моніторингу. Цей репо не мав би впливати на Proxmox зовсім, але міг би, якби пріоритети APT дозволяли це.

Їх захистом були дві нудні практики. По-перше, той сторонній репо був прикріплений низьким пріоритетом (pinned), тож він не міг перекривати базові пакети. По-друге, вони завжди запускали симульований dist-upgrade у процесі зміни, і симуляція показала, що вирішувач хоче видалити мета-пакет Proxmox. Це та «сирена диму», яку сприймають як тривожний сигнал, а не пораду.

Вони поправили рядок репо і продовжили. Жодного інциденту, жодних героїчних дій у вихідні. Просто ще одне нагадування, що операційна досконалість часто виглядає як «нічого не сталося».

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

1) Симптом: `apt update` показує `401 Unauthorized` для enterprise

Корінна причина: Enterprise репо увімкнено без токена підписки.

Виправлення: Закоментуйте /etc/apt/sources.list.d/pve-enterprise.list або видаліть файл. Для нод без підписки вмикайте лише no-subscription.

2) Симптом: «Release file changed» або «repository does not have a Release file»

Корінна причина: Неправильна назва suite (bullseye vs bookworm) або застарілий рядок після спроби мажорного оновлення.

Виправлення: Підтвердіть мажорну версію PVE і версію Debian, потім переконайтесь, що всі рядки відповідають. Почистіть застарілі джерела у sources.list.d.

3) Симптом: dist-upgrade хоче видалити `proxmox-ve`

Корінна причина: Змішані репозиторії або дрейф залежностей (зазвичай через testing/sid або сторонні репо, що перекривають залежності).

Виправлення: Видаліть винні репозиторії; зніміть затримки; прогоніть apt-cache policy proxmox-ve і переконайтесь, що кандидати — з правильного Proxmox-репо.

4) Симптом: Proxmox UI працює, але запуск VM падає з дивними помилками qemu

Корінна причина: qemu-server і pve-qemu-kvm — різні версії через часткові оновлення або змішані джерела.

Виправлення: Перевірте apt-cache policy для qemu-пакетів. Вирівняйте репозиторії; виконайте повний dist-upgrade; перезавантажте, якщо оновились ядро/qemu.

5) Симптом: Ceph кластер починає скаржитись після «очищення репо»

Корінна причина: Ceph-пакети тепер приходять з неправильного репо (Debian main або інша серія Ceph) або репо видалено, поки пакети лишилися.

Виправлення: Додайте назад правильний Proxmox Ceph-репо для вашої версії PVE; перевірте через apt-cache policy ceph-common; оновлюйте Ceph лише з планом ролінгового оновлення.

6) Симптом: «You have held broken packages» під час оновлення

Корінна причина: Утримувані пакети, pinned-версії або стан часткового оновлення.

Виправлення: Перевірте утримання через apt-mark showhold. Зніміть утримання, якщо це випадково. Використайте симуляцію, щоб побачити, що хоче змінитись. Виправте репо перед примусовими інсталяціями.

7) Симптом: Вузол оновився, але утиліти кластера поводяться дивно (попередження corosync, проблеми кворуму)

Корінна причина: Оновлення одного вузла до невідповідного мажорного релізу або витяг пакетів кластера з різних джерел.

Виправлення: Тримайте вузли кластера на однаковій мажорній серії під час звичайної роботи. При мажорному оновленні дотримуйтеся плану ролінгового оновлення і тримайте репозиторії узгодженими на кожному етапі.

Жарт №2: Змішування Bullseye і Bookworm — як злиття двох організаційних схем: раптом усі підпорядковуються «Depends», і ніхто не погоджує зміну.

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

Чекліст A: Безпечно перевести автономний вузол на no-subscription (PVE вже встановлено)

Зробіть снапшот поточного стану (людинозрозумілий): виведіть джерела і версії.
- Запустіть pveversion -v і збережіть вивід.
- Запустіть grep по APT-джерелах і збережіть вивід.
Вимкніть enterprise репо шляхом закоментування, а не видалення (якщо не вимагає політика відповідності).
Увімкніть no-subscription репо для правильного suite (bullseye для PVE7, bookworm для PVE8).
Запустіть apt update і переконайтесь, що нема помилок автентифікації або реліз-файлу.
Перевірте походження кандидатів для pve-manager, proxmox-ve, pve-kernel, qemu-server.
Симулюйте dist-upgrade. Якщо пропонуються видалення — зупиніться і виправте репозиторії.
Виконайте оновлення у вікні обслуговування, якщо є зміни ядра/qemu.
Перезавантажте, якщо встановлено нове ядро. Перевірте uname -r після.
Після-перевірка: перевірте сервіси Proxmox і операції запуску VM.

Чекліст B: Зміни репозиторіїв з урахуванням кластера (бо один вузол ніколи не «лише один вузол»)

Підтвердіть кворум (pvecm status).
Виберіть порядок: оновлюйте некритичні вузли першими; зберігайте принаймні N-1 потужності для HA, де можливо.
Забезпечте ідентичні APT-джерела на всіх вузлах для одного релізу PVE. Різниці — майбутні інциденти.
Один вузол за раз: зміна репо, apt update, симуляція, оновлення, перезавантаження, валідація.
Перевірте функції кластера: міграції, HA-менеджер, підключення до сховища, стабільність corosync.

Чекліст C: Якщо Ceph задіяний, ставтеся до репозиторіїв як до частини платформи зберігання

Перевірте здоров’я Ceph (ceph -s) перед зміною пакетів.
Підтвердіть походження Ceph-пакетів (apt-cache policy ceph-common).
Узгодьте Ceph-репо всередині всіх вузлів, що виконують демони Ceph.
Не поєднуйте «оновлення Proxmox» і «оновлення Ceph» в одному необмеженому вікні. Розділяйте їх, якщо немає протестованого комбінованого runbook.

FAQ

1) Чи небезпечний репозиторій no-subscription?

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

2) Чи можна увімкнути одночасно enterprise і no-subscription і дозволити APT обирати?

Не робіть цього. APT обиратиме на основі номерів версій і пріоритетів. Ця «вибірка» — не політика; це майбутній інцидент. Оберіть один канал.

3) Чи зникне банер підписки при вимкненні enterprise?

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

4) Чому Proxmox так переймається узгодженням Debian suite?

Тому що пакети Proxmox збираються проти бібліотек і тулчейну конкретного релізу Debian. Змішування suite означає змішування libc, OpenSSL, systemd-компонентів і стеків Python. Іноді це пройде — допоки не пройде.

5) Я оновив Debian до Bookworm. Можу я тимчасово тримати PVE 7 репозиторії?

Це частковий стан оновлення. Можливо, система завантажиться, але це нестійка політика. Узгодьте Proxmox-репозиторії з тією версією PVE, яку ви плануєте використовувати, і дотримуйтесь правильної процедури мажорного оновлення PVE замість імпровізацій.

6) Чи потрібен мені Ceph-репозиторій, якщо я не використовую Ceph?

Ні. Якщо ви не використовуєте Ceph-пакети, не включайте Ceph-репо «на всяк випадок». Кожен увімкнений репо — ще один рухомий елемент у вирішенні залежностей.

7) Який найпростіший спосіб виявити змішаний suite?

Використайте apt-cache policy для основних пакетів (libc6, systemd, pve-manager) і перевірте назви релізів у виводі. Також виведіть усі deb-рядки з sources.list*. Змішані suites видно швидко.

8) Використовувати `apt full-upgrade` чи `apt dist-upgrade` для Proxmox?

Вони за змістом прагнуть одного і того ж (дозволяти зміни залежностей). Головне — спочатку симулювати і трактувати запропоновані видалення як сигнал тривоги. Використовуйте те, що стандартизовано у вашій команді, але дотримуйтеся послідовності.

9) Чи можна «виправити» зламане оновлення примусовою установкою через `dpkg --force`?

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

10) Як тримати кілька Proxmox вузлів консистентними з часом?

Стандартизувати файли репозиторіїв, періодично їх аудтувати і ставитися до змін репо як до конфігураційних змін. Практично: керуйте /etc/apt/sources.list.d/ через автоматизацію і періодично порівнюйте виводи grep та apt-cache policy між вузлами.

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

Запускати Proxmox без підписки — не гріх. Гріх — робити це з хаотичними репозиторіями. Якщо ви хочете чистих оновлень, оберіть смугу руху (enterprise або no-subscription), тримайте Debian suites узгодженими з мажорною версією PVE і ніколи не «виправляйте» помилку автентифікації додаванням випадкових репозиторіїв.

Наступні кроки:

На одному вузлі виведіть усі APT-джерела і переконайтесь, що увімкнено рівно один Proxmox-канал.
Запустіть apt-cache policy pve-manager і переконайтесь, що кандидат надходить з очікуваного репозиторію та suite.
Симулюйте dist-upgrade. Якщо він хоче видалити базові пакети Proxmox — вважайте це дефектом конфігурації, а не кроком оновлення.
Якщо кластерний — робіть зміни вузол за вузлом з перевірками кворуму і валідацією після перезавантаження.