Как я безопасно обновил Proxmox VE 7.1 до 9.2: пошаговое руководство

Поэтапное обновление Proxmox VE 7.1 → 7.4 → 8.4 → 9.2 с предварительным резервным копированием VM.

В этой статье я описываю реальное обновление одиночного узла Proxmox VE: с pve-manager 7.1-7 и Debian 11 Bullseye до pve-manager 9.2.11 и Debian 13 Trixie.

Я не перепрыгивал через основные версии. Маршрут был таким:

PVE 7.1 → последняя PVE 7.4 → последняя PVE 8.4 → PVE 9.2

Это не универсальный набор команд для бездумного копирования. В статье я показываю, почему перед каждым шагом проверял пакеты, загрузчик, хранилища и виртуальные машины, а также поясняю ответы на вопросы установщика именно для моей конфигурации.


Важно: большое обновление гипервизора всегда может закончиться потерей доступа к узлу или необходимостью восстановления. Наличие бэкапа VM/CT не отменяет резервную копию конфигурации хоста, физическую или удалённую консоль и заранее подготовленное окно простоя.

1. Что было в начале и что получилось в конце​

Исходная система была давно не обновлявшимся одиночным сервером:

• Proxmox VE: 7.1-7;
• Debian: 11 (bullseye);
• запущенное ядро: 5.13.19-2-pve;
• кластер отсутствовал;
• корневая файловая система: ext4 на /dev/mapper/pve-root;
• хранилища: локальный каталог local и LVM-thin local-lvm;
• загрузка: Legacy BIOS с GRUB, не UEFI;
• ZFS-пул отсутствовал;
• гиперконвергентный Ceph отсутствовал;
• LXC-контейнеров не было;
• на узле находились пять QEMU/KVM-машин;
• репозиторий Proxmox: pve-no-subscription.

Границы применимости: это сценарий одиночного узла без Corosync/HA, ZFS-пула, Ceph-хранилища, LXC, сторонних DKMS-модулей, GPU/HBA passthrough и SAN/multipath. Для любой из этих технологий к описанным проверкам нужно добавить профильный раздел официального руководства. Особенно нельзя переносить мои ответы по lvm.conf на узел с SAN или пользовательскими LVM-фильтрами.

Финальное состояние после обновления и очистки:


Операционная система стала Debian 13 Trixie, все хранилища остались активными, проверка pve8to9 --full завершилась без предупреждений и ошибок, а все виртуальные машины загрузились штатно.

2. Почему я не обновлял 7.1 сразу до 9.2​

Proxmox VE тесно связан с базовой версией Debian:

• PVE 7 работает на Debian 11 Bullseye;
• PVE 8 работает на Debian 12 Bookworm;
• PVE 9 работает на Debian 13 Trixie.

Поэтому переход на две основные версии за один запуск APT был бы неподдерживаемым и слишком рискованным. Я разбил работу на самостоятельные этапы и после каждого этапа получал полностью рабочую промежуточную систему:

1. обновил PVE 7.1 до последнего состояния ветки 7.4;
2. загрузился в рекомендованное для перехода ядро 5.15;
3. запустил pve7to8 --full и добился нулевого числа ошибок;
4. обновил Bullseye/PVE 7 до Bookworm/PVE 8;
5. загрузился в ядро PVE 8 версии 6.8 и повторил проверки;
6. подготовил PVE 8 к переходу через pve8to9 --full;
7. обновил Bookworm/PVE 8 до Trixie/PVE 9;
8. загрузился в ядро 7.0 и только после проверки VM занялся очисткой.

Главный принцип: после смены основной версии я не продолжал следующий этап, пока сервер не загружался в новое ядро, dpkg --audit не был пустым, системные службы не были исправны, а хранилища не отображались как active.

3. Что я подготовил до первого изменения​

3.1. Резервные копии виртуальных машин​

Все VM я заранее скопировал на отдельный Proxmox Backup Server. Важно, что PBS находился вне обновляемого системного диска. Локальный бэкап на том же физическом сервере не защищает от повреждения диска, таблицы разделов, LVM или ошибки загрузчика.

Я убедился, что задачи резервного копирования завершились успешно и что в PBS видны актуальные снимки. Для действительно критичных машин желательно дополнительно проверить восстановление хотя бы одной VM в изолированной среде: существование файла бэкапа ещё не доказывает возможность восстановления.

Перед каждым переходом основной версии я остановил все гостевые системы:


В моём случае вывод qm list показывал пять остановленных VM, а pct list был пустым. Работающий гость не всегда технически блокирует обновление, но на одиночном узле он увеличивает риск повреждения данных при неожиданной перезагрузке и усложняет диагностику.

3.2. Отдельная копия конфигурации хоста​

Бэкап VM не содержит всю конфигурацию самого гипервизора. Поэтому отдельно я сохранил как минимум:

• /etc/pve — конфигурации VM, хранилищ, пользователей, заданий и самого узла;
• /etc/network/interfaces — сетевые мосты и адреса;
• /etc/hosts и /etc/hostname;
• /etc/apt/sources.list и /etc/apt/sources.list.d;
• /etc/default/grub и связанные настройки загрузчика;
• /etc/lvm, если LVM настраивался вручную;
• сведения о дисках, разделах, LVM и загрузочном режиме.

Для копии источников пакетов я использовал отдельный каталог с датой:


Примечание: копию каталога /etc/pve лучше делать штатным архивированием с сохранением прав и отдельно от VM-бэкапов. Если узел перестанет загружаться, эти файлы сильно ускорят ручное восстановление сети, хранилищ и конфигураций гостей.

3.3. Доступ к серверу на случай потери сети​

Обновление меняет ядро, systemd, OpenSSH, сетевые библиотеки, GRUB и множество базовых пакетов. Поэтому одной SSH-сессии недостаточно. До начала работ я предусмотрел доступ через физическую консоль, IPMI/iKVM или другой независимый канал.

Во время обновления я не закрывал текущую SSH-сессию. Если установщик перезапускает sshd, существующее соединение обычно сохраняется, но это не заменяет аварийную консоль.

4. Первичная инвентаризация узла​

Сначала я не менял ничего, а собрал фактическое состояние системы:


Ключевые строки исходного pveversion -v:


Операционная система:

4.1. Сообщение pvecm status не было ошибкой узла​

Команда вернула:


Для одиночного сервера это ожидаемый результат. pvecm status проверяет состояние кластера Corosync, а кластер на этом узле никогда не создавался. Отсутствие /etc/pve/corosync.conf в такой конфигурации не требовало «исправления» и тем более создания фиктивного cluster-конфига.

4.2. Проверка хранилищ и свободного места​

Исходно оба хранилища были активны:


На корневом томе было около 35 ГБ свободного места:


findmnt показал ext4 на LVM:


Отдельный /boot не был смонтирован: файлы ядра и initramfs находились в каталоге /boot корневой файловой системы. Это важно при оценке свободного места: отдельный маленький boot-раздел мог бы переполниться от нескольких старых ядер, но в моей схеме такого раздела не было.

4.3. Ceph-пакеты не означали наличие Ceph-кластера​

Команда показала клиент Ceph Octopus:


Однако в pvesm status не было Ceph-хранилищ, а последующие штатные проверки писали no hyper-converged ceph setup detected. Следовательно, отдельная процедура обновления Ceph-кластера здесь не требовалась. Наличие ceph-fuse или других клиентских библиотек само по себе не делает узел участником Ceph.

4.4. Почему ошибка proxmox-boot-tool была ожидаемой​

Я проверил режим загрузки:


Результат:


А proxmox-boot-tool status ответил:


Это не означало поломку загрузчика. Узел стартовал в Legacy BIOS через обычный GRUB, а proxmox-boot-tool не управлял EFI System Partition. В дальнейшем успех загрузки я проверял по файлам ядра, содержимому /boot/grub/grub.cfg и сообщению об установке GRUB на системный диск.

4.5. Что ещё было важно в исходной диагностике​

• apt-mark showhold не показал удерживаемых пакетов;
• dpkg --audit был пустым — незавершённых установок не было;
• zpool status -x ничего не вывел — ZFS-пул отсутствовал;
• места на корневом томе хватало для одновременного хранения старых и новых ядер;
• источники APT указывали только на Bullseye, но был включён недоступный без подписки pve-enterprise.

5. Этап первый: обновление PVE 7.1 до последней PVE 7.4​

Сначала я остался в рамках Debian 11 Bullseye и довёл установленную ветку PVE 7 до финального состояния. Именно такую систему затем должен проверять pve7to8.

5.1. Переключение с enterprise на pve-no-subscription​

Исходно присутствовал репозиторий:


Подписки на узле не было, поэтому enterprise-репозиторий я отключил, сохранив файл для истории, и добавил официальный публичный репозиторий:


Затем проверил все активные строки:


Почему я не оставил оба репозитория: смешивать pve-enterprise и pve-no-subscription без причины не нужно. Без действующей подписки enterprise даёт ошибку авторизации, а дублирующие источники усложняют понимание того, откуда пришёл пакет.

5.2. Обновление индексов и обязательная симуляция​

Симуляция показала примерно следующий итог:


Единственным удаляемым служебным пакетом был старый pve-kernel-helper, но одновременно устанавливался его актуальный преемник proxmox-kernel-helper. Метапакет proxmox-ve обновлялся и не удалялся.

Перед реальным запуском я проверил именно эти признаки:

• proxmox-ve остаётся установленным;
• pve-manager обновляется;
• устанавливается новое ядро PVE;
• не удаляются QEMU, LVM-thin, GRUB и сетевые пакеты, необходимые этому узлу;
• список удалений объясним заменой пакетов, а не конфликтом репозиториев.

После этого запустил реальное обновление:

5.3. Контроль до перезагрузки​

После завершения установки версия менеджера уже была 7.4, но работало старое ядро — это нормальное промежуточное состояние:


Пакеты нового ядра присутствовали:


Я отдельно убедился, что файлы ядра и initramfs существуют:


Фактический результат:


Также проверил GRUB:


В конфигурации присутствовали строки загрузки нового ядра и initrd. Только после этого я перезагрузил узел:

5.4. Проверка PVE 7.4 после перезагрузки​

Новое ядро действительно стало запущенным:


Гости были остановлены, оба хранилища оставались активными, повреждённых пакетов и failed units не было. Главный итог штатной проверки:


Контрольная точка № 1 пройдена: система работала на последней PVE 7.4 и подходящем ядре 5.15, а pve7to8 --full не нашёл ни предупреждений, ни ошибок.

6. Этап второй: переход с PVE 7.4/Bullseye на PVE 8.4/Bookworm​

Этот шаг одновременно обновлял Proxmox VE 7 до Proxmox VE 8 и Debian 11 до Debian 12. Поэтому я ещё раз убедился, что VM остановлены, PBS-бэкапы доступны, а проверка pve7to8 --full чистая.

6.1. Повторная копия репозиториев​

Перед заменой Bullseye на Bookworm я сделал отдельную точку возврата только для APT-конфигурации:


Это не заменяет бэкап сервера. Такая копия нужна, чтобы быстро сравнить старые и новые источники, если apt update покажет смешение релизов или дубль репозитория.

6.2. Репозитории Debian 12 Bookworm и PVE 8​

Для Debian я записал:


Для Proxmox VE:


Компонент non-free-firmware появился в Debian 12 как отдельный раздел. Позже именно из него установился пакет микрокода процессора.

После редактирования я просмотрел все найденные строки и убедился, что Bullseye остался только в архивных файлах с суффиксами .disabled или .dpkg-dist. APT их не считает активными источниками:


APT показал кандидатов:


Если после смены источников APT предлагает пакет из Bullseye и одновременно из Bookworm, продолжать нельзя. Сначала нужно найти старую активную строку в /etc/apt/sources.list.d, сторонний репозиторий или неверный pinning.

6.3. Симуляция перехода на PVE 8​

Сначала я снова запустил только расчёт транзакции и одновременно сохранил его полный вывод:


В длинном выводе я проверял не каждую библиотеку, а критичные условия:

• кандидат proxmox-ve — версия 8.4, метапакет не удаляется;
• pve-manager, qemu-server и пакеты хранилищ обновляются;
• устанавливается ядро PVE 8 серии 6.8;
• нет неожиданного удаления сетевого стека, GRUB или пакетов LVM;
• все пакеты приходят из Bookworm и официального Proxmox-репозитория.

После проверки выполнил:

7. Как я отвечал на вопросы установщика при переходе на PVE 8​

Большое обновление не прошло полностью автоматически. Именно эти окна чаще всего вызывают сомнения, поэтому ниже — не только выбранные ответы, но и логика.

7.1. Экран apt-listchanges с длинным текстом NEWS​

В терминале открылся просмотр изменений пакетов, например adduser. Внизу экрана стояло двоеточие, а установка выглядела остановившейся.

Это был пейджер, а не зависание. Я прочитал важные изменения и нажал:


После выхода установка продолжилась.

7.2. Файл /etc/issue — я выбрал N​

Установщик спросил:


Я нажал Enter, то есть оставил N — текущую версию файла.

/etc/issue содержит локальный баннер входа и не влияет на загрузку ядра, сеть, LVM или работу VM. На PVE он нередко отличается от шаблона Debian. Сохранить действующий вариант в этой ситуации безопасно.

7.3. Автоматически перезапускать службы после обновления libc6​

Появился диалог:

Restart services during package upgrades without asking?

Нажмите, чтобы развернуть...

Смысл вопроса: после замены libc, libpam или libssl запущенные процессы продолжают использовать старые библиотеки. Их желательно перезапустить, но рестарт отдельных сервисов может кратковременно прервать обслуживание.

На одиночном узле в запланированном окне обслуживания я разрешил штатный перезапуск необходимых служб. Следующее окно предложило список:


Я оставил его без изменений и подтвердил. Текущая SSH-сессия при штатном рестарте sshd обычно не закрывается, однако именно поэтому до обновления нужен независимый консольный доступ.

7.4. Файл /etc/lvm/lvm.conf — в этой конфигурации я выбрал Y​

Запрос выглядел так:


На моём узле был стандартный локальный LVM/LVM-thin без пользовательских фильтров для SAN, multipath, iSCSI или необычных устройств. Поэтому я выбрал Y — установил актуальную версию сопровождающего пакета. Скрипты Proxmox затем добавили требуемый global_filter.

Этот ответ нельзя механически повторять на любом сервере. Если в lvm.conf есть собственные filter, global_filter, устройства SAN, multipath, кластерный LVM или другое ручное изменение, сначала нужно нажать D, сохранить различия и перенести нужные параметры в новую версию. Потеря LVM-фильтра может привести к обнаружению нежелательных устройств или проблемам с томами.

7.5. Удалённый pve-enterprise.list — я выбрал N​

Установщик увидел, что файл из пакета ранее был удалён:


Подписки не было, и уже использовался pve-no-subscription, поэтому я оставил файл удалённым: N или просто Enter.

Если бы я выбрал Y, enterprise-репозиторий вернулся бы, а apt update снова начал бы сообщать об отсутствии подписки.

7.6. Универсальное правило для conffile-вопросов​

Обозначения dpkg:

• Y или I — заменить текущий файл версией сопровождающего пакета;
• N или O — сохранить установленный сейчас файл;
• D — показать различия;
• Z — открыть shell для дополнительного исследования.

Для /etc/issue и намеренно удалённого enterprise-репозитория выбор был очевиден. Для сети, SSH, GRUB, LVM, PAM, хранилищ и других критичных конфигураций правильное действие — сначала D, а не угадывание по чужой инструкции.

8. Проверка PVE 8 до первой перезагрузки​

После завершения APT новая пользовательская часть уже была установлена, но ядро оставалось старым:


Это ожидаемо: ядро не меняется у работающей системы без перезагрузки. Я проверил:


В журнале установки GRUB также было успешное завершение для платформы i386-pc и системного диска /dev/sda. Это согласовывалось с ранее установленным режимом Legacy BIOS.

До перезагрузки pve7to8 показывал два ожидаемых предупреждения:

• запущено старое ядро 5.15, хотя новое 6.8 уже установлено;
• LXCFS пока работает с FUSE2, потому что процесс запущен со старого окружения.

Ошибок FAILURES не было. Оба предупреждения должны исчезнуть после загрузки нового ядра и запуска новых служб.

Я перезагрузил сервер:

8.1. Проверка после загрузки PVE 8​

Результат:


Штатный чекер завершился чисто:


Контрольная точка № 2 пройдена: сервер работал на Debian 12, PVE 8.4 и ядре 6.8. Старые ядра 5.x я пока не удалял: до полного завершения перехода они оставались дополнительным вариантом загрузки.

9. Подготовка PVE 8.4 к обновлению до PVE 9​

Перед следующим изменением репозиториев я снова выполнил полную штатную проверку:


Проверка обнаружила одно исправимое предупреждение: для Intel CPU отсутствовал пакет intel-microcode. Поскольку non-free-firmware уже присутствовал в Bookworm-репозиториях, я установил его обычным способом:


Вместе с микрокодом установился вспомогательный iucode-tool. Повторная проверка показала:


Новый микрокод гарантированно применяется после перезагрузки. В нашем случае следующая перезагрузка всё равно входила в план перехода на ядро PVE 9.

9.1. NOTICE об autoactivation на local-lvm​

Чекер сообщил:


И предложил команду:


Я её не запускал. Сам чекер уточнил, что все затронутые тома находятся на локальном хранилище, где это обычно не вызывает проблем. Это был NOTICE, а не WARN и не FAIL. Менять активацию существующих томов непосредственно перед крупным обновлением без практической необходимости было бы лишним вмешательством.

9.2. Отключение audit-сокета на время перехода​

Перед большим обновлением до PVE 9 я применил рекомендацию руководства, чтобы системный журнал не переполнялся потоком audit-сообщений во время замены systemd и связанных компонентов:


Это не удаляет журналы и не отключает обычный systemd-journal. Команда выключает приём audit-сообщений через конкретный сокет. Если на сервере развёрнут обязательный аудит по требованиям безопасности, такой шаг сначала нужно согласовать со своей политикой журналирования.

10. Этап третий: репозитории Debian 13 Trixie и PVE 9​

Для PVE 9 я перешёл на современный формат Deb822 с расширением .sources. Старые активные строки Bookworm я закомментировал или отключил, а не оставил рядом с Trixie.

10.1. Debian 13 в /etc/apt/sources.list.d/debian.sources​

10.2. PVE 9 no-subscription в /etc/apt/sources.list.d/proxmox.sources​

После этого я проверил все источники, включая Deb822-поля:


Кандидаты были правильными:

10.3. Симуляция крупной транзакции PVE 9​

Итог был внушительным:


Большой список удаляемых пакетов на переходе Debian 12 → 13 сам по себе не означает катастрофу. Debian 13 переводит многие библиотеки на ABI с суффиксом t64. В симуляции старые библиотеки удалялись вместе с установкой их новых замен, например:

• libarchive13 → libarchive13t64;
• libcurl4 → libcurl4t64;
• libssl3 → libssl3t64;
• libgnutls30 → libgnutls30t64;
• libzfs4linux → libzfs7linux;
• Python 3.11 → Python 3.13;
• Perl 5.36 → Perl 5.40.

Ключевая проверка была иной: proxmox-ve не удалялся, а обновлялся до 9.2; pve-manager обновлялся; устанавливались proxmox-default-kernel, ядро 7.0.14-14-pve и остальные пакеты PVE 9.

Стоп-сигнал: если симуляция предлагает удалить proxmox-ve без установки его новой версии, удалить pve-manager либо оставить сотни пакетов not upgraded, реальный dist-upgrade запускать нельзя. Обычно это означает неправильные или смешанные репозитории.

После проверки выполнил:

11. Вопросы установщика при переходе на PVE 9​

На этом этапе снова появились интерактивные экраны. Я не запускал обновление в фоне и не отключал вопросы DEBIAN_FRONTEND=noninteractive: при междистрибутивном переходе безопаснее видеть конфликтующие конфигурационные файлы.

11.1. Новости OpenSSH 10 — это не ошибка​

apt-listchanges показал большой текст об OpenSSH 9.8, 9.9 и 10.0. Среди значимых изменений были удаление DSA, изменение набора Diffie-Hellman KEX по умолчанию и более строгая обработка некоторых директив Match.

Я проверил, что не использую старые DSA-ключи и экзотические пользовательские KexAlgorithms/Match exec, после чего вышел из просмотрщика клавишей:


Это только закрыло NEWS и продолжило установку. Нажатие q не отменяет обновление OpenSSH.

Для старой инфраструктуры: если к PVE подключаются очень старые SSH-клиенты или используются вручную заданные алгоритмы, совместимость нужно проверить до обновления. Не следует возвращать слабые алгоритмы глобально без необходимости.

11.2. /etc/issue — снова N​

Запрос был тем же:


Я снова нажал Enter и сохранил действующий файл.

11.3. /etc/lvm/lvm.conf — снова Y, но только после оценки конфигурации​

Узел по-прежнему использовал стандартный локальный local-lvm без пользовательских LVM-фильтров и внешнего SAN. Поэтому я установил новую версию сопровождающего пакета ответом Y.

Для другого сервера этот выбор может быть неверным. Если файл изменён администратором, правильная последовательность такая:

1. нажать D и изучить diff;
2. отдельно сохранить текущую версию;
3. понять назначение каждой пользовательской строки;
4. принять новую версию и вернуть нужные параметры либо оставить старую и вручную перенести обязательные изменения нового релиза;
5. после установки проверить pvs, vgs, lvs и pvesm status.

11.4. Что делать, если снова появляется pve-enterprise.list​

Для узла без подписки я сохранял enterprise-файл отключённым: N. После завершения обновления обязательно проверил, что активен только Trixie pve-no-subscription.

11.5. Почему я не давал один ответ на все остальные файлы​

Для неизвестного изменённого файла выбор по умолчанию не считается автоматически правильным. Особенно опасны:

• /etc/network/interfaces — можно потерять сетевой доступ;
• /etc/ssh/sshd_config — можно потерять SSH;
• /etc/default/grub — можно изменить параметры загрузки или IOMMU;
• /etc/lvm/lvm.conf — можно повлиять на обнаружение томов;
• конфигурации PAM, multipath, NFS, iSCSI и сторонних драйверов.

В таких окнах я сначала использую D. Если различия неочевидны, лучше приостановить решение в shell через Z, чем продолжать наугад.

12. PVE 9 установлен, но перезагрузка ещё не выполнена​

После завершения APT я выполнил:


Пакеты уже были новыми, а запущенное ядро — ещё от PVE 8:


Новое ядро действительно находилось в /boot:


В /boot/grub/grub.cfg присутствовали обычная и recovery-записи для 7.0.14-14-pve. dpkg --audit ничего не вывел, то есть пакетная транзакция завершилась.

12.1. Почему pve8to9 показывал два предупреждения​

До перезагрузки итог выглядел так:


Первое предупреждение было ожидаемым:


Второе было связано с NTP: после замены пакета chrony.service отображался как failed. Это не затрагивало диски, сеть управления, хранилища или создание initramfs, а пакетная система была целой. Новое ядро и GRUB были проверены, поэтому плановая перезагрузка была обоснована. После неё Chrony запустился штатно.

Это не правило «любую failed-службу лечит reboot». Если failed unit относится к сети, LVM, файловой системе, GRUB, multipath, pve-cluster или хранилищу, сначала нужно выяснить причину. В нашем случае единственной failed-службой был сервис синхронизации времени после его пакетной замены.

Я перезагрузил узел:

13. Итоговая проверка после загрузки PVE 9​

После возврата узла в сеть я не запускал VM немедленно, а сначала проверил основу:


Система загрузилась именно в новое ядро и новый Debian:


systemctl --failed вернул:


Chrony был активен, chronyc tracking показывал нормальную синхронизацию, Stratum 3, Leap status: Normal и малое смещение. Оба хранилища были доступны:


Финальный штатный чекер:


Сообщение об autoactivation local-lvm осталось уровнем NOTICE, а не предупреждением. Также чекер упомянул восемь старых файлов истории RRD. Это не влияло на работу VM или хранилищ, поэтому в рамках обновления я ничего с ними не удалял.

Контрольная точка № 3 пройдена: Debian 13, PVE 9.2 и ядро 7.0 работали совместно; пакетная база, службы, время и хранилища были исправны.

14. Запуск виртуальных машин и предупреждение UEFI 2023​

После проверки хоста я запускал VM по одной и контролировал консоль, сеть и прикладные службы. Все машины заработали, но одна Windows 11 VM получила предупреждение:

14.1. Что означало предупреждение​

У VM уже был EFI-диск с более старым набором Microsoft Secure Boot certificates. PVE 9 проверяет наличие нового набора 2023 года и предлагает зачислить его в переменные OVMF. Это не означало повреждение Windows, EFI-диска или виртуального TPM.

Строка:


тоже не была ошибкой. Proxmox обнаружил существующее состояние виртуального TPM и корректно отказался перезаписывать его. Удалять TPM state или создавать новый TPM из-за этой строки нельзя: для Windows с BitLocker это могло бы привести к запросу recovery key или потере доступа при отсутствии ключа восстановления.

14.2. Почему нужно учесть BitLocker​

BitLocker может привязывать автоматическую разблокировку системного тома к измерениям Secure Boot и TPM. Изменение сертификатов EFI меняет доверенное загрузочное состояние. Если заранее не приостановить защиту, при следующем старте Windows может запросить 48-значный recovery key.

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


Я также убедился, что ключ восстановления сохранён вне этой VM. Для каждого тома с включённой защитой приостановил protectors. Для системного тома пример был таким:


Затем Windows была полностью выключена, а не переведена в suspend/hibernate. На хосте я проверил состояние VM:


Ожидаемый ответ:


После этого зачислил новые ключи:


То же действие доступно в веб-интерфейсе: у EFI Disk выбрать Disk Action → Enroll Updated Certificates. Я использовал только один из способов, а не оба подряд.

Проверка конфигурации:


В параметрах EFI-диска должна появиться опция:


Затем:


После успешной загрузки Windows я снова проверил BitLocker и возобновил защиту, если она оставалась приостановленной:


Если защищены другие тома, операции -disable и -enable выполняются для каждого из них. После этой процедуры предупреждение исчезло, а Windows 11 загрузилась штатно.

Никогда не удаляйте EFI Disk или TPM State как «быстрое исправление» этого предупреждения. Сначала сохраните BitLocker recovery key, приостановите protectors, выключите VM и используйте штатный qm enroll-efi-keys.

15. Безопасная очистка после успешного обновления​

Я начал очистку только после выполнения четырёх условий:

• хост несколько раз штатно загрузился в ядро PVE 9;
• все VM были проверены и работали;
• pve8to9 --full показывал WARNINGS: 0 и FAILURES: 0;
• PBS-бэкапы и сохранённые конфигурации всё ещё были доступны.

15.1. Сначала я проверил, какое ядро реально загружено​

Результат:


GRUB_DEFAULT=0 означал загрузку первой записи меню, grub-editenv list не показывал сохранённого старого выбора, вручную закреплённых ядер не было. Текущим оставалось 7.0, а 6.8 сохранялось как рабочее резервное ядро от PVE 8.

Установленные новые пакеты:

15.2. Удаление только старых ядер 5.13 и 5.15​

Я не начинал с autoremove и не удалял пакеты по маске. Сначала явно перечислил только заведомо старые ядра и выполнил симуляцию:


APT предложил удалить ровно пять указанных пакетов:


В списке не было:

• proxmox-ve;
• proxmox-default-kernel;
• текущего ядра 7.0.14-14-pve;
• резервного ядра 6.8.12-43-pve;
• GRUB или пакетов управления загрузкой.

Только после этого выполнил реальное удаление:


После удаления ещё раз проверил текущее ядро, пакетную базу, GRUB и список выбранных ядер:


Оба нужных ядра оставались в GRUB.

15.3. Почему я не использовал proxmox-boot-tool clean для удаления ядер​

proxmox-boot-tool синхронизирует загрузочные разделы и управляет выбором ядер в соответствующих схемах загрузки. Это не замена штатному удалению установленных Debian-пакетов ядра. Пакеты следует удалять через APT, чтобы корректно отработали зависимости, post-removal scripts, генерация initramfs и обновление GRUB.

На этом сервере дополнительно использовался Legacy BIOS, а не EFI-managed boot, поэтому ручной вызов proxmox-boot-tool clean для удаления старых пакетов был бы особенно бессмысленным.

15.4. Симуляция autoremove​

После явного удаления старых ядер я посмотрел, что APT считает больше не нужным:


Он предложил 30 пакетов, оставшихся в основном от Debian 12:


В списке не было пакетов PVE, текущего или резервного ядра, LVM, GRUB и сетевого стека. Поэтому выполнил:


Почему сначала обязательна симуляция: набор автоматически установленных пакетов индивидуален. На другом сервере APT может предложить удалить DKMS-модуль, драйвер HBA/NIC, библиотеку стороннего backup agent или пакет, который администратор когда-то установил как зависимость. В таком случае нужный пакет сначала следует пометить как установленный вручную через apt-mark manual имя-пакета и повторить симуляцию.

15.5. Финальный контроль после очистки​

Фактический итог:


После этой очистки дополнительная перезагрузка не требовалась: работающее ядро 7.0 не удалялось и конфигурация GRUB уже содержала обе нужные записи. Тем не менее при следующем плановом рестарте следует ещё раз убедиться, что узел загружается штатно.

16. Вопросы, которые возникли по ходу обновления​

Зачем нужен бэкап VM, если обновление обычно проходит штатно?​

Потому что обновлялся не один пакет, а две основные версии Proxmox и две версии Debian, включая ядро, QEMU, LVM, systemd, OpenSSH и GRUB. Бэкап на PBS превращает необратимую потерю VM в процедуру восстановления. При этом он не отменяет копию конфигурации хоста и аварийный консольный доступ.

Почему бэкап должен быть на PBS, NFS или внешнем носителе?​

Копия на том же физическом диске зависит от того же контроллера, LVM и загрузочной системы. Если проблема затронет локальное хранилище или сам сервер, такой бэкап может стать недоступен одновременно с VM.

Нормально ли использовать pve-no-subscription?​

Репозиторий доступен без ключа и содержит тот же функционал, но его пакеты проходят менее длительную проверку, чем enterprise. Proxmox рекомендует enterprise для производственных систем. В этой установке подписки не было, поэтому я осознанно использовал pve-no-subscription, не смешивая его с pve-enterprise. Для критичного production-узла следует отдельно оценить подписку и требования к поддержке.

Можно ли было перескочить с PVE 7.1 сразу на PVE 9?​

Нет. Поддерживаемая логика — сначала довести текущую ветку до последнего 7.4, затем выполнить официальный переход 7 → 8, полностью проверить PVE 8 и только потом выполнять переход 8 → 9. Каждый переход меняет базовый Debian и имеет собственный checker и набор известных изменений.

Почему после установки новой версии pveversion показывал старое ядро?​

Пакеты нового ядра уже лежали на диске, но Linux не подменяет запущенное ядро на ходу. До reboot это нормальное состояние. Опасно другое: перезагружаться, не проверив наличие нового vmlinuz, initrd.img и записи GRUB.

Почему apt update было недостаточно?​

apt update только загружает индексы репозиториев. Само обновление пакетов выполняет apt dist-upgrade или эквивалентный apt full-upgrade, который умеет устанавливать и удалять пакеты для разрешения изменившихся зависимостей.

Почему перед реальным dist-upgrade запускался apt-get -s?​

Флаг -s выполняет симуляцию без изменения системы. Именно на этом этапе можно увидеть удаление метапакета proxmox-ve, смешанные репозитории или отсутствие нового ядра и остановиться до причинения вреда.

Опасно ли число «54 packages will be removed» при переходе на Debian 13?​

Число без контекста ничего не решает. В нашем случае большая часть старых библиотек заменялась вариантами t64, а Python, Perl и ZFS переходили на новые ABI. Безопасность подтверждалась парными установками замен, сохранением proxmox-ve и установкой ядра PVE 9. Если замены нет или удаляется метапакет PVE, продолжать нельзя.

Почему для /etc/issue выбиралось N, а для lvm.conf — Y?​

/etc/issue был локальным баннером, который безопасно сохранить. lvm.conf на этом конкретном узле был стандартным и не содержал важных пользовательских фильтров, поэтому была принята актуальная версия пакета. Эти ответы отражают назначение файлов и фактическую конфигурацию, а не универсальное правило «везде нажимать N» или «везде нажимать Y».

Нужно ли беспокоиться из-за перезапуска ssh при обновлении libc?​

Штатный рестарт sshd обычно не разрывает уже установленное соединение, но новая сессия может не открыться из-за ошибки конфигурации или сети. Поэтому я сохранил текущую SSH-сессию и заранее предусмотрел IPMI/локальную консоль.

Почему сообщение об отсутствии corosync.conf было нормальным?​

Потому что узел standalone. Файл /etc/pve/corosync.conf появляется у участника кластера. Создавать его только ради успешного pvecm status нельзя.

Почему установленный ceph-fuse не потребовал обновления Ceph-кластера?​

Потому что Ceph-кластера и Ceph-хранилища на узле не было. Клиентские пакеты могли быть установлены как зависимости или остаться от прежней конфигурации. Решение принималось по фактическому pvesm status и результату штатного checker, а не только по наличию пакета.

Почему proxmox-boot-tool status сообщил об отсутствующем файле?​

Сервер загружался в Legacy BIOS через GRUB. Файл /etc/kernel/proxmox-boot-uuids нужен для систем, где proxmox-boot-tool управляет синхронизацией загрузочных разделов. В нашей схеме отсутствие файла ожидаемо.

Нужно ли было исправлять NOTICE об LVM autoactivation?​

Нет, не в рамках этого обновления. Checker прямо сообщил, что все затронутые тома находятся на локальном storage и обычно не вызывают проблем. Я не стал менять поведение существующих LVM-томов в тот же момент, когда менялись ОС и PVE.

Почему после установки PVE 9 временно упал chrony?​

Служба оказалась в failed-состоянии после замены базовых пакетов, но пакетная транзакция завершилась, сеть и хранилища работали, новое ядро и GRUB были готовы. После штатной перезагрузки Chrony запустился и синхронизировал время. Важно, что я не проигнорировал сообщение, а проверил службу повторно после загрузки.

Почему старое ядро 6.8 оставлено, а 5.13 и 5.15 удалены?​

Ядро 6.8 было последним проверенным рабочим ядром предыдущей основной версии и служило разумным fallback. Ядра 5.x относились к PVE 7, занимали место и уже не были нужны после успешной работы PVE 9. Хранить одно актуальное резервное ядро полезно; хранить все ядра за несколько поколений — нет.

Что означало swtpm_setup: Not overwriting existing state file?​

У VM уже существовало состояние виртуального TPM, и инструмент не стал его перезаписывать. Это защитное поведение, а не повод удалить TPM. Для BitLocker существующий TPM state особенно важен.

Почему перед Enroll Updated Certificates нужно приостановить BitLocker?​

Изменение EFI Secure Boot certificates может изменить TPM measurements. Без приостановки protectors Windows способна перейти в BitLocker Recovery. Я заранее сохранил recovery key, выполнил manage-bde -protectors -disable, обновил сертификаты только на выключенной VM, затем загрузил Windows и вернул защиту.

17. Мой короткий контрольный список для повторения​

18. Что делать, если этап пошёл не по плану​

• APT хочет удалить proxmox-ve: ответить n, не подтверждать транзакцию, проверить codename и все активные репозитории.
• dpkg завершился с ошибкой: не перезагружаться вслепую; сохранить полный вывод, выполнить dpkg --audit, проверить место и конкретный failed package.
• Нет нового ядра или записи GRUB: не перезагружаться; проверить установку kernel package, создание initramfs и вывод update-grub.
• После reboot пропала сеть: использовать IPMI/локальную консоль, проверить имена интерфейсов и /etc/network/interfaces.
• local-lvm не active: не запускать VM; проверить pvs, vgs, lvs, lvm.conf и журнал LVM.
• Windows просит BitLocker recovery key: использовать заранее сохранённый ключ; не удалять EFI/TPM state и не пытаться «починить» VM созданием нового TPM.
• Новое ядро не загружается: выбрать в Advanced options последнее проверенное ядро 6.8, загрузить узел и исследовать initramfs, драйверы и GRUB.
• Хост невозможно быстро восстановить: установить чистый поддерживаемый PVE, восстановить сеть/storage и вернуть VM из PBS. Именно ради этого бэкапы проверяются до обновления.

19. Итог​

Я начал с PVE 7.1-7, Debian 11 и ядра 5.13, а закончил на PVE 9.2.11, Debian 13 и ядре 7.0.14-14. Само выполнение apt dist-upgrade было не самой сложной частью. Безопасность дали контрольные точки:

• внешние бэкапы VM на PBS и отдельная копия конфигурации хоста;
• никаких прыжков через основные версии;
• штатные pve7to8 и pve8to9;
• проверка APT-транзакции до её выполнения;
• осознанные ответы на каждый conffile-вопрос;
• проверка kernel, initrd и GRUB до каждого reboot;
• проверка служб, времени и хранилищ после каждого reboot;
• запуск VM до удаления старых пакетов;
• сохранение ядра 6.8 как fallback;
• двухэтапная очистка: сначала симуляция, потом удаление.

В результате все виртуальные машины сохранились, предупреждение по UEFI 2023 для Windows 11 было устранено штатно, пакетная система осталась чистой, а на корневом разделе сохранилось около 33 ГБ свободного места.

Главный вывод: безопасное обновление Proxmox — это не одна длинная команда, а последовательность маленьких проверяемых переходов. Я продолжал только тогда, когда мог доказать, что предыдущий этап полностью завершён.

Нажмите, чтобы развернуть...

20. Официальные материалы​

• Proxmox VE: Upgrade from 7 to 8
• Proxmox VE: Upgrade from 8 to 9
• Proxmox VE Package Repositories
• Proxmox VE Host Bootloader
• Proxmox VE Administration Guide
• Официальный анонс Proxmox VE 9.2
• Microsoft Learn: manage-bde
• Microsoft Learn: manage-bde protectors

Версии пакетов и номера ядер в этой статье — фактический результат конкретного обновления на 31 августа 2026 года. При повторении позднее номера минорных версий могут отличаться. Маршрут, официальные инструкции и результаты checker нужно сверять заново непосредственно перед работами.