Як виправити помилки оновлення Ubuntu: Повний посібник з усунення несправностей

Система керування пакетами APT в Ubuntu є однією з найнадійніших в екосистемі Linux, але вона не застрахована від збоїв. Коли `apt-get upgrade`, `apt-get dist-upgrade` або `do-release-upgrade` видає помилку, першопричина майже завжди належить до однієї з п’яти категорій: застарілий або пошкоджений індекс пакетів, невирішені ланцюжки залежностей, застарілий файл блокування, залишений аварійно завершеним процесом, недостатньо місця на диску в кореневому розділі або частково налаштований пакет, залишений у несправному стані попередньою перерваною транзакцією.

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

Розуміння того, що насправді відбувається під час оновлення Ubuntu

Перш ніж сліпо виконувати команди, варто зрозуміти внутрішню механіку. Коли ви викликаєте `sudo apt-get upgrade`, APT виконує прохід вирішення залежностей відносно локального кешу пакетів у `/var/lib/apt/lists/`. Якщо цей кеш застарілий, пошкоджений або не синхронізований з налаштованими репозиторіями в `/etc/apt/sources.list` та `/etc/apt/sources.list.d/`, резолвер або повністю завершується з помилкою, або пропонує неузгоджений набір пакетів.

Шар dpkg під APT підтримує власну базу даних стану в `/var/lib/dpkg/`. Якщо попередня інсталяція або оновлення були перервані — через відключення живлення, розрив SSH-сесії або ручне `Ctrl+C` — dpkg може залишити один або кілька пакетів у стані `half-installed` або `triggers-awaiting`. APT не може продовжити роботу, поки стан dpkg не буде чистим.

П’ять першопричин у короткому огляді

Рішення 1: Оновлення індексу пакетів і виконання повного оновлення

Це правильний перший крок у кожному діагностичному робочому процесі. Завжди запускайте `update` перед `upgrade` — вони не є взаємозамінними.

“`bash

sudo apt-get update

sudo apt-get upgrade

“`

Що насправді робить кожна команда:

• `apt-get update` — Завантажує свіжі метадані пакетів з кожного репозиторію, визначеного у вашому `sources.list`. Вона нічого не встановлює. Вона перезаписує файли індексу в `/var/lib/apt/lists/`.
• `apt-get upgrade` — Вирішує та встановлює новіші версії всіх поточно встановлених пакетів. Вона ніколи не видалить встановлений пакет і не встановить новий для задоволення залежності — це навмисне обмеження безпеки.

Якщо `apt-get upgrade` затримується пакетами, які потребують нових залежностей або видалення конфліктуючих, перейдіть до:

“`bash

sudo apt-get dist-upgrade

“`

`dist-upgrade` використовує більш агресивний резолвер, якому дозволено встановлювати нові пакети та видаляти застарілі для задоволення графа залежностей. Це правильний інструмент для оновлень точкових релізів у межах однієї версії Ubuntu (наприклад, з 22.04.1 до 22.04.4).

Критичний нюанс: На виробничих серверах завжди переглядайте план `dist-upgrade` перед підтвердженням. Спочатку запустіть `apt-get dist-upgrade –dry-run`, щоб точно побачити, що буде встановлено, оновлено або видалено без впливу на систему.

Рішення 2: Виправлення зламаних і невиконаних залежностей

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

“`bash

sudo apt-get install -f

“`

Прапор `-f` (`–fix-broken`) вказує APT спробувати виправити зламаний граф залежностей шляхом завантаження та встановлення відсутніх залежностей або видалення пакетів, які не можуть бути задоволені. Після завершення повторно запустіть оновлення.

Коли `-f` недостатньо: Якщо ви вручну встановили пакети `.deb` поза офіційними репозиторіями (поширена практика при встановленні стороннього програмного забезпечення), ці пакети можуть закріплювати залежності до конкретних версій, що конфліктують з версіями репозиторію. Визначте їх за допомогою:

“`bash

apt-cache policy <package_name>

dpkg -l | grep "^ii" | grep -v "^ii lib"

“`

Перевірте версії “Installed” та “Candidate”. Закріплений пакет покаже нижчого кандидата, ніж пропонує репозиторій, або взагалі жодного кандидата. Можливо, вам доведеться видалити конфліктуючий пакет, завершити оновлення, а потім перевстановити сумісну версію.

Рішення 3: Переналаштування частково встановлених пакетів за допомогою dpkg

Якщо попереднє оновлення було перервано, база даних стану dpkg міститиме пакети, позначені як `half-configured` або `half-installed`. APT відмовляється продовжувати, поки вони не будуть вирішені.

“`bash

sudo dpkg –configure -a

“`

Прапор `-a` означає “all” — dpkg спробує запустити скрипти пост-інсталяційного налаштування (`postinst`) для кожного пакету, який був залишений у незавершеному стані. Це часто вирішує такі помилки:

“`

dpkg was interrupted, you must manually run 'sudo dpkg –configure -a' to correct the problem.

“`

Одразу після цього виконайте свіже оновлення індексу та спробу оновлення:

“`bash

sudo apt-get update && sudo apt-get upgrade

“`

Граничний випадок — пошкоджена база даних dpkg: У рідкісних сценаріях сама база даних dpkg стає пошкодженою (найчастіше після збою диска або помилки файлової системи). Симптоми включають `dpkg: error: parsing file '/var/lib/dpkg/status'`. Процедура відновлення передбачає відновлення з резервної копії, яку dpkg автоматично підтримує в `/var/backups/dpkg.status*`. Скопіюйте найновішу резервну копію поверх пошкодженого файлу стану:

“`bash

sudo cp /var/backups/dpkg.status.0 /var/lib/dpkg/status

sudo dpkg –configure -a

“`

Рішення 4: Видалення застарілих файлів блокування

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

“`

E: Could not get lock /var/lib/dpkg/lock-frontend – open (11: Resource temporarily unavailable)

“`

Перед видаленням файлів блокування завжди перевіряйте, що жоден легітимний процес їх не утримує:

“`bash

sudo lsof /var/lib/dpkg/lock-frontend

sudo lsof /var/lib/dpkg/lock

sudo lsof /var/cache/apt/archives/lock

“`

Якщо `lsof` не повертає жодного виводу, блокування є застарілим і його можна безпечно видалити:

“`bash

sudo rm /var/lib/dpkg/lock-frontend

sudo rm /var/lib/dpkg/lock

sudo rm /var/cache/apt/archives/lock

sudo dpkg –configure -a

sudo apt-get update

“`

Попередження: Ніколи не видаляйте файли блокування, поки активно працює інший процес `apt`, `apt-get`, `dpkg` або `unattended-upgrades`. Це призведе до пошкодження бази даних пакетів. Якщо `lsof` показує активний PID, дочекайтеся завершення цього процесу або з’ясуйте, чому він завис, перш ніж вживати заходів.

Рішення 5: Звільнення місця на диску в кореневому розділі

Оновлення Ubuntu — особливо оновлення основних версій — вимагають значного вільного місця на кореневому розділі. Поширеною точкою збою є заповнення `/boot` старими образами ядра, що повністю блокує встановлення нового ядра.

Перевірте поточне використання диска:

“`bash

df -h

“`

Перевірте конкретно, що займає місце в `/boot`:

“`bash

du -sh /boot/*

ls /boot/vmlinuz-*

“`

Систематична процедура відновлення місця:

“`bash

Remove packages installed as dependencies that are no longer needed

sudo apt-get autoremove –purge

Remove cached .deb files from the local package archive

sudo apt-get clean

Remove old kernel images (keeps the two most recent)

sudo apt-get autoremove –purge

“`

Якщо `/boot` все ще заповнений після `autoremove`, визначте та вручну видаліть старі ядра. Спочатку знайдіть поточно запущене ядро, щоб не видалити його:

“`bash

uname -r

“`

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

“`bash

dpkg -l 'linux-image-*' | grep '^ii'

sudo apt-get purge linux-image-X.X.X-XX-generic

“`

Замініть рядок версії на старішу версію ядра — ніколи не ту, що повертає `uname -r`.

Якщо ви використовуєте середовище VPS Хостинг з фіксованим розміром кореневого розділу, цей сценарій є особливо поширеним. Виділення достатнього обсягу диска для вашого VPS з самого початку — або використання окремого розділу `/boot` — повністю запобігає цьому класу збоїв.

Рішення 6: Очищення зайвих пакетів і кешу APT

Накопичений кеш пакетів і осиротілі пакети погіршують як продуктивність системи, так і надійність оновлень.

“`bash

sudo apt-get autoremove

sudo apt-get autoclean

sudo apt-get clean

“`

Різниця між `autoclean` та `clean`:

• `autoclean` видаляє кешовані файли `.deb` лише для пакетів, які більше не можна завантажити з налаштованих репозиторіїв (тобто вони застарілі). Він зберігає кешовані файли для поточно доступних пакетів.
• `clean` видаляє всі кешовані файли `.deb` безумовно, незалежно від того, чи вони ще доступні. Використовуйте це, коли потрібно відновити максимальний обсяг місця на диску.

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

Рішення 7: Ручне вирішення конфліктів конкретних пакетів

Коли `apt-get upgrade` повідомляє про конкретні конфлікти пакетів, а не про загальний збій залежностей, потрібне цільове втручання.

“`bash

sudo apt-get upgrade –fix-missing

“`

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

Щоб видалити та перевстановити конкретний конфліктуючий пакет:

“`bash

sudo apt-get remove –purge <package_name>

sudo apt-get install <package_name>

“`

Використання `–purge` з `remove` видаляє як бінарні файли пакету, так і його конфігураційні файли, що важливо, коли пошкоджений конфігураційний файл є фактичним джерелом конфлікту.

Визначення точного джерела конфлікту: Коли APT повідомляє про конфлікт, повідомлення про помилку зазвичай називає задіяні пакети. Для глибшого аналізу:

“`bash

apt-cache show <package_name>

apt-cache depends <package_name>

apt-cache rdepends <package_name>

“`

`rdepends` (зворотні залежності) показує, які інші встановлені пакети залежать від даного пакету — критична інформація перед видаленням будь-чого.

Рішення 8: Виконання оновлення основної версії за допомогою do-release-upgrade

Оновлення між релізами Ubuntu LTS (наприклад, з 20.04 Focal до 22.04 Jammy або з 22.04 до 24.04 Noble) вимагає спеціального інструменту. Використання лише `apt-get dist-upgrade` для оновлення основної версії не підтримується і призведе до неузгодженої системи.

Правильна процедура:

“`bash

sudo apt-get update

sudo apt-get dist-upgrade

sudo apt-get autoremove

sudo do-release-upgrade

“`

Чому попереднє оновлення `dist-upgrade` важливе: `do-release-upgrade` перевіряє, що ваша поточна система повністю оновлена перед початком переходу версії. Якщо у вас є затримані пакети або невирішені залежності, він відмовиться продовжувати. Попереднє виконання `dist-upgrade` забезпечує чисту базову лінію.

Специфічні міркування для сервера щодо `do-release-upgrade`:

• На безголових серверах, доступних через SSH, завжди запускайте `do-release-upgrade` всередині сесії `tmux` або `screen`. Якщо ваше SSH-з’єднання обривається під час оновлення, процес продовжується у фоновому режимі, а не завершується, що залишило б систему в зламаному проміжному стані.
• Використовуйте прапор `-d` лише при оновленні до версії розробки (ще не стабільної LTS). Для виробничих систем ніколи не використовуйте `-d`.
• Інструмент запропонує вам переглянути зміни у конфігураційних файлах, змінених відносно їхніх значень за замовчуванням. Уважно читайте ці підказки — сліпе прийняття версії супроводжувача може перезаписати власні конфігурації сервера.

“`bash

Start a persistent session before upgrading

tmux new -s upgrade

sudo do-release-upgrade

“`

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

Рішення 9: Виправлення проблем зі сторонніми репозиторіями

Часто ігнорованою причиною помилок оновлення є зламаний або несумісний сторонній PPA (Personal Package Archive) або репозиторій. Коли PPA додається для одного релізу Ubuntu і ви оновлюєтесь до наступного, PPA може не мати пакетів для нового кодового імені релізу, що змушує `apt-get update` видавати помилки на кшталт:

“`

E: The repository 'http://ppa.launchpad.net/…' does not have a Release file.

“`

Перелічіть усі налаштовані репозиторії:

“`bash

ls /etc/apt/sources.list.d/

cat /etc/apt/sources.list

“`

Тимчасово вимкніть проблемні PPA, закоментувавши або видаливши їхні файли `.list` в `/etc/apt/sources.list.d/`, завершіть оновлення системи, а потім повторно увімкніть або замініть їх версіями, сумісними з новим релізом.

“`bash

sudo add-apt-repository –remove ppa:<ppa_name>/<ppa_name>

“`

Рішення 10: Перезавантаження для усунення перешкод на рівні процесів

Певні збої оновлення спричинені станом у пам’яті, а не проблемами на рівні диска — наприклад, запущена служба, що утримує дескриптор файлу бібліотеки, яку APT потребує замінити, або модуль ядра, що конфліктує з нещодавно встановленою версією.

“`bash

sudo reboot

“`

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

“`bash

sudo apt-get update && sudo apt-get upgrade

“`

На віддалених серверах, де перезавантаження несе операційний ризик, використовуйте `needrestart` для визначення служб, що потребують перезапуску, без повного перезавантаження системи:

“`bash

sudo apt-get install needrestart

sudo needrestart

“`

`needrestart` перевіряє запущені процеси та визначає ті, що використовують застарілі спільні бібліотеки, дозволяючи перезапустити лише уражені служби, а не всю систему.

Запобігання помилкам оновлення Ubuntu: операційні найкращі практики

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

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

• Запускайте `sudo apt-get update && sudo apt-get upgrade` за регулярним розкладом — щонайменше щотижня для виробничих систем.
• Відстежуйте місце на диску в `/`, `/boot` та `/var` з порогами сповіщень (85% використання є розумним тригером).
• Перевіряйте сторонні PPA перед кожним циклом оновлення основної версії.
• Завжди запускайте оновлення основних версій всередині `tmux` або `screen` на віддалених системах.
• Зберігайте знімок або резервну копію перед будь-якою операцією `do-release-upgrade`. На Виділеному сервері або VPS це означає створення повного образу диска або знімка файлової системи перед початком оновлення.
• Тестуйте процедури оновлення в тестовому середовищі перед застосуванням до виробництва.
• Використовуйте `unattended-upgrades` лише для патчів безпеки, а не для повних оновлень пакетів, щоб уникнути несподіваних змін залежностей на виробничих системах.

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

Матриця рішень: яке виправлення застосувати першим

FAQ

Чому `apt-get upgrade` залишає деякі пакети як “held back”?

Пакети затримуються, коли їх оновлення вимагало б встановлення нових пакетів або видалення існуючих — дії, які `apt-get upgrade` не дозволено виконувати за задумом. Використовуйте `apt-get dist-upgrade` для вирішення затриманих пакетів, але завжди переглядайте запропоновані зміни за допомогою `–dry-run` спочатку на виробничих системах.

Чи безпечно видаляти файли блокування з `/var/lib/dpkg/`?

Лише якщо жоден процес APT або dpkg активно не працює. Перевірте за допомогою `sudo lsof /var/lib/dpkg/lock-frontend` перед видаленням. Якщо живий процес утримує блокування і ви видалите файл, ви пошкодите базу даних пакетів, що вимагатиме ручного відновлення з резервної копії стану dpkg.

У чому різниця між `apt-get upgrade` та `apt-get dist-upgrade`?

`apt-get upgrade` ніколи не видаляє встановлені пакети та не встановлює нові для вирішення залежностей — він лише оновлює пакети, які можуть бути задоволені без структурних змін. `apt-get dist-upgrade` використовує розумніший резолвер, який може встановлювати нові пакети та видаляти застарілі. Для оновлень точкових релізів і оновлень основних версій `dist-upgrade` є правильним інструментом.

Чому `do-release-upgrade` завершується з помилкою одразу після його запуску?

Найпоширенішою причиною є те, що поточна система має невирішені залежності або затримані пакети. Запустіть `sudo apt-get dist-upgrade` та `sudo apt-get autoremove`, щоб привести систему до повністю узгодженого стану перед викликом `do-release-upgrade`. Також перевірте, що всі сторонні PPA або вимкнені, або сумісні з цільовим релізом.

Скільки вільного місця на диску потрібно для оновлення основної версії Ubuntu?

Як практичний мінімум, вам потрібно щонайменше 2–3 GB вільного місця на кореневому розділі та щонайменше 200–300 MB вільного місця на `/boot`. Фактична вимога варіюється залежно від кількості встановлених пакетів. Запускайте `sudo do-release-upgrade` при системі на рівні або вище цих порогів; якщо місця мало, запустіть `sudo apt-get autoremove –purge && sudo apt-get clean` безпосередньо перед початком оновлення.