Proxmox — «dpkg was interrupted»: виправлення пошкоджених пакетів без перевстановлення

Що насправді означає «dpkg was interrupted»

Proxmox працює на Debian. Debian використовує dpkg для виконання низькорівневих кроків розпакування/налаштування.
apt — це вищий рівень, що вирішує залежності й організовує dpkg.
Коли dpkg переривається — відключення живлення, примусове завершення процесу, брак місця на диску, зламаний pre/postinst-скрипт
або конфлікт пакунків — воно залишає напівзаписаний стан у /var/lib/dpkg/.

Сумнозвісне повідомлення зазвичай означає, що пакетний менеджер каже вам:
«Я не можу рухатися далі, поки не завершаться очікувані кроки конфігурації».
Це не порада. Це журнал транзакцій, який просить вас відтворити незавершену частину.

Є дві широкі категорії проблем із «пошкодженими пакетами» на Proxmox:

• Чисто проблеми стану dpkg/apt: файли блокування, перервані конфігурації, відсутні залежності,
  часткове розпакування. Це виправляється на хості за допомогою обережних команд.
• Проблеми з репозиторіями/невідповідністю: змішування релізів Debian, мікс репозиторіїв Proxmox
  або невірне pinning. Це може виглядати як помилки dpkg, але справжнє виправлення — «припиніть давати apt сміття».

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

Одна цитата, щоб тримати вас у рамках: «Надія — не стратегія.» — генерал Гордон Р. Салліван.
(Не програміст, але кожна чергова зміна з ним погодиться.)

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

Перший: чи дійсно dpkg працює, чи просто завис?

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

Другий: чи файлові системи здорові й доступні для запису?

«dpkg was interrupted» часто означає «диск заповнений» або «root-файлова система перейшла в режим лише для читання».
На хості Proxmox це може бути спричинено ростом логів, повним local-lvm, зламаним дзеркалом або збоями SSD.

Третій: чи apt отримує коректні репозиторії?

Вузол із неправильною кодовою назвою Debian або змішаними репозиторіями Proxmox може зірвати оновлення посередині й залишити
dpkg напівсконфігурованим. Виправлення dpkg без виправлення репозиторіїв просто повторить помилку, але голосніше.

Далі: відновлення стану dpkg, залежностей, перевірка сервісів Proxmox

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

Цікаві факти та коротка історія (чому це повторюється)

1. dpkg існує довше ніж apt. dpkg походить з раннього Debian; apt з’явився пізніше, щоб краще вирішувати залежності
   і працювати з віддаленими репозиторіями.
2. dpkg навмисно «примітивний». Воно не вирішує залежності; воно виконує скрипти пакетів
   і фіксує стан. Така простота робить його передбачуваним — і вона не дозволяє «вгадувати» як відновитись.
3. Скрипти Debian-пакетів — це код, а не метадані. Preinst/postinst-скрипти можуть робити майже все:
   оновлювати initramfs, перезапускати сервіси, перезаписувати конфіги. Це й сила, й небезпека.
4. Proxmox — це дистрибутив на основі Debian з власними пакетами. Proxmox накладає своє ядро,
   стек управління та політики репозиторіїв зверху Debian, тому змішування репозиторіїв тут особливо болюче.
5. Блокування — це кооперативний механізм. Файли блокувань у /var/lib/dpkg/ та
   /var/lib/apt/lists/lock не мають магічних властивостей; це конвенція. Видалення їх під час активного процесу
   запрошує корупцію.
6. Перервані оновлення раніше були частішими на обертових дисках. Повільний I/O плюс агресивні таймаути
   плюс люди, які перезавантажують систему, бо «вона зависла», створювали багато напівсконфігурованих систем.
7. dpkg фіксує детальні стани. Пакети можуть бути «розпаковані, але не налаштовані», «напівсконфігуровані»,
   «очікуються triggers» тощо. Точний стан часто підказує, з яким типом помилки ви маєте справу.
8. Triggers існують для пакетування роботи. Такі операції, як update-initramfs або
   update-ca-certificates, можуть відкладатися через тригери — аж поки переривання не залишить їх у очікуванні.

Безпека перш за все на хості Proxmox (не заблокуйте вузол)

На ноутбуці можна грубо пробувати виправити пакети. На хості Proxmox, що запускає VMs/CTs,
потрібна трохи дисципліни:

• Не перезавантажуйте «щоб очистити». Перезавантаження не виправить стану dpkg. Воно просто додає нову невідомість,
  наприклад сервіси, що не стартують, бо їхні пакети ніколи не завершили конфігурацію.
• Не перезапускайте сервіси Proxmox під час оновлення, якщо це не необхідно. Коли пакети управління в процесі,
  перезавантаження pveproxy може відрізати вас від доступу. Використовуйте SSH і тримайте відкритий один root-шелл.
• Уникайте героїчних дій лише по мережі. Якщо це вузол у дата-центрі без OOB-доступу,
  заплануйте вікно або переконайтесь, що IPMI/iKVM працює. «Це просто пакунки» — так ви опинитесь за кермом о пів на другу ночі.
• Зробіть snapshot кореневого диска, якщо можете. Якщо Proxmox OS на ZFS root — зробіть знімок.
  Якщо на LVM-thin і у вас є механізм знімків на рівні гіпервізора — скористайтесь ним. Відкат кращий за жаління.

Жарт №1: Сліпе видалення файлів блокування dpkg — це як різати червоний дріт, бо він «виглядає впевненіше».
Іноді це працює. Це не похвала.

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

Нижче — завдання, які я справді виконую в продакшні, коли вузол Proxmox отримує «dpkg was interrupted».
Кожне завдання включає: команду, типовий вивід, що це означає, і яке рішення прийняти.
Виконуйте їх у порядку, якщо немає причини робити інакше.

Завдання 1: Підтвердити процеси apt/dpkg і чи вони зависли

cr0x@server:~$ ps aux | egrep 'apt|dpkg' | egrep -v egrep
root      1523  0.0  0.1  21440  9820 ?        Ss   10:11   0:00 /usr/bin/dpkg --configure -a
root      1544  0.2  0.1  72868 11640 ?        S    10:11   0:03 /usr/bin/perl /usr/share/debconf/frontend /var/lib/dpkg/info/pve-manager.postinst configure

Що це означає: dpkg працює і активно конфігурує пакети (тут він у postinst).

Рішення: Чекайте. Перевірте CPU/диск. Якщо воно дійсно зависло (немає I/O, немає прогресу тривалий час),
перегляньте логи і скрипт, який виконується, перш ніж вбивати що-небудь.

Завдання 2: Перевірити файли блокування dpkg без їх видалення

cr0x@server:~$ sudo lsof /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dpkg    1523 root    3uW  REG  252,0        0  811 /var/lib/dpkg/lock-frontend

Що це означає: Блокування утримується dpkg з PID 1523.

Рішення: Не видаляйте блокування. Якщо файл існує, але жоден процес його не тримає — це інша історія.

Завдання 3: Перевірити вільне місце на root (повний диск — класика)

cr0x@server:~$ df -hT /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   60G   59G  320M 100% /

Що це означає: Місця немає. dpkg не може надійно розпаковувати/конфігурувати.

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

Завдання 4: Перевірити, чи файлова система не перейшла в режим лише для читання

cr0x@server:~$ mount | grep ' on / '
/dev/sda2 on / type ext4 (ro,relatime,errors=remount-ro)

Що це означає: Root змонтовано тільки для читання. dpkg буде невпинно падати.

Рішення: Зупиніться. Перевірте dmesg, стан сховища і робіть remount лише якщо безпечно.
Read-only remount зазвичай вказує на помилки файлової системи або проблеми з пристроєм.

Завдання 5: Прочитати останні записи логів dpkg/apt (знайти реальну помилку)

cr0x@server:~$ tail -n 40 /var/log/dpkg.log
2025-12-26 10:10:59 unpacked pve-manager:amd64 8.2.4
2025-12-26 10:11:01 configuring pve-manager:amd64 8.2.4
2025-12-26 10:11:04 status half-configured pve-manager:amd64 8.2.4
2025-12-26 10:11:04 error processing package pve-manager:amd64 (--configure):
 installed pve-manager package post-installation script subprocess returned error exit status 1

Що це означає: Помилка всередині скрипта пакета (postinst), а не у вирішенні залежностей.

Рішення: Ймовірно, потрібно прочитати вивід postinst (див. наступні завдання) і виправити корінну причину.

Завдання 6: Запустити відтворення конфігурації dpkg (канонічне перше виправлення)

cr0x@server:~$ sudo dpkg --configure -a
Setting up pve-manager (8.2.4) ...
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

Що це означає: dpkg виконав свою частину; пакет впав через проблему зі стартом/перезапуском сервісу.

Рішення: Не запускайте dpkg знову й знову в надії, що воно поміняє думку. Дебагуйте невдалий сервіс.

Завдання 7: Інспектувати сервіс, що падає (pveproxy — частий підозрюваний)

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 Fri 2025-12-26 10:11:03 UTC; 12s ago
    Process: 1622 ExecStart=/usr/bin/pveproxy start (code=exited, status=255/EXCEPTION)
   Main PID: 1622 (code=exited, status=255/EXCEPTION)
     Status: "starting server"
     Error: unable to load certificate '/etc/pve/local/pve-ssl.pem': No such file or directory

Що це означає: dpkg падає, бо pveproxy не може стартувати через відсутні сертифікати.
Це часто відбувається після проблем з кластерною файловою системою, правами чи неповним станом pve-cluster.

Рішення: Виправте підлягаючу конфігурацію Proxmox (відновлення сертифікатів, здоров’я /etc/pve), потім перезапустіть dpkg.

Завдання 8: Перевірити доступність /etc/pve та стан кластерної файлової системи

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

Quorum information
------------------
Date:             2025-12-26 10:12:01
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.1a
Quorate:          Yes

Що це означає: Кластер має кворум, що сильно вказує на те, що /etc/pve має бути змонтовано й доступне для запису.

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

Завдання 9: Регегенерувати сертифікати Proxmox, якщо це блокер

cr0x@server:~$ sudo pvecm updatecerts --force
Generating new node certificate...
Restarting pveproxy and pvedaemon...
Done.

Що це означає: Сертифікати вузла регенеровано, сервіси перезапущено.

Рішення: Повторіть dpkg --configure -a. Якщо регенерація сертифікатів не вдається, перевірте права та монтування /etc/pve.

Завдання 10: Автоматично відновити проблеми із залежностями (якщо dpkg недостатньо)

cr0x@server:~$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
The following packages will be upgraded:
  pve-manager pveproxy pvedaemon
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/2,914 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up pveproxy (8.2.3) ...
Setting up pvedaemon (8.2.3) ...
Setting up pve-manager (8.2.4) ...

Що це означає: apt знайшов узгоджений план залежностей і застосував його. Це часто вирішує часткові оновлення.

Рішення: Якщо apt пропонує видалення ключових пакетів Proxmox (наприклад, pve-manager), зупиніться і дослідіть репозиторії/пінінг.

Завдання 11: Виявити «напіввстановлені» пакунки та їхній стан

cr0x@server:~$ dpkg -l | awk '$1 ~ /^(iF|iU|iH|iW|rc)$/ {print}'
iF  pve-manager   8.2.4   amd64   Proxmox Virtual Environment manager
iU  pve-kernel-6.8 6.8.12-4 amd64 Proxmox kernel image

Що це означає: Ці пакети не встановлені/сконфігуровані коректно.

Рішення: Сфокусуйте дебаг на цих пакетах. Застрягле ядро в стані iU може зламати логіку завантаження або збірки DKMS-модулів.

Завдання 12: Перевірити утримувані (held) пакети, що заважають apt

cr0x@server:~$ apt-mark showhold
pve-kernel-6.8
zfs-dkms

Що це означає: Хтось зафіксував пакети. Іноді це навмисно; часто — забуте налаштування.

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

Завдання 13: Зняти утримання (лише після розуміння причин)

cr0x@server:~$ sudo apt-mark unhold pve-kernel-6.8 zfs-dkms
Canceled hold on pve-kernel-6.8.
Canceled hold on zfs-dkms.

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

Рішення: Негайно виконайте apt-get -f install або apt full-upgrade для збіжності.

Завдання 14: Перевірити конфігурацію репозиторіїв на предмет адекватності (специфічно для Proxmox)

cr0x@server:~$ grep -R --line-number -E 'pve|proxmox|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

Що це означає: Реліз Debian — Bookworm, і репозиторій Proxmox відповідає Bookworm. Це добре.

Рішення: Якщо ви бачите змішані кодові назви (bullseye + bookworm) або одночасно enterprise і no-subscription без наміру — виправте це спершу.

Завдання 15: Оновити списки пакетів і виявити негайні помилки репозиторіїв

cr0x@server:~$ sudo 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
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Що це означає: Репозиторії доступні й метадані узгоджені.

Рішення: Якщо ви бачите 401/403 або помилки підписів, не продовжуйте оновлення, поки не виправите доступ/довіру до репозиторіїв.

Завдання 16: Завершити ремонт контрольованим оновленням

cr0x@server:~$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-kernel-6.8 pve-manager pveproxy pvedaemon
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 58.4 MB of archives.
After this operation, 312 MB of additional disk space will be used.
Do you want to continue? [Y/n] y

Що це означає: apt має узгоджений план. Він оновлює ключові компоненти; це нормально для Proxmox.

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

Завдання 17: Перевірити, що база пакетів чиста

cr0x@server:~$ sudo dpkg --audit

Що це означає: Відсутність виводу — добре: dpkg не бачить пошкоджених/напіввстановлених пакетів.

Рішення: Якщо воно виводить пакети — робота ще не завершена; повертайтесь до логів і невдалих скриптів.

Завдання 18: Підтвердити, що сервіси управління Proxmox здорові

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

Що це означає: Площина управління працює.

Рішення: Якщо якийсь неактивний — перевірте journalctl -u перед тим, як вважати справу закритою.

Завдання 19: Очищення старих блокувань лише якщо вони застаріли (рідко, але реально)

cr0x@server:~$ sudo lsof /var/lib/dpkg/lock-frontend
cr0x@server:~$ sudo ls -l /var/lib/dpkg/lock-frontend
-rw-r----- 1 root root 0 Dec 26 10:05 /var/lib/dpkg/lock-frontend

Що це означає: Жоден процес не тримає блокування, але файл існує (це нормально). Блокування — це файли, а не сокети.

Рішення: Не видаляйте просто тому, що файл існує. Дійте лише якщо apt явно скаржиться на блокування і ви перевірили, що ніхто його не тримає.

Завдання 20: Коли скрипт пакета зламаний — прогнати його в режимі налагодження

cr0x@server:~$ sudo sh -x /var/lib/dpkg/info/pve-manager.postinst configure
+ set -e
+ systemctl daemon-reload
+ systemctl try-restart pveproxy.service
Job for pveproxy.service failed because the control process exited with error code.
+ exit 1

Що це означає: postinst падає саме на перезапускі сервісу.

Рішення: Виправте залежність сервісу (сертифікати, порти, конфіг, диск) замість того, щоб ліпити стан dpkg.
Якщо потрібно зберегти вузол працездатним, іноді можна тимчасово заборонити перезапуски — але це крайній захід і має бути задокументовано.

Жарт №2: dpkg не «зламане», воно просто тримає вас до того стандарту, який ваш change manager прикидається, що має.

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

Інцидент через хибне припущення: «Це лише GUI-пакет»

Середня компанія мала три вузли Proxmox, що хостили внутрішні сервіси: Git-сервер, моніторинг, CI-ранери
та кілька Windows-VM, за які ніхто не хотів визнаватися. Одного дня адміністратор побачив очікувані оновлення і запустив apt upgrade
на вузлі в робочий час. Оновлення зависло, потім вузол почав віддавати «dpkg was interrupted».

Хибне припущення було простим: вони думали, що pve-manager — «тільки веб-інтерфейс». Це не так. Скрипти пакета
перезапускають сервіси, торкаються сертифікатів і залежать від здоров’я кластерної файлової системи. Під час оновлення вузол
коротко втратив кворум через окрему мережеву зміну. postinst намагався доступитись до /etc/pve, отримав частковий стан
і впав. dpkg зупинився посеред конфігурації.

Їхня перша реакція — перезавантаження. Вузол піднявся, але proxy не запустився. Тепер вони не могли використовувати веб-UI для міграцій.
SSH працював, але команда витратила час, шукаючи «де Proxmox зберігає бінарник GUI», наче це десктопний додаток.

Виправлення не було драматичним. Вони відновили кластерну підключеність, підтвердили кворум, регенерували сертифікати вузла, знову запустили
dpkg --configure -a, а потім закінчили оновлення. Більший урок: у Proxmox пакети управління — це операційні пакети.
Тримайте їх як оновлення ядра гіпервізора.

Оптимізація, що обернулась проблемою: «Давайте автоматично оновлювати все щодня»

Інше середовище мало ініціативу модернізації: менше ручних кроків, більше автоматизації. Вони розгорнули unattended upgrades
на вузлах Proxmox. Ідея була логічною — оновлення без людських помилок. Реалізація — ні.

Вони не синхронізували це з вікнами обслуговування чи реальністю сховища. Деякі вузли мали маленькі кореневі розділи та високу генерацію логів.
Однієї ночі unattended upgrades спробували втягнути оновлення ядра й нові пакети прошивки, поки root був майже повний.
dpkg розпакував частково, потім закінчилось місце. Вузол продовжував запускати VM, але наступний apt показував «dpkg was interrupted».

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

Вони виправили це, вимкнувши unattended upgrades на гіпервізорах, додавши явні перевірки вільного місця
і виконуючи оновлення у запланованих вікнах з пост-перевірками: аудит dpkg, здоров’я сервісів і черга перезавантажень для змін ядра.
Автоматизація — крута річ. Автоматизація хаосу — це все ще хаос, просто швидше.

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

Третя організація мала суворе правило: будь-яка зміна пакетів гіпервізора вимагала (1) перевірений OOB-консоль,
(2) недавню резервну копію конфігурації і (3) план відкату. Це здавалося бюрократією, поки вузол не помер найбанальнішим способом:
глюк прошивки викликав ремонт файлової системи в режим лише для читання під час оновлення пакета.

dpkg зупинився посеред транзакції. Вузол все ще хостив критичні навантаження, а веб-UI став нестабільним, бо сервіси не могли
записувати файли в /var. Але оскільки у них був iKVM і знімок ZFS root зроблений перед обслуговуванням,
вони могли спокійно вирішити: спочатку спробувати ремонт, а якщо треба — відкотитись і евакуювати.

Вони перевірили стан дисків, підтвердили помилки в кореневому пулі і вирішили не форсувати записи. Міґрували VM з вузла,
перезавантажились у rescue-середовище, відремонтували файлову систему, після чого знову запустили конфігурацію dpkg.
Знімок навіть не знадобився, але він знизив тиск. Ось що купує «нудність»: час на обдумані рішення.

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

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

Корінь проблеми: Інший процес apt/dpkg працює (або завис), або фоновий інструмент виконує оновлення.

Виправлення: Використовуйте ps і lsof, щоб знайти процес. Якщо він легітимний — зачекайте.
Якщо процес застряг, дослідіть причину (повний диск, завислий NFS, зламаний postinst). Вбивати — останній варіант,
потім запустіть dpkg --configure -a.

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

Корінь проблеми: Є очікувані кроки конфігурації пакетів; база dpkg вказує на незавершений стан.

Виправлення: Запустіть dpkg --configure -a. Якщо воно падає, слідуйте за невдалим скриптом/сервісом,
а не за емоціями. Читайте /var/log/dpkg.log і journalctl.

3) Симптом: dpkg configure падає на pve-manager/pveproxy через відсутні сертифікати

Корінь проблеми: /etc/pve не змонтовано коректно, проблеми з кворумом або сертифікати відсутні/пошкоджені.

Виправлення: Перевірте pvecm status. Забезпечте кворум. Регенеруйте сертифікати командою
pvecm updatecerts --force, потім знову запустіть конфігурацію dpkg.

4) Симптом: «No space left on device» під час оновлення

Корінь проблеми: Root-файлова система заповнена; dpkg не може розпаковувати/налаштовувати. Іноді це /boot,
засмічене старими ядрами.

Виправлення: Звільніть місце безпечно (очистіть кеш apt, скоротіть логи, видаліть старі ядра, якщо точно знаєте, що робите).
Потім повторіть dpkg --configure -a і apt-get -f install.

5) Симптом: apt хоче видалити мета-пакети Proxmox (pve-manager, proxmox-ve)

Корінь проблеми: Змішані релізи Debian, неправильний репозиторій Proxmox або pinning, що спричиняє конфлікти залежностей.

Виправлення: Зупиніться. Аудитуйте /etc/apt/sources.list*. Вирівняйте кодові назви.
Видаліть конфліктні репозиторії. Повторіть apt update і перегляньте план.

6) Симптом: dpkg зациклюється на тригерах (initramfs, ca-certificates) і ніколи не завершується

Корінь проблеми: Команда-trigger падає (часто через брак місця, зламаний хук ядра або некоректне середовище update-initramfs).

Виправлення: Запустіть інструмент тригерів вручну і зафіксуйте помилки. Виправте підлягаючу причину,
потім знову запустіть dpkg --configure -a.

7) Симптом: Скрипти пакетів зависають назавжди

Корінь проблеми: Очікування зупинки сервісу, що ніколи не завершується, блокований I/O, зависання DNS у скрипті
або інтерактивний prompt у неінтерактивній сесії.

Виправлення: Перевірте journalctl, підтвердьте I/O-стан і забезпечте noninteractive-фронтенд,
якщо працюєте віддалено. Якщо потрібно, встановіть DEBIAN_FRONTEND=noninteractive для ремонту.

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

Фаза 0: Переконайтеся, що ви не пожалкуєте

• Підтвердьте доступ по SSH і, бажано, наявність консолі OOB.
• Провірте, чи витримаєте ви рестарт площини управління (тримайте одне з’єднання відкритим).
• Спершу перевірте вільне місце й здоров’я файлової системи.
• Якщо в кластері: підтвердьте кворум. Скрипти пакетів, що торкаються /etc/pve, не люблять неоднозначності.

Фаза 1: Швидка діагностика режиму відмови

1. Перевірте запущені процеси: ps aux | egrep 'apt|dpkg'.
2. Перевірте блокування за допомогою lsof.
3. Перевірте місце на диску (df -h) і прапори монтування (mount).
4. Читайте /var/log/dpkg.log і останні записи журналу для невдалого юніту.

Фаза 2: Відновлення стану dpkg і залежностей

1. Запустіть dpkg --configure -a.
2. Якщо воно падає — виправте причину (конфіг сервісу, сертифікати, сховище, репозиторії).
3. Запустіть apt-get -f install для виправлення залежностей.
4. Запустіть apt full-upgrade для приведення системи в стан узгодженості.
5. Переконайтеся, що dpkg --audit не повертає нічого.

Фаза 3: Proxmox-специфічні перевірки після ремонту

1. Перевірте сервіси управління: systemctl is-active pveproxy pvedaemon pvestatd.
2. Підтвердьте стан кластера (за потреби): pvecm status.
3. Підтвердьте узгодженість ядра/модулів, якщо використовується ZFS: переконайтесь, що нове ядро і пакети zfs встановлені коректно перед перезавантаженням.
4. Заплануйте перезавантаження, якщо ядро оновлено; не робіть це спонтанно під час пікового навантаження.

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

1) Чи можу я виправити «dpkg was interrupted» без перезавантаження?

Зазвичай так. Ремонти dpkg/apt — це операції в простежі користувача. Перезавантаження не вирішує стан бази dpkg.
Перезавантажуйтеся тільки після встановлення нового ядра або виправлення проблеми з файловою системою, що цього потребує.

2) Чи завжди безпечно запускати dpkg --configure -a на Proxmox?

Це правильний перший крок, але «безпечно» залежить від причини переривання. Якщо диск повний або root у режимі read-only,
воно впаде і може ускладнити ситуацію. Спершу перевірте здоров’я файлової системи.

3) apt хоче видалити proxmox-ve або pve-manager. Чи дозволяти?

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

4) Що робити, якщо dpkg застряг у виконанні postinst-скрипта?

Визначте, який саме скрипт задіяно за допомогою ps, потім перевірте його залежності: перезапуск сервісів, файли під /etc/pve,
DNS або сховище. Якщо воно дійсно зависло (немає I/O, немає прогресу), дослідіть логи і прогоніть скрипт у трасуванні.
Вбивати dpkg — крайній варіант і мусить супроводжуватись негайними кроками відновлення.

5) Чи потрібно зупиняти VMs/контейнери перед ремонтом пакетів?

Не завжди. Багато ремонтів можливо виконати вживу. Але якщо ви оновлюєте ядро, стек ZFS або ключові сервіси Proxmox,
заплануйте вікно. Хост може продовжувати працювати з навантаженнями, але доступ управління може мигати під час перезапусків.

6) Чому помилка сертифіката ламає dpkg?

Тому що скрипти пакетів часто перезапускають сервіси, щоб активувати нові версії. Якщо pveproxy не може стартувати через відсутні
SSL-файли, postinst завершується з ненульовим кодом. dpkg трактує це як «пакет не налаштований» й зупиняє транзакцію.

7) Як я дізнаюсь, що база пакетів знову чиста?

Запустіть dpkg --audit (відсутність виводу — добре), перевірте dpkg -l на незвичні стани (iF, iU) і переконайтесь,
що apt-get -f install більше нічого не виправляє.

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

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

9) Чи змінює кластерний режим спосіб ремонту пакетів?

Так. Кластерні вузли залежать від кворуму для узгодженої поведінки /etc/pve. Якщо ви поза кворумом,
деякі операції управління і скрипти можуть падати. Поверніть кворум спершу, якщо можливо.

10) Чи можна «примусити» dpkg ігнорувати невдалі скрипти?

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

Висновок: наступні кроки, що справді допомагають

«dpkg was interrupted» — не привід перевстановлювати Proxmox. Це привід уповільнитися й відновити стан, як доросла людина:
перевірте, що dpkg не працює активно, переконайтеся, що система може писати на диск, перевірте репозиторії на узгодженість, потім відтворіть
конфігурацію і виправте конкретний скрипт або сервіс, що впав.

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

1. Запустіть швидку діагностику: процеси → стан диску/монтування → репозиторії.
2. Відновіть за допомогою dpkg --configure -a, потім apt-get -f install, потім apt full-upgrade.
3. Переконайтеся, що dpkg --audit чистий і сервіси Proxmox активні.
4. Якщо ядро змінилось — заплануйте перезавантаження, не робіть цього навмання.
5. Після відновлення виправте корінь проблеми: розмір диску, чистота репозиторіїв, вікна обслуговування і OOB-доступ.