Proxmox “pve-apt-hook failed”: чому оновлення блокуються й як безпечно розблокувати

Що насправді робить “pve-apt-hook”

Proxmox VE базується на Debian, але це не «просто Debian з веб-інтерфейсом». Це хост віртуалізації з власними поглядами: щодо ядер, репозиторіїв, узгодженості кластера, завантажувачів і порядку пакування. Ці погляди закодовані в інструментах, і одним із таких інструментів є набір APT hook-скриптів, що поставляються з пакетами Proxmox (зазвичай через pve-manager та суміжні пакети).

APT hook-и — це скрипти, які виконуються до або після операцій з пакетами — уявіть собі «перевірки перед польотом» і «прибирання після». Proxmox використовує їх, щоб запобігти класу типових помилок, які часто трапляються на гіпервізорах:

• Змішування Debian-сьютів або репозиторіїв Proxmox так, що в результаті утворюється «франкен-система».
• Оновлення до ядра або стану завантажувача, з якого вузол не зможе чисто завантажитися.
• Дозволяти вузлам кластера «відходити» на різні мажорні версії й потім дивуватися, коли corosync або API очікують іншого.
• Порушення стеків зберігання (ZFS, клієнтські бібліотеки Ceph) шляхом оновлення компонентів у неправильному порядку.
• Встановлення пакетів, які конфліктують із мета-пакетами Proxmox (наприклад, мета-пакети ядра).

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

Два важливі операційні наслідки:

1. Помилка hook-а зазвичай — симптом, а не хвороба. Виправте основний розбіжність (репозиторії, стан пакетів, блокування dpkg, конфігурацію) — і hook припинить кричати.
2. Обхід hook-а — крайній захід. Ви можете обійти APT hook-и, але тоді ви берете на себе наслідки того, що hook намагався запобігти — можливо опівночі після перезавантаження.

Парафраз ідеї (Gene Kranz): Failures are not an option — не як бахвальство, а як дисципліна: ви проектуєте системи, що не допускають уникнених відмов.

Чому оновлення блокуються: реальні режими відмов

1) Плутанина в репозиторіях: enterprise vs no-subscription, невірний suite, невірний мажор

Найпоширенішим тригером є невідповідність у репозиторіях. APT охоче обчислює шлях оновлення через змішані репозиторії. Proxmox, мудро, робить це менш охоче. Типові проблеми:

• Увімкнення pve-enterprise без підписки, що повертає HTTP 401/403 або помилки «not signed».
• Одночасна наявність pve-enterprise і pve-no-subscription, що породжує хаос пріоритетів.
• Використання Debian-сьюту, який не відповідає вашому мажорному релізу Proxmox (наприклад, перехід на trixie, тоді як Proxmox очікує bookworm).
• Копіювання списку джерел з поста в блозі, написаного для іншої версії Proxmox.

2) Пошкоджений стан APT/dpkg: перервані інсталяції, напівсконфігуровані пакети

Якщо dpkg було перервано або скрипт post-install завершився помилкою, hook-и Proxmox, як правило, блокують подальші «звичайні» оновлення, поки стан пакування не стане когерентним. APT називає це «half-installed» або «not fully installed or removed». Proxmox каже: «ні, сьогодні не варто».

3) Утримання пакетів і зафіксовані ядра

Оновлення ядра — це не те ж саме, що оновлення htop. Зафіксований пакет ядра, утриманий pve-kernel-* або невідповідний мета-пакет можуть створити ситуацію, коли Proxmox намагається тримати вас на підтримуваному шляху. Hook блокує, коли виявляє, що ви збираєтесь «відхилитися» від наміченої траєкторії.

4) Проблеми з завантажувачем / EFI, особливо після змін розмітки диска

Деякі системи оновлюються нормально й лише після перезавантаження показують проблеми — тому Proxmox тут обережний. Якщо у вас незмонтований ESP, відсутній /boot/efi або вичерпане місце в /boot, встановлення нових ядер і initramfs стає ризикованим.

5) Різниця версій у кластері та змішані мажорні версії

У кластері «оновити лише один вузол» може бути прийнятним, але оновлення між мажорними версіями потребує планування. Hook-и — це один із способів Proxmox підштовхнути вас уникнути випадкових мажорних стрибків.

6) Тісне зв’язування стеку зберігання: ZFS і Ceph

У вузлах Proxmox часто працює ZFS або клієнт Ceph (або обидва). Оновлення бібліотек, модулів ядра або інструментів користувацького простору у неправильному порядку може зламати імпорт пулів, прапори функцій або сумісність клієнта. Hook-и не вирішують усе, але вони зменшують шанс зробити щось очевидно небезпечне.

Жарт №1: APT hook — як інспектор з безпеки в касці: дратує доти, поки не врятує вас від впадання в яму, яку ви самі викопали.

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

Коли з’являється помилка, не починайте «чинити», випадково редагуючи файли. Зробіть швидку триаж у порядку. Ви шукаєте першу «пробку», яка пояснює помилку hook-а.

Перше: чи здоровий APT і чи доступні репозиторії?

• Виконайте apt update і читайте першу помилку, а не останню.
• Шукайте 401/403, «Release file», «not signed», TLS-помилки, проблеми з DNS.
• Підтвердьте, що ввімкнено лише потрібний репозиторій Proxmox (enterprise або no-subscription, а не обидва).

Друге: чи в чистому стані dpkg?

• Перевірте, чи dpkg --configure -a повідомляє про проблеми.
• Перевірте утримувані пакети (apt-mark showhold).
• Перевірте наявність завислих залежностей (apt -f install).

Третє: чи блокування стосується ядер/завантаження?

• Перевірте вільне місце в /boot і /boot/efi.
• Підтвердьте, яке ядро запущено і які ядра встановлені.
• На ZFS root підтвердьте коректний стан proxmox-boot-tool (якщо застосовно).

Четверте: міркування для кластера

• Якщо є кластер, перевірте, чи це мажорне оновлення і чи інші вузли на різних мажорних версіях.
• Перевірте здоров’я кворуму corosync перед тим, як чіпати пакети.

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

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

Завдання 1: відтворіть помилку з максимальною контекстною інформацією

cr0x@server:~$ apt-get -o Debug::pkgProblemResolver=yes -o Debug::Acquire::https=true dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Starting pkgProblemResolver with broken count: 0
...
E: Sub-process /usr/share/proxmox-ve/pve-apt-hook returned an error code (1)
E: Failure running hook scripts.

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

Рішення: Перевірте логи/повідомлення, специфічні для hook-а, потім підтвердьте репозиторії та стан dpkg.

Завдання 2: перевірте конкретний hook і пакет-власника

cr0x@server:~$ dpkg -S /usr/share/proxmox-ve/pve-apt-hook
pve-manager: /usr/share/proxmox-ve/pve-apt-hook

Що це означає: Hook походить від pve-manager. Це ваш пакет контрольної площини, і він навмисно попереджає.

Рішення: Не видаляйте його. З’ясуйте, що йому не подобається.

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

cr0x@server:~$ apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Err:3 https://enterprise.proxmox.com/debian/pve bookworm InRelease
  401  Unauthorized [IP: 51.91.38.34 443]
Reading package lists... Done
E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/bookworm/InRelease  401  Unauthorized
E: The repository 'https://enterprise.proxmox.com/debian/pve bookworm InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Що це означає: Увімкнено enterprise-репозиторій без облікових даних/підписки. APT вимикає його; hook Proxmox часто блокує оновлення, коли конфігурація репозиторіїв неконсистентна.

Рішення: Додайте правильний доступ до enterprise або відключіть enterprise-репо і ввімкніть no-subscription (робіть це акуратно).

Завдання 4: перевірте списки джерел Proxmox і Debian

cr0x@server:~$ grep -R --line-number -E 'proxmox|pve|ceph' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
/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/ceph.list:1:deb http://download.proxmox.com/debian/ceph-quincy bookworm no-subscription

Що це означає: Ввімкнені і enterprise, і no-subscription репозиторії. Це як поставити дві різні рулі в одну машину.

Рішення: Виберіть один канал репозиторіїв Proxmox. Якщо у вас немає підписки, відключіть pve-enterprise.list.

Завдання 5: безпечно відключіть невірний репозиторій (з аудиторією)

cr0x@server:~$ sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list
cr0x@server:~$ apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://download.proxmox.com/debian/pve bookworm InRelease
Hit:4 http://download.proxmox.com/debian/ceph-quincy bookworm InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

Що це означає: Тепер APT бачить узгоджені репозиторії. Ви усунули передбачуване джерело помилки.

Рішення: Повторіть оновлення. Якщо hook все ще падає, переходьте до перевірки цілісності dpkg.

Завдання 6: підтвердьте, що dpkg не напівзламаний

cr0x@server:~$ dpkg --audit
The following packages are only half configured, probably due to problems configuring them the first time.
 pve-manager

Що це означає: У вас є перервана конфігурація. Це цілком може спричиняти помилки hook-а, бо пакети Proxmox залежать від скриптів postinst.

Рішення: Завершіть конфігурацію перед подальшими оновленнями.

Завдання 7: завершіть очікувану конфігурацію пакетів

cr0x@server:~$ dpkg --configure -a
Setting up pve-manager (8.2.2) ...
Job for pveproxy.service failed because the control process exited with error code.
See "systemctl status pveproxy.service" and "journalctl -xeu pveproxy.service" for details.
dpkg: error processing package pve-manager (--configure):
 installed pve-manager package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 pve-manager

Що це означає: Тепер у вас є конкретна причина: pveproxy не запускається, через що конфігурація pve-manager не завершується.

Рішення: Зупиніть нескінченні спроби APT. Виправте проблему зі службою (часто це сертифікати, порти або конфігурація).

Завдання 8: огляньте проблемний unit systemd і логи

cr0x@server:~$ systemctl status pveproxy.service --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-26 09:41:12 UTC; 15s ago
    Process: 18722 ExecStart=/usr/bin/pveproxy start (code=exited, status=255/EXCEPTION)
...
cr0x@server:~$ journalctl -xeu pveproxy.service --no-pager | tail -n 20
Dec 26 09:41:12 server pveproxy[18722]: can't open certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 26 09:41:12 server systemd[1]: pveproxy.service: Main process exited, code=exited, status=255/EXCEPTION

Що це означає: Відсутній SSL-сертифікат у /etc/pve. Це — область кластерного файлового простору. Або pmxcfs у нездоровому стані, або файли були видалені.

Рішення: Перевірте стан pve-cluster/pmxcfs і при потребі згенеруйте сертифікати заново.

Завдання 9: перевірте стан pmxcfs (кластерної файлової системи)

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 09:39:01 UTC; 2min 34s ago
cr0x@server:~$ ls -l /etc/pve/local/ | head
total 8
-rw-r----- 1 root www-data  428 Dec 26 09:39 pve-ssl.key
-rw-r----- 1 root www-data  0 Dec 26 09:39 pve-ssl.pem

Що це означає: PEM-файл існує, але має нульовий розмір. Це призведе до аварії pveproxy.

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

Завдання 10: перегенеруйте сертифікати вузла Proxmox

cr0x@server:~$ pvecm updatecerts --force
forcing certificate regeneration
writing new private key to '/etc/pve/local/pve-ssl.key'
writing new certificate to '/etc/pve/local/pve-ssl.pem'
Restarting pveproxy.service
Restarting pvedaemon.service

Що це означає: Відсутній/порожній сертифікат виправлено, служби перезапущено. Часто цього достатньо, щоб pve-manager завершив конфігурацію.

Рішення: Повторіть dpkg --configure -a і спробуйте оновлення ще раз. Якщо це кластер — розумійте розповсюдження сертифікатів і ідентичність вузлів.

Завдання 11: перевірте здоров’я сервісів після виправлення

cr0x@server:~$ systemctl is-active pveproxy pvedaemon
active
active

Що це означає: Контрольна площина працює. Тепер скрипти postinst пакетів мають шанс виконатися успішно.

Рішення: Продовжуйте конфігурацію dpkg та оновлення.

Завдання 12: ідентифікуйте утримувані пакети (тихі саботажники)

cr0x@server:~$ apt-mark showhold
pve-kernel-6.2.16-20-pve

Що це означає: Зафіксовано пакет ядра. Іноді це свідомо (тестування сумісності апаратури). Іноді — забуте тимчасове рішення.

Рішення: Якщо немає письмового обґрунтування утримання — зніміть hold. Якщо є — очікуйте, що hook буде скаржитися, коли мета-пакети не можуть просунутися.

Завдання 13: зніміть утримання з наміром, потім перегляньте зміни

cr0x@server:~$ apt-mark unhold pve-kernel-6.2.16-20-pve
Canceled hold on pve-kernel-6.2.16-20-pve.
cr0x@server:~$ apt-get -s dist-upgrade | sed -n '1,40p'
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-kernel-6.5.13-5-pve pve-kernel-helper proxmox-ve
...

Що це означає: Імітація показує нормальний шлях оновлення ядра/мета-пакетів. Ніяких сюрпризів на кшталт видалення півсистеми.

Рішення: Продовжуйте, коли вікно обслуговування дозволяє перезавантаження (оновлення ядра — важливе).

Завдання 14: перевірте вільне місце в розділах /boot перед встановленням ядер

cr0x@server:~$ df -h /boot /boot/efi
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       512M  486M   26M  95% /boot
/dev/sda1       512M  110M  402M  22% /boot/efi

Що це означає: /boot майже заповнений. Встановлення ядер може завершитися помилкою посеред процесу, що призведе до поломки dpkg і (гірше) плутанини завантажувача.

Рішення: Видаліть старі ядра перед оновленням, але робіть це обережно, залишаючи принаймні одне завідомо робоче ядро.

Завдання 15: перелічіть встановлені ядра й безпечно видаліть старі

cr0x@server:~$ dpkg -l 'pve-kernel-*' | awk '/^ii/{print $2,$3}'
pve-kernel-6.2.16-20-pve 6.2.16-20
pve-kernel-6.2.16-22-pve 6.2.16-22
pve-kernel-6.5.13-5-pve 6.5.13-5
cr0x@server:~$ uname -r
6.2.16-22-pve
cr0x@server:~$ apt-get remove pve-kernel-6.2.16-20-pve
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  pve-kernel-6.2.16-20-pve
After this operation, 380 MB disk space will be freed.
Do you want to continue? [Y/n] y

Що це означає: Ви видалили старіше ядро, яке не працює зараз. Звільнення місця знижує ризик під час оновлення.

Рішення: Залиште запущене ядро і одне резервне. Потім продовжуйте оновлення.

Завдання 16: перевірте політику пакетів та пріоритети репозиторіїв (pinning)

cr0x@server:~$ apt-cache policy pve-manager proxmox-ve | sed -n '1,80p'
pve-manager:
  Installed: 8.2.2
  Candidate: 8.2.2
  Version table:
 *** 8.2.2 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status
proxmox-ve:
  Installed: 8.2-1
  Candidate: 8.2-1
  Version table:
 *** 8.2-1 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status

Що це означає: Кандидати надходять із очікуваного репозиторію. Якби кандидати походили з несподіваних джерел, ви б очікували конфліктів із hook-ами й дивних оновлень.

Рішення: Продовжуйте. Якщо кандидати виглядають невірно — виправте джерела/пінінг передусім.

Завдання 17: виконайте реальне оновлення в контрольованому середовищі

cr0x@server:~$ apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
...
Setting up proxmox-ve (8.2-1) ...
Processing triggers for pve-ha-manager (4.0.5) ...
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.5.13-5-pve

Що це означає: Скрипти postinst і тригери initramfs виконалися успішно — саме тут багато зламаних систем помирають.

Рішення: Плануйте перезавантаження. Не «перезавантажувати пізніше» і забути на 90 днів.

Завдання 18: підтвердьте, що hook більше не блокує, і перегляньте прапор перезавантаження

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2-1 (running kernel: 6.2.16-22-pve)
pve-manager: 8.2.2 (running version: 8.2.2)
...
cr0x@server:~$ ls -l /var/run/reboot-required 2>/dev/null || echo "no reboot flag"
-rw-r--r-- 1 root root 0 Dec 26 10:12 /var/run/reboot-required

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

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

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

Інцидент №1 (невірне припущення): «Це Debian, значить поводитиметься як Debian»

Одна команда керувала невеликим кластером Proxmox, що хостив «внутрішні» робочі навантаження. Бізнес-логіка була проста: якщо внутрішнє — не критично; якщо не критично — можна імпровізувати. Вони мали стандартний Debian playbook для оновлень і вирішили, що Proxmox теж підійде.

Невірне припущення виявилося в конфігурації репозиторіїв. Хтось увімкнув enterprise-репозиторій, бо він звучав «стабільніше», але підписки не було. apt update почав кидати помилки автентифікації. Вони побачили помилки, знизали плечима і все одно запустили apt dist-upgrade. Hook заблокував процес. Вони сприйняли це як особисту образу.

Щоб «виправити», вони закоментували hook у конфігу APT (не рекомендовано, і так, це було так само огидно, як звучить). Оновлення пройшло, але в процесі було завантажено набір пакетів з Debian, які не відповідали набору Proxmox. Негайного краху не сталося — просто поступове відхилення.

За місяць вони перезавантажили вузол для техобслуговування обладнання. Завантажилося ядро без очікуваного модуля ZFS. Імпорт не відбувся. У них не було чистого запасного ядра, бо старі ядра були автоприбрані під час попереднього «виправлення». Аварія не була драматичною; вона була повільною, заплутаною і повною суперечливих симптомів.

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

Інцидент №2 (оптимізація, що влетіла в копієчку): «Давайте пришвидшимо оновлення агресивним чищенням»

Інша організація мала жорсткі вікна обслуговування. Їхній проєкт оптимізації був простий: пришвидшити оновлення, зменшивши дисковий бруд. Добросмисленний інженер додав cron, який чистить старі ядра і кеші пакетів агресивніше, ніж за замовчуванням.

Це працювало — поки не перестало. У одного вузла був трохи менший розділ /boot (старий образ, ніколи не стандартизований). Ядра накопичувалися. Cron видаляв старі ядра без урахування правила «зберегти одне запасне ядро». Він також запускався близько до часу оновлення.

Під час рутинного оновлення initramfs-tools спробував згенерувати новий initrd і вичерпав місце посеред запису. Це той особливий вид збою, який залишає dpkg напівсконфігурованим і артефакти завантаження неконсистентними. APT hook-и почали блокувати подальші оновлення через пошкоджений стан пакування.

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

Висновок: не «не чистити». Висновок: не чистити бездумно. Підтримка дискової гігієни корисна, але життєвий цикл ядер на гіпервізорах має бути свідомим: зберігайте запасне ядро, перевіряйте простір у /boot і ставтеся до генерації initramfs як до критичного кроку.

Інцидент №3 (скучна, але правильна практика): staging, симуляція і одне зайве ядро врятували день

Третя команда працювала з міксом робочих навантажень: stateful БД, stateless веби, кілька appliance-VM і декілька хостів з GPU passthrough, яких всі боялися чіпати. Їхній процес був неефектний: кожне оновлення починалося з apt-get -s dist-upgrade, потім перевірки походження пакетів і знімок стану конфігурацій.

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

Одного тижня оновлення внесло регресію для конкретного драйвера NIC на їхньому обладнанні. Вузол перезавантажився і вийшов у стані деградованої мережі — доступний, але нестабільний для продуктивності. Оскільки вони тримали попереднє ядро, вони завантажилися з нього через віддалену консоль (IPMI). Вузол повернувся до стабільної поведінки.

Вони зафіксували проблемне ядро для цих хостів, документували причину і чекали на виправлення. Hook ніколи не став ворогом, бо команда не ставилася до оновлень як до рулетки. Виправлення було нудне, але нудне — недооцінене.

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

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

1) Симптом: «pve-apt-hook failed» одразу після увімкнення репозиторію

Корінь проблеми: Увімкнено enterprise-репо без підписки, або одночасно увімкнені enterprise і no-subscription.

Виправлення: Увімкніть рівно один канал Proxmox. Закоментуйте /etc/apt/sources.list.d/pve-enterprise.list, якщо у вас немає доступу; тримайте pve-no-subscription, якщо це ваша політика. Виконайте apt update до чистого стану.

2) Симптом: оновлення не вдається, dpkg повідомляє про «post-installation script returned error»

Корінь проблеми: Служба Proxmox (часто pveproxy, pvedaemon, pve-cluster) не може запуститися через проблеми з конфігурацією або сертифікатами.

Виправлення: Припиніть багаторазові запуски apt. Перегляньте systemctl status та journalctl, виправте службу, потім виконайте dpkg --configure -a.

3) Симптом: під час оновлення «недостатньо місця в /boot», а потім hook блокує

Корінь проблеми: Встановлення ядра перервалося посеред процесу, залишивши dpkg у зламаному стані; наступні спроби натрапляють на hook-и й помилки пакування.

Виправлення: Звільніть місце в /boot, видаливши старі ядра, що не запущені зараз. Потім виконайте apt -f install і dpkg --configure -a для відновлення.

4) Симптом: hook падає після спроб «оновлення релізу Debian»

Корінь проблеми: Невідповідність Debian-сьюту очікуванням релізу Proxmox; у джерелах може бути змішання типу bullseye/bookworm.

Виправлення: Вирівняйте джерела Debian до підтримуваного сьюта для вашого мажорного релізу Proxmox. Якщо ви робите мажорне оновлення Proxmox — дотримуйтеся спеціальної послідовності, а не просто apt dist-upgrade.

5) Симптом: оновлення пропонує видалити proxmox-ve або встановити випадкові Debian-ядра

Корінь проблеми: Конфлікти мета-пакетів, невірні пріоритети репозиторіїв або випадкове видалення мета-пакетів Proxmox.

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

6) Симптом: на ZFS-boot-системах ядра встановлюються, але вузол не завантажує нове ядро

Корінь проблеми: Проблеми синхронізації завантажувача між дзеркальними ESP або proxmox-boot-tool не оновлено після змін дисків.

Виправлення: Перевірте proxmox-boot-tool status і повторно ініціалізуйте/синхронізуйте за потреби перед довірчими оновленнями ядра.

7) Симптом: у вузлах кластера різні кандидати пакетів і помилки hook-ів виникають лише на одному вузлі

Корінь проблеми: Індивідуальні джерела на вузлі, залишковий pinning або локальний apt-проксі відрізняється.

Виправлення: Порівняйте /etc/apt і підтвердьте, що визначення репозиторіїв відповідають політиці кластера. Стандартизуйтесь по піну й очистьте застарілі списки.

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

Коли ви бачите «pve-apt-hook failed» (один вузол)

1. Зупиніться. Не запускайте ту саму команду п’ять разів поспіль. Ви не ламаєте hook силою.
2. Виконайте apt update і доведіть його до чистого стану (немає помилок автентифікації, відсутніх Release-файлів).
3. Аудит репозиторіїв Proxmox: ввімкнено рівно один канал (enterprise або no-subscription).
4. Запустіть dpkg --audit. Якщо є напівсконфігуровані пакети — виправте це першочергово.
5. Виконайте dpkg --configure -a і виправляйте помилки, відновлюючи службу або файл, що викликає postinst-помилку.
6. Перевірте apt-mark showhold на предмет утримань, що блокують мета-пакети.
7. Перевірте вільне місце в /boot і /var.
8. Симулюйте оновлення (apt-get -s dist-upgrade) і переконайтесь, що воно не видаляє proxmox-ve.
9. Проведіть реальне оновлення.
10. Перезавантажтеся в межах вікна. Перевірте, що uname -r відповідає новому ядру.

Позиція для безпечного оновлення в кластері (що зробити перед чіпанням пакетів)

1. Підтвердіть здоров’я кворуму й corosync. Оновлення кластера при нестабільному кворумі — це гра з ризиком.
2. Визначте порядок: спочатку некритичні вузли, потім критичні, потім «спеціальне обладнання» (GPU, HBA passthrough).
3. Мігруйте або вимикайте VM на вузлі, який оновлюєте. Якщо не можете — це не вікно обслуговування, а надійне сподівання.
4. Зробіть знімки конфігурацій: резервні tar-архіви /etc і /etc/pve. У кластерах поводьтеся з /etc/pve обережно.
5. Переконайтесь, що є хоча б один запасний запис для завантаження (старіше ядро).

Чого уникати (бо «працює», поки не зруйнує)

• Не видаляйте і не обходьте Proxmox APT hook-и як першу реакцію.
• Не змішуйте канали репозиторіїв «тимчасово». Тимчасові зміни мають довгий «термін напіврозпаду».
• Не оновлюйте ядра, коли /boot заповнений. Саме так ви створюєте корупцію dpkg за розкладом.
• Не робіть мажорні оновлення простим «dist-upgrade». Мажорні оновлення потребують плану й історії відкату.

Цікаві факти та історичний контекст

• Факт 1: Модель пакування Proxmox VE свідомо використовує мета-пакети (наприклад, proxmox-ve), щоб тримати узгоджений набір ядер і користувацьких компонентів.
• Факт 2: APT hook-и існують роками як механізм розширення поведінки пакетного менеджера без форку APT; Proxmox використовує їх для примусу системних інваріантів.
• Факт 3: Proxmox VE будується на Debian stable, який віддає перевагу стабільності над новизною — Proxmox вибірково накладає новіші ядра та компоненти віртуалізації зверху.
• Факт 4: Розділення на enterprise і no-subscription репозиторії — це не лише ліцензійна театральність; це також різна частота оновлень і очікування підтримки.
• Факт 5: Багато вузлів Proxmox завантажуються з ZFS (включно з дзеркальними ESP), що ускладнює керування ядром/завантажувачем порівняно з одно-дисковою ext4 кореневою системою.
• Факт 6: /etc/pve — це не звичайний каталог у кластерних налаштуваннях; це кластерна файлова система, і відсутність файлів там може свідчити про глибші проблеми стану кластера.
• Факт 7: Накопичення пакетів ядра — повторювана операційна проблема, бо ядра великі, initramfs теж, а розділи /boot часто застаріло маленькі.
• Факт 8: Історично Proxmox підтримував кілька бекендів зберігання (LVM, ZFS, Ceph), і безпечність оновлень має враховувати різні режими відмов для кожного з них.

FAQ

Q1: Це “pve-apt-hook failed” — баг APT чи баг Proxmox?

Зазвичай ні того, ні іншого. Це Proxmox навмисно повертає ненульовий код із APT hook-а, бо виявив ризиковий або неконсистентний стан. Сприймайте це як сигнал про порушення політики.

Q2: Чи можу я просто відключити hook, щоб примусово оновитися?

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

Q3: Я увімкнув pve-enterprise і тепер оновлення падають. Що робити правильно?

Якщо у вас є підписка — залиште enterprise і переконайтеся в правильності облікових даних/доступу. Якщо підписки немає — закоментуйте enterprise-репо і ввімкніть pve-no-subscription. Потім виконайте apt update до чистого стану.

Q4: Чому Proxmox так дбає про узгодженість репозиторіїв?

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

Q5: Hook падає, але apt update чистий. Що далі?

Перевірте стан dpkg (dpkg --audit), завершіть конфігурацію (dpkg --configure -a), перевірте утримання пакетів і переконайтеся, що /boot не повний. Помилки hook-ів часто йдуть після пошкодження dpkg.

Q6: Чи потрібно перезавантажуватися після оновлень?

Якщо оновилося ядро або низькорівневі бібліотеки — так. Ви можете перевірити /var/run/reboot-required і порівняти uname -r з встановленими ядрами. Перезавантажувати пізніше — нормально; забути назавжди — ні.

Q7: Як дізнатися, чи оновлення намагається видалити щось критичне?

Симулюйте: apt-get -s dist-upgrade. Якщо воно хоче видалити proxmox-ve або встановити загальний Debian-мета-ядро замість Proxmox ядра — зупиніться і виправте джерела/пінінг.

Q8: Чи по-різному ця помилка впливає на Ceph або ZFS?

Сам hook загальний, але наслідки різні. На ZFS boot сумісність ядра/модулів критична. З Ceph важлива сумісність клієнтських бібліотек. У будь-якому випадку тримайте оновлення послідовними і дотримуйтеся дисципліни «перезавантажити і перевірити».

Q9: Чому виправлення pveproxy важливе для оновлень пакетів?

Бо пакети Proxmox часто виконують post-install скрипти, які очікують запуску ключових сервісів або валідації конфігів. Якщо postinst падає — dpkg залишається зламаним, а hook ймовірно продовжить блокувати «звичайні» операції, доки ви не відновите систему.

Наступні кроки, які не укусять вас пізніше

Коли Proxmox повідомляє pve-apt-hook failed, воно не драматизує. Воно захищає інваріанти: узгоджені репозиторії, послідовний стан пакування і безпечні наслідки для ядра/завантаження. Ваше завдання — знайти, який інваріант ви порушили — і виправити саме його, а не «кур’єра» повідомлення.

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

1. Зробіть apt update чистим і переконайтеся, що ввімкнено лише потрібний канал Proxmox.
2. Відновіть стан dpkg (dpkg --audit, dpkg --configure -a) і виправте сервіси, що падають, замість повторного запуску оновлень.
3. Перевірте місце в /boot і обережно видаліть старі ядра (зберігши запасне).
4. Симулюйте оновлення перед виконанням і не ігноруйте плановані перезавантаження.
5. Для кластерів: підтвердіть кворум, оновлюйте в обраному порядку і ставтеся до кожного вузла як до продуктивної системи — бо так воно і є.