Обновление Proxmox VE 8.4 → 9 без переустановки

Раньше я бы поднял чистую систему на новом ssd и восстановил все ВМ и контейнеры из бэкапов. Но из-за их текущей стоимости обновлял домашний сервер с Proxmox VE 8.4.19 на 9.x через apt dist-upgrade, без чистой установки. Все ВМ и LXC-контейнеры выжили, данные не пострадали, но без пары приключений с загрузчиком не обошлось. Описал что делать и на что обратить внимание, если решитесь на то же самое.

Перед стартом

Официальный путь обновления — bookworm → trixie через apt, поверх работающей системы. Proxmox даёт для этого утилиту-чеклист:

pve8to9 --full

Она проверяет пакеты, ядро, конфигурацию хранилищ, bootloader и кучу мелочей. Мой запуск показал:

• 1 FAIL — установлен пакет systemd-boot, который может конфликтовать с обновлением GRUB;
• 2 WARN — не установлен grub-efi-amd64 (мета-пакет), и меньше 10GB свободного места на root;
• пара NOTICE про LVM autoactivation.

Главное, не запускать dist-upgrade, пока pve8to9 --full не покажет FAILURES: 0.

Разбираемся с bootloader до апгрейда

Самая частая проблема при переходе на PVE 9 — конфликт systemd-boot и GRUB. Прежде чем что-то удалять, нужно понять, чем реально грузится сервер:

efibootmgr -v
mount | grep -i efi
dpkg -l | grep -Ei 'systemd-boot|grub'

В моём случае efibootmgr показывал текущую загрузку через \EFI\BOOT\BOOTX64.EFI — это generic fallback-путь. Смонтировав ESP-раздел вручную (mount /dev/sdX2 /mnt) и сравнив размеры файлов, выяснилось: и в EFI/BOOT/, и в EFI/PROXMOX/ лежит один и тот же GRUB/shim, просто скопированный в fallback при установке. Папки EFI/systemd/ на разделе не было вообще — то есть пакет systemd-boot был мёртвым хвостом, никак не участвующим в реальной загрузке.

Только после такой проверки я сделал:

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

и сделал контрольную перезагрузку прямо на PVE 8 — чтобы не мешать в один клубок возможные проблемы бутлоадера и последствия самого dist-upgrade.

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

Перед тем как трогать загрузчик сделал:

tar czf /root/efi-backup.tar.gz -C /mnt/efi-check .      # файлы ESP-раздела
dd if=/dev/sdX2 of=/root/sdX2-efi.img bs=4M               # побайтовый образ ESP
efibootmgr -v > /root/efibootmgr-before.txt               # снимок NVRAM
lvcreate -L4G -s -n root-snap-before-boot-fix /dev/pve/root   # LVM-снапшот root

Само удаление systemd-boot прошло гладко, но эти бэкапы очень пригодились позже — уже после самого dist-upgrade.

Сам апгрейд

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
apt update
apt install tmux    # чтобы обрыв SSH не убил апгрейд
tmux new -s upgrade
apt dist-upgrade

663 пакета: апгрейды, ~170 новых (новое ядро, FRR, контейнерный сетевой стек aardvark-dns/netavark, новый мобильный интерфейс), 58 удаляемых (пересборка библиотек под 64-битный time_t).

По ходу апгрейда пару раз всплывали диалоги про изменённые конфиги (journald.conf, lvm.conf) — прежде чем отвечать Y/N, каждый раз смотрел diff (D в диалоге dpkg), чтобы не потерять осознанно выставленные настройки.

Неожиданность: сервер не загрузился

После reboot — тишина, пинга нет. Подключил монитор: BIOS зацикленно возвращается сам в себя. Через F11 выбрал загрузку с диска руками — мелькнуло «Welcome to GRUB» и снова откат в BIOS. То есть GRUB стартовал, но падал ещё до меню.

Причина: grub-install при установке grub-efi-amd64 (ещё на PVE 8) обновил файлы в /EFI/proxmox/, но не тронул fallback-путь /EFI/BOOT/ — там остались файлы почти двухлетней давности, несовместимые с новым grub.cfg, который сгенерировал апгрейд.

Восстановление через chroot с Live-USB

1. Загрузка с Debian Live в UEFI-режиме.
2. Активация LVM и монтирование:

vgscan; vgchange -ay
mount /dev/mapper/pve-root /mnt/pve-root
mount /dev/sdX2 /mnt/pve-root/boot/efi
mount --bind /dev /mnt/pve-root/dev
mount --bind /proc /mnt/pve-root/proc
mount --bind /sys /mnt/pve-root/sys
mount --bind /run /mnt/pve-root/run
chroot /mnt/pve-root /bin/bash

3. Внутри chroot — переустановка GRUB дважды: сначала стандартно, потом с флагом --removable, чтобы синхронизировать оба пути:

mount -t efivarfs efivarfs /sys/firmware/efi/efivars   # без этого NVRAM не обновится
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=proxmox --recheck /dev/sdX
update-grub
grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable --recheck /dev/sdX

После этого перезагрузка. Ядро 7.0.14-3-pve поднялось с первого раза, все ВМ и контейнеры запустились.

Хвосты после апгрейда

• Enterprise-репозиторий переоткрылся сам. PVE 9 добавляет pve-enterprise.sources в новом DEB822-формате параллельно со старым .list-файлом — если нет подписки, апдейт будет падать с 401, пока не пропишете Enabled: no в .sources-файле (комментирование старого .list тут не поможет).
• LVM-снапшот root переполнился. 4GB, которые я выделил под снапшот перед фиксом bootloader’а, не выдержали объём изменений за весь dist-upgrade — снапшот «лопнул» (invalidated) и начал сыпать Buffer I/O error в dmesg. Удалил снапшот:

lvremove /dev/pve/root-snap-before-boot-fix

• apt autoremove --purge подчистил старые ядра и build-зависимости.

Чеклист, если будете повторять

1. pve8to9 --full → чинить всё до FAILURES: 0.
2. Разобраться, что физически грузит сервер (efibootmgr -v + ручной осмотр ESP), прежде чем удалять systemd-boot.
3. Сделать бэкап ESP-раздела (файлы + dd-образ) и NVRAM-записей.
4. Сделать LVM-снапшот root — но выделить с запасом (я бы теперь брал не 4, а 8-10GB на весь dist-upgrade).
5. После установки grub-efi-amd64 — сразу проверить и обновить оба пути: /EFI/<id>/ и /EFI/BOOT/ (флаг --removable), и сделать контрольный ребут ещё на старой версии.
6. После апгрейда — проверить /etc/apt/sources.list.d/*.sources, не ожил ли enterprise-репозиторий.
7. Удалить временный LVM-снапшот сразу после подтверждения, что всё стабильно.

По итогу — апгрейд полностью рабочий путь, но именно с bootloader’ом на UEFI-системах стоит перестраховаться заранее — это единственное место, где обновление реально может оставить сервер без загрузки.