Думал на одно, оказалось другое: 4Kn-диски сломали ZFS-загрузку
В утреннем посте написал: три установки Proxmox с ZFS, три раза UEFI shell. Корневая причина якобы в схеме загрузки — systemd-boot не пишет fallback-путь \EFI\BOOT\BOOTX64.EFI, всё зависит от NVRAM, а на whitebox-железе NVRAM может терять записи. Рецепт страховки — скопировать загрузчик в fallback-путь руками.
Хорошая теория. Не моя проблема.
Что было на самом деле
Поддержка провайдера потратила несколько часов на диагностику: тесты разных конфигураций ядра, попытки разных параметров ZFS, разные пути установки. Дошла до уровня глубже, чем я смотрел.
Два диска NVMe Intel P4510 с нативным размером сектора 4 КБ (4Kn). На бумаге — нормально: спецификация UEFI поддерживает 4Kn-загрузку. На практике — конкретная связка PM9 + ZFS + этой BIOS-прошивки не справляется. Установщик пишет диски, ZFS-пул собирается, EFI-разделы создаются. А BIOS при загрузке не может корректно прочитать ESP с 4Kn-диска. Итог — UEFI shell.
Поэтому большинство провайдеров ставит 512e-диски (физически 4 КБ, эмулируют 512 б на логическом уровне) — именно чтобы избежать этого класса багов. P4510 в 4Kn-варианте — старая enterprise-серия, оптимизирована под пиковую производительность, не под универсальную совместимость.
Решение — физическая замена на Micron 9300 Pro с нативным 512 б. Установка проходит чисто, сервер грузится с диска без шаманства.
Где я ошибся
Симптом — да, верно: загрузка падает в UEFI shell, NVRAM-зависимая история. Механизм — придумал свой, более общий: systemd-boot не пишет fallback. Это реальная особенность Proxmox + ZFS на whitebox-железе с непредсказуемым BMC, и рецепт страховки (скопировать BOOTX64.EFI руками) сам по себе полезен. Просто не моя проблема в этот раз.
Честно: я искал на уровне OS + bootloader. Поддержка провайдера пошла на уровень ниже — firmware vs физический формат сектора диска. Это слой, который я не подумал проверить.
Признаю — диагноз был неверный. Полезно: в следующий раз буду смотреть туда раньше.
Что вынес
→ Симптом «UEFI shell на ZFS-инсталле» имеет минимум два разных корня: бутлоадер-уровень (systemd-boot fallback gap) и hardware-уровень (4Kn-диск + капризная BIOS). Обе ловушки реальные.
→ Когда проверка GPT GUID-ов после установки показывает, что диски действительно перепрописываются, но сервер всё равно падает в shell — стоит спросить про формат сектора дисков (nvme id-ns /dev/nvme0n1 покажет 512 vs 4096). Я не спросил.
→ Рецепт cp BOOTX64.EFI остаётся в закладках — общая страховка от другого класса проблем. Двойная страховка лишней не бывает.
→ Хорошая поддержка провайдера — это когда меняют железо, а не дают шаблонный ответ. Несколько часов работы, прозрачный технический ответ, физическая замена дисков. Уважение возвращено.
День ушёл. Урок остался — другой, чем казалось утром.