Три раза установил Proxmox с ZFS — три раза получил UEFI shell

Хотел собрать один Proxmox-узел на новом железе. По знакомой схеме: ZFS RAID-1 на двух NVMe, корень на пуле, snapshots + send/receive в Proxmox Backup Server. Полтора часа от заказа до боевого контура.

Ушёл день.

Что вышло

Установщик отрабатывает чисто: диски размечаются под GPT, EFI-разделы пишутся на оба NVMe (для зеркала так положено), ZFS-пул собирается, систему ставит в rpool/ROOT/pve-1. Установка завершается. Reboot.

Сервер падает в UEFI Interactive Shell.

Три попытки, три пути:

→ Нативный установщик через netboot.xyz — сетевой автодетект не справился (у сервера два интерфейса в разных VLAN), откатился до старта → qemu-iso из rescue-режима — установщик в QEMU-VM с passthrough дисков, ISO в RAM, VNC на :5900. Установка прошла. Reboot. UEFI shell. → Нативный установщик заново с предзаполненной сетью — установка прошла. Reboot. UEFI shell.

После каждой попытки заходил в UEFI shell, смотрел Mapping table — GPT GUID-ы EFI-разделов менялись от попытки к попытке. Установщик действительно перепрописывал диски.

Где собака зарыта

Загрузка Proxmox устроена по-разному в зависимости от файловой системы корня.

На LVM Proxmox использует GRUB. Установщик кладёт grubx64.efi в два места: путь, на который ставится UEFI NVRAM-запись через efibootmgr — и fallback-путь \EFI\BOOT\BOOTX64.EFI. Этот второй путь любая UEFI-прошивка обязана проверить, если ни одна NVRAM-запись не подошла. Страховка от того, что NVRAM сбросилась, прошивка свежая, диск переставили в другой сервер.

На ZFS Proxmox переключается на systemd-boot — GRUB не умеет надёжно читать ZFS из загрузчика (модуль есть, но это лотерея на разных версиях пула и feature-флагов). Загрузчик systemd-bootx64.efi лежит только в \EFI\systemd\ на каждом ESP. Fallback \EFI\BOOT\BOOTX64.EFI Proxmox для systemd-boot не создаёт. Загрузка зависит исключительно от NVRAM-записи, которую ставит proxmox-boot-tool refresh.

Если конкретный BMC не сохраняет эту NVRAM-запись между холодными ребутами — а на whitebox AMI BIOS дешёвых dedicated-серверов это бывает — fallback бы спас, но fallback не написан.

Картина складывается:

→ На LVM проблема не воспроизводится — fallback подстрахован → На ZFS воспроизводится только если у конкретного BMC проблемы с UEFI-переменными → Документация про это нигде явно не предупреждает

Рецепт страховки (проверю на следующей установке — не поторопись применять без теста)

После того, как однажды войдёшь в Proxmox — копируешь systemd-boot в fallback-путь на каждом ESP:

cp /boot/efi/EFI/systemd/systemd-bootx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
 
# второй ESP — нужно примонтировать
proxmox-boot-tool init /dev/nvme1n1p2
mount /dev/nvme1n1p2 /mnt/esp
cp /mnt/esp/EFI/systemd/systemd-bootx64.efi /mnt/esp/EFI/BOOT/BOOTX64.EFI
umount /mnt/esp

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

«Ремни и подтяжки», как говорится.

→ ZFS-on-root на Proxmox — отличная штука. Снапшоты, send/receive в PBS, компрессия, ARC. Не отказываюсь. → Но на чужом железе с непредсказуемым BMC — после установки руками положить fallback BOOTX64.EFI копию systemd-boot. Минута работы. → Документации провайдеров про эту сцепку UEFI + ZFS + systemd-boot нигде не нашёл. Гэп, не баг — но без него вспоминаешь обычно вечером того дня, когда уже три раза переустановил систему с нуля.

(хотя казалось бы)

День ушёл. Урок остался.