Удаляет ли pve8to9 настоящий загрузчик Proxmox

Вижу знакомую паузу: `pve8to9` пишет удалить `systemd-boot`, а сервер действительно загружается через systemd-boot. Рука к Enter не тянется — и правильно. Я, Семёнов Евгений Сергеевич, в такой ситуации сначала разделяю пакет, файлы на EFI-разделах и механизм их обновления. Ниже покажу, как определить реальную схему загрузки, когда удаление штатно, где находится единственное существенное исключение и как мы прошли этот этап на двух узлах условной службы доставки «Экспресс-Курьер».

Почему удалить пакет — не всегда значит удалить загрузчик

Короткий ответ такой: если актуальный pve8to9 сам требует удалить метапакет systemd-boot, штатная конфигурация Proxmox обычно от этого не перестаёт загружаться. Но я всё равно не выполняю команду вслепую. Исключение прямо названо в официальном руководстве: systemd-boot нельзя механически удалять, если администратор сам устанавливал и настраивал его без proxmox-boot-tool. В такой системе метапакет действительно может быть частью собственного механизма обслуживания загрузчика. Отдельно ставить systemd-boot-efi и systemd-boot-tools руководство не требует — оно лишь оговаривает, что если они нужны, pve8to9 об этом предупредит.

Здесь смешаны три сущности. Первая — запись в базе dpkg о пакете systemd-boot. В Debian 13 Trixie это метапакет с хуками, которые срабатывают при обновлении его самого и других пакетов и устанавливают systemd-boot как загрузчик; он зависит от двух пакетов ниже. Вторая — пакет systemd-boot-efi, содержащий исходный EFI-бинарник, например /usr/lib/systemd/boot/efi/systemd-bootx64.efi, и пакет systemd-boot-tools с командой bootctl. Третья — уже развёрнутые копии на EFI System Partition: /EFI/systemd/systemd-bootx64.efi, записи в /loader/entries/ и каталоги ядер /EFI/proxmox/. Это не один объект и не одна операция.

В Debian 12 Bookworm команда bootctl входила в systemd-boot, поэтому пакет попадал на системы, установленные с ISO Proxmox VE 8.1–8.4. В Trixie инструменты и EFI-бинарники разнесли по отдельным пакетам, а systemd-boot оставили как автоматически действующую интеграцию. Proxmox такая автоматика мешает: его ESP обычно не смонтированы постоянно, а ядра и конфигурацию на них синхронизирует собственный proxmox-boot-tool. Поэтому смысл предупреждения — убрать конкурирующего управляющего, а не отказаться от systemd-boot как загружаемого EFI-кода.

• `systemd-boot` — хуки и автоматическая интеграция Debian.
• `systemd-boot-efi` — EFI-бинарники, из которых можно развернуть загрузчик.
• `systemd-boot-tools` — утилиты, включая `bootctl`.
• `proxmox-boot-tool` — штатный для Proxmox механизм синхронизации зарегистрированных ESP.

Как я определяю реальный путь загрузки

Сначала собираю факты одной пачкой. Наличие пакета ничего не доказывает, существующая запись NVRAM тоже может оказаться старой. Мне нужны режим текущей загрузки, файловая система корня, состояние proxmox-boot-tool, активная UEFI-запись и установленные пакеты.

if test -d /sys/firmware/efi; then echo UEFI; else echo BIOS-Legacy; fi
findmnt -no SOURCE,FSTYPE /
proxmox-boot-tool status
efibootmgr -v
dpkg -l systemd-boot systemd-boot-efi systemd-boot-tools proxmox-kernel-helper grub-efi-amd64 2>/dev/null | grep -E '^(ii|rc)'
ls /etc/kernel/proxmox-boot-uuids
findmnt /boot/efi /efi 2>/dev/null

Последняя команда в типовой схеме с proxmox-boot-tool часто ничего не выводит. Это нормально: Proxmox специально не держит vfat-разделы смонтированными постоянно, а подключает их для синхронизации.

Штатная развилка из документации Host Bootloader проста. Legacy BIOS означает GRUB. При UEFI и корне на ext4 или XFS (в том числе поверх LVM) используется GRUB. При UEFI, ZFS на корне и выключенном Secure Boot установщик Proxmox применяет systemd-boot. При ZFS и включённом Secure Boot используется GRUB через shim. Это правило для стандартной установки, а не закон природы: перенесённые системы и ручные переделки встречаются регулярно.

У proxmox-boot-tool status есть неочевидная формулировка. Строка is configured with: uefi означает ESP, подготовленный для systemd-boot; строка is configured with: grub означает ESP с GRUB. В выводе efibootmgr -v я сопоставляю BootCurrent с конкретной строкой BootNNNN: путь \EFI\systemd\systemd-bootx64.efi указывает на systemd-boot, \EFI\proxmox\grubx64.efi — на GRUB, а \EFI\proxmox\shimx64.efi — на GRUB с Secure Boot. Просто найти где-то Linux Boot Manager недостаточно: запись могла остаться после прошлой конфигурации.

• BIOS Legacy → GRUB; пакет `systemd-boot` загрузке не нужен.
• UEFI + ext4/XFS/LVM → обычно GRUB; проверьте `grub-efi-amd64`.
• UEFI + ZFS root + Secure Boot off → обычно systemd-boot под управлением `proxmox-boot-tool`.
• Ручной systemd-boot без зарегистрированных в Proxmox ESP → нестандартная схема, автоматическое удаление останавливаем.

Безопасная последовательность, которую я выбираю

На ещё не обновлённом PVE 8 с активным systemd-boot под управлением proxmox-boot-tool свежий проверяющий скрипт (если существует /etc/kernel/proxmox-boot-uuids, а proxmox-boot-tool status показывает ESP с uefi) сообщает SKIP: not yet upgraded, systemd-boot still needed for bootctl. Я в этот момент пакет не трогаю: в Bookworm отдельного systemd-boot-tools ещё нет. Если старый скрипт даёт другой совет, сначала довожу PVE 8.4 до последних доступных пакетов и снова запускаю pve8to9 --full. Руководство требует минимум pve-manager 8.4.1, но на практике я ставлю все обновления ветки 8.4.

Когда узел уже обновлён до PVE 9 и pve8to9 выдаёт FAIL systemd-boot meta-package installed, на узле с systemd-boot я сначала явно закрепляю две нужные части. Это моя страховка, а не пункт руководства: метапакет зависит от systemd-boot-efi и systemd-boot-tools, и после его удаления они, установленные как зависимости, становятся кандидатами для apt autoremove. Затем смотрю симуляцию удаления. Если APT собирается удалить proxmox-ve, proxmox-kernel-helper, EFI-пакет или неожиданно большой список — отвечаю «нет» и разбираю зависимости.

apt install systemd-boot-efi systemd-boot-tools
apt-mark manual systemd-boot-efi systemd-boot-tools
apt -s remove systemd-boot
apt remove systemd-boot
proxmox-boot-tool refresh
proxmox-boot-tool status
pve8to9 --full

После apt remove я не перезагружаюсь, пока refresh не завершился без ошибок и каждый ожидаемый UUID не появился в status. Это мой главный практический предохранитель.

Для узла с Legacy BIOS или подтверждённым GRUB отдельные пакеты systemd-boot обычно не нужны: достаточно симуляции, удаления метапакета и повторной проверки. На Legacy BIOS скрипт выдаёт лишь WARN systemd-boot package installed on legacy-boot system is not necessary, а на UEFI без proxmox-boot-uuids — FAIL сразу, ещё до перехода на Trixie, потому что bootctl такому узлу не нужен. А вот если BootCurrent ведёт на systemd-boot, файла /etc/kernel/proxmox-boot-uuids нет и вы знаете, что загрузчик ставили вручную, команду выполнять нельзя только ради зелёного отчёта. Я сначала перевожу такую машину на документированную схему proxmox-boot-tool либо GRUB и лишь затем продолжаю major upgrade.

На GRUB-узлах с UEFI, в том числе с Secure Boot через shim, тот же блок проверки pve8to9 смотрит ещё две вещи, и их я исправляю в том же окне. Если не установлен метапакет grub-efi-amd64, новые версии GRUB не будут записываться в /boot/efi — после обновления firmware продолжит грузить старый бинарник. Если на ESP лежит резервный путь /EFI/BOOT/BOOTX64.efi, а debconf не настроен обновлять его, скрипт предлагает включить это явно:

apt install grub-efi-amd64
echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
apt install --reinstall grub-efi-amd64

На платах, которые игнорируют записи NVRAM и грузятся только по резервному пути, именно этот пункт отличает успешную перезагрузку от старого GRUB, не понимающего новое ядро.

• Проверить резервные копии ВМ и CT, а не только факт завершения задания.
• Получить рабочий доступ через IPMI, iDRAC, iLO или локальную консоль.
• Сохранить вывод `proxmox-boot-tool status`, `efibootmgr -v`, `lsblk -f` и `pveversion -v`.
• Выполнить `apt -s remove systemd-boot` и прочитать весь план APT.
• После удаления обязательно выполнить синхронизацию и повторный `pve8to9 --full`.

Практика: два узла «Экспресс-Курьера» и четыре ESP

«Экспресс-Курьер» — условное имя, параметры проекта обезличены. У службы доставки 33 рабочих места, а девять виртуальных машин (1С, диспетчерская система, сервис трекинга, терминальный сервер, почтовый шлюз и служебные ВМ) и два LXC-контейнера работали на двух одинаковых узлах. На каждом — 64 ГБ RAM, два системных SSD по 480 ГБ в ZFS mirror и по две ESP размером 512 МБ. Перед работами стояла Proxmox VE 8.4 со всеми обновлениями ветки и ядром 6.8.12; целевой результат — актуальная PVE 9.2 на Debian 13 с ядром 7.0. Внешний backup-сервер хранил 1,8 ТБ резервных копий, а восстановление тестовой ВМ мы проверили за 9 минут.

Перед первым окном я увидел ровно тот случай, который пугает администраторов: efibootmgr показывал активный Linux Boot Manager, корень был rpool/ROOT/pve-1, а пакет systemd-boot стоял. Но proxmox-boot-tool видел обе ESP, поэтому это была штатная схема Proxmox.

System currently booted with uefi
19F2-7A61 is configured with: uefi (versions: 6.8.12-15-pve, 6.8.12-14-pve)
19F4-21B0 is configured with: uefi (versions: 6.8.12-15-pve, 6.8.12-14-pve)

В /etc/kernel/cmdline была одна строка root=ZFS=rpool/ROOT/pve-1 boot=zfs, а в /etc/kernel/proxmox-boot-uuids — оба UUID. До перехода на Trixie проверка правильно оставила пакет ради bootctl.

После обновления первого узла до PVE 9 повторный pve8to9 --full уже выдал FAIL по метапакету. Я явно установил systemd-boot-efi и systemd-boot-tools, сделал симуляцию удаления и убедился, что в секции REMOVE указан только systemd-boot. После реального удаления сразу выполнил proxmox-boot-tool refresh. Оба раздела получили новое ядро ветки 7.0 и предыдущее ядро 6.17 как запасное; активная запись NVRAM продолжала вести на \EFI\systemd\systemd-bootx64.efi. То есть управляющий пакет исчез, а используемый загрузчик остался и снова был синхронизирован.

Первый узел обновлялся 24 минуты, его контрольная перезагрузка вместе с POST сервера заняла около 5 минут. Затем мы вернули часть нагрузки, повторили тот же порядок на втором узле и получили примерно такое же время. Все 11 гостевых систем стартовали, диспетчерская и трекинг вернулись в работу до начала утренней смены, ZFS mirror остался ONLINE, обе ESP на каждом сервере отображались в status. Через неделю очередное обновление ядра тоже разошлось на четыре ESP автоматически. Чем всё закончилось? Нулём восстановлений загрузчика и понятной схемой сопровождения вместо пакета, который конкурировал с Proxmox.

• 2 узла и 4 зарегистрированные ESP.
• 9 ВМ, 2 LXC и 33 рабочих места.
• ZFS mirror на двух системных SSD каждого узла.
• 1,8 ТБ проверенных резервных копий.
• Последовательное обновление с переносом нагрузки и независимой консолью.

Где администраторы ломают загрузку

Самая частая ошибка — воспринимать подсказку как просьбу зачистить всё с названием systemd-boot. Удаляют /boot/efi/EFI/systemd, правят NVRAM через efibootmgr -b … -B, стирают /etc/kernel/proxmox-boot-uuids или запускают bootctl remove. Ничего этого pve8to9 не просит. После такой уборки установленное ядро остаётся на ZFS, но firmware уже не знает, чем и откуда его загрузить.

Вторая ошибка — выполнить apt remove, увидеть успешный exit code и сразу перезагрузиться. Успех APT говорит только о состоянии пакетов. Он не подтверждает, что обе ESP доступны, содержат одинаковые ядра и соответствуют загрузочной записи. Ещё хуже запускать следом без чтения apt autoremove: явно нужные systemd-boot-efi и systemd-boot-tools могут считаться автоматическими зависимостями, если их заранее не закрепили.

Есть и тонкий момент. Скрипты метапакета работают с ESP через bootctl и рассчитаны на классическую схему Debian с постоянно смонтированной ESP; именно поэтому ручная схема является исключением, и перед удалением на таком узле я читаю сами maintainer-скрипты в /var/lib/dpkg/info/systemd-boot.*. В штатном Proxmox ESP обычно не смонтированы, а последующий proxmox-boot-tool refresh разворачивает нужное содержимое заново. Отдельный Debian bug №1110177 зафиксировал и обратную проблему: postinst метапакета (версия 257.7-1) падал, когда ESP не смонтирована — а у Proxmox она по умолчанию именно не смонтирована. Предупреждение pve8to9 появилось не из эстетических соображений — два независимых управляющих механизма действительно плохо уживаются.

• Остановитесь, если APT предлагает удалить `proxmox-ve` или `proxmox-kernel-helper`.
• Остановитесь, если systemd-boot используется, но `proxmox-boot-tool status` не видит ни одной ESP.
• Остановитесь, если UUID из `/etc/kernel/proxmox-boot-uuids` не находятся через `blkid`.
• Остановитесь, если ESP постоянно смонтирована и происхождение этой настройки неизвестно.
• Не перезагружайтесь после ошибки `proxmox-boot-tool refresh`.

Финальная проверка перед перезагрузкой

Перед рестартом я хочу получить не ощущение, а доказательства. Проверяю версию платформы и ядра, отсутствие сломанных пакетов, успешную синхронизацию всех ESP и итоговый отчёт. Команду pve8to9 полезно запускать неоднократно: её вывод намеренно меняется до и после перехода на PVE 9.

pveversion -v
uname -r
dpkg --audit
proxmox-boot-tool refresh
proxmox-boot-tool status
efibootmgr -v
pve8to9 --full

Если два системных диска должны независимо загружаться, в status должны присутствовать обе ESP. Одной строки System currently booted with uefi для зеркала недостаточно.

Первую перезагрузку делаю только при открытой независимой консоли. В меню проверяю наличие ожидаемых ядер, после старта — zpool status, сетевые мосты, кластер, хранилища и запуск контрольной ВМ. Проверка загрузки со второго системного диска полезна, но на рабочем сервере я провожу её только в отдельное окно: изменение BootOrder — самостоятельный риск, не обязательная часть удаления метапакета.

На сентябрь 2026 года актуальная ветка — Proxmox VE 9.2, основанная на Debian 13.5 и использующая ядро 7.0 как стабильное по умолчанию. Сам принцип не изменился: Proxmox управляет своими ESP через proxmox-boot-tool, а интеграционный systemd-boot из Trixie ему обычно не нужен. Мой приоритет такой: сначала доказать способ загрузки, затем сохранить отдельные EFI-компоненты, убрать только метапакет, синхронизировать ESP и лишь потом перезагружать. На косметические остатки конфигов можно не тратить окно обслуживания.

• Все зарегистрированные ESP имеют состояние configured и содержат ожидаемые версии ядер.
• `dpkg --audit` ничего не выводит.
• `pve8to9 --full` не оставляет необъяснённых FAIL.
• Доступ через IPMI/iKVM остаётся рабочим до полной проверки узла.
• Резервная копия находится вне обновляемого хоста и проверена восстановлением.

Частые вопросы