Подтверждаю, что это исправляет загрузку нашего инстанса Proxmox. @sbraz, у меня проблема появилась после обычного "apt upgrade". Нужно ли делать это при каждом обновлении Proxmox, которое затрагивает grub? Будет ли в будущем более постоянное решение?

@autra Не используй apt upgrade на PVE. Всегда используй apt full-upgrade или apt dist-upgrade, иначе может получиться так, что некоторые пакеты pve обновятся не должным образом.

Если RAID создан с версией 0.90 или 1.0, суперблок находится в конце раздела. Обычно это означает, что BIOS воспринимает ESP на RAID как обычный FAT-раздел. Мы пока не смогли проверить это на всех устройствах, поэтому по этой причине сейчас так не делаем. Какую модель вашей платы, если не секрет? Может быть, у меня есть такая, и я смогу протестировать.

Привет, @autra, я так и не до конца понял, что у тебя произошло. Если хочешь разобраться глубже, стоит сравнить содержимое всех твоих ESP. Что касается конвертации md RAID, я в итоге написал скрипт вместо руководства, потому что подумал, что это будет полезнее. Я протестировал его на 70 свежих серверах с Proxmox VE 8 и разным железом — работает нормально, но, возможно, пропустил какие-то редкие случаи. Вот сам скрипт, ПРЕДОСТАВЛЯЕТСЯ "КАК ЕСТЬ" БЕЗ ГАРАНТИЙ, ИСПОЛЬЗУЙ НА СВОЙ СТРАХ И РИСК, ЗАПУСКАЙ ТОЛЬКО ЕСЛИ ПОНИМАЕШЬ, ЧТО ОН ДЕЛАЕТ: https://gist.github.com/sbraz/0b58302a244cf1767b931b95226fefb8

После запуска нужно добавить новый RAID-массив в mdadm.conf и пересобрать initramfs, чтобы в него попал обновлённый mdadm.conf. Иначе система не распознает массив и при следующей загрузке его могут собрать как /dev/md127, что вызовет путаницу. Также нужно проверить, что в fstab запись для /boot/efi валидна в новой схеме. Если ты не менял fstab с момента установки, ESP должна монтироваться по LABEL=EFI_SYSPART — это по-прежнему работает, потому что новая FAT-файловая система использует тот же ярлык.

Пример запуска на Proxmox VE 8:

Код:
# Запуск скрипта
root@test:~# ./esp_over_raid.sh
Unmounted /boot/efi
/dev/nvme0n1p1 — самая свежая ESP с файлом, изменённым в 2025-09-24T20:48:02+00:00
Скопировано содержимое новой ESP в /root/efi_system_partition_data/files/
Сделан бэкап /dev/nvme0n1p1 в /root/efi_system_partition_data/nvme0n1p1
Удаление подписей с /dev/nvme0n1p1
Подписи удалены с /dev/nvme0n1p1
Сделан бэкап /dev/nvme1n1p1 в /root/efi_system_partition_data/nvme1n1p1
Удаление подписей с /dev/nvme1n1p1
Подписи удалены с /dev/nvme1n1p1
Создание RAID1 устройства /dev/md0
mdadm: размер установлен в 523200K
mdadm: массив /dev/md0 запущен.
Создание FAT-файловой системы на /dev/md0
Копирование содержимого ESP на /dev/md0, смонтированный в /boot/efi
ESP теперь на RAID1:
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
md0           9:0    0 510.9M  0 raid1 /boot/efi
├─nvme1n1p1 259:1    0   511M  0 part  
│ └─nvme1n1 259:0    0 419.2G  0 disk  
└─nvme0n1p1 259:7    0   511M  0 part  
 └─nvme0n1 259:6    0 419.2G  0 disk  
Скрипт завершён успешно, проверь, пожалуйста, запись /boot/efi в /etc/fstab, обнови mdadm.conf и пересобери initramfs

# Обновление mdadm.conf, например, через mkconf в Debian
root@test:~# cp /etc/mdadm/mdadm.conf .
root@test:~# /usr/share/mdadm/mkconf force-generate
root@test:~# diff -u -I '^#' mdadm.conf /etc/mdadm/mdadm.conf
--- mdadm.conf    2025-09-24 21:39:10.113286805 +0000
+++ /etc/mdadm/mdadm.conf    2025-09-24 21:42:29.457819759 +0000
@@ -18,6 +18,7 @@
MAILADDR root

# описания существующих MD-массивов
+ARRAY /dev/md0 UUID=4845c9d4:caf2d945:e58f4aa9:a69bb1cc
ARRAY /dev/md/md2  metadata=1.2 UUID=c1b98502:0c9041aa:52f8b1ff:654bf40e name=md2
ARRAY /dev/md/md3  metadata=1.2 UUID=76f7a921:78a279e2:5fdf9df1:cb4e0b06 name=md3
ARRAY /dev/md/md5  metadata=1.2 UUID=e0b7ff4f:ead83485:705fa843:4f2607bc name=md5

# Пересборка initramfs с обновлённым mdadm.conf
root@test:~# update-initramfs -u
update-initramfs: Генерируется /boot/initrd.img-6.8.12-15-pve
setupcon отсутствует. Пожалуйста, установите пакет 'console-setup'.
Запуск хука 'zz-proxmox-boot'...
Повторный запуск '/etc/kernel/postinst.d/zz-proxmox-boot' в новом приватном пространстве монтирования...
Файл /etc/kernel/proxmox-boot-uuids не найден, пропускаю синхронизацию ESP.

# Проверяем, что запись /boot/efi в fstab работает
root@test:~# grep /boot/efi /etc/fstab
LABEL=EFI_SYSPART    /boot/efi    vfat    defaults    0    1
root@test:~# umount /boot/efi
root@test:~# mount /boot/efi

# Проверяем, что сервер перезагружается
root@test:~# reboot

Несколько заметок о скрипте: его можно запускать как на самом Proxmox, так и из rescue-системы. Единственная разница — если запускаешь там, где /boot/efi не смонтирован, скрипт в конце его не монтирует обратно. Если работаешь из rescue, для обновления mdadm.conf и пересборки initramfs нужно будет зайти в chroot Proxmox. Скрипт должен работать на всех дистрибутивах Linux, я проверял на AlmaLinux 10 и Rocky Linux 10. Требуется только bash, util-linux, dosfstools и rsync. Он опирается на mtime файлов в ESP, чтобы понять, какая из них актуальная. Иногда это может привести к выбору не той ESP. Если так случится, просто переустанови GRUB командой grub-install --no-nvram (опция --no-nvram не меняет порядок загрузки; если её не указать, сервер при загрузке может перейти сразу к диску, и тогда вызов rescue станет невозможен). Скрипт сильно зависит от метки EFI_SYSPART. Не назначай эту метку для чего-то другого — иначе повредишь эти разделы. Он создаёт бэкап всех ESP, так что при необходимости можно вернуть старую конфигурацию с несколькими отдельными ESP (например, с помощью dd). Заметь, что каждый бэкап занимает около 511 МиБ.

Также: мы собираемся внедрить подобную схему для всех новых установок. Сейчас продолжаем тестировать, чтобы всё работало на всём железе, которое мы предлагаем. Надеемся переключиться в ближайшие недели. Если ты установил Proxmox до июня 2024, скорее всего, атрибут efiBootloaderPath у твоего сервера не задан. Это означает, что rEFInd при загрузке сканирует ESP в поисках .efi-файлов. Это не очень хорошо — rEFInd может выбрать не grubx64.efi, да и загрузка идет медленнее. Чтобы ускорить процесс и дать iPXE самостоятельно загрузить GRUB, установи efiBootloaderPath в \efi\proxmox\grubx64.efi (регистр не важен) с помощью этого API маршрута. Не забудь экранировать обратные слэши в JSON, вот пример:

JSON: {
 "efiBootloaderPath": "\\efi\\proxmox\\grubx64.efi"
}

Та же проблема возникла у меня при обновлении с PVE8 до PVE9 на выделенном сервере OVH. Обновление прошло нормально, но после перезагрузки начались сложности. Вот несколько скриптов, которые я сделал, чтобы решить свои проблемы.

Моя схема дисков (4×2 ТБ Soft raid с ZFS):

Code: lsblk -f  
NAME   FSTYPE     FSVER            LABEL        MOUNTPOINTS  
sda                                          
├─sda1 vfat       FAT16            EFI_SYSPART   /boot/efi  
├─sda2 zfs_member 5000             zp0                                        
├─sda3 swap       1                swap-sda3                  
├─sda4 zfs_member 5000             data0                                      
└─sda5 iso9660    Joliet Extension config-2                                
sdb                                          
├─sdb1 vfat       FAT16            EFI_SYSPART                                          
├─sdb2 zfs_member 5000             zp0                        
├─sdb3 swap       1                swap-sdb3                  
└─sdb4 zfs_member 5000             data0                                      
sdc                                          
├─sdc1 zfs_member 5000             data1                                      
└─sdc9                                        
sdd                                          
├─sdd1 zfs_member 5000             data1                                      
└─sdd9                                                                                            
nbd0  

Сначала мне нужно примонтировать диски ZFS в режиме восстановления:

Code: #!/bin/bash  
#  
# Этот скрипт монтирует корневой и загрузочный датасеты ZFS, монтирует EFI-раздел,  
# связывает необходимые системные каталоги и входит в chroot-окружение.  
# Используется в режиме восстановления для восстановления или ремонта системы на базе ZFS.  
#  
# Запускать под root в режиме восстановления  

set -e  

POOL="zp0"  
MOUNTROOT="/mnt"  
EFI_PART="/dev/sda1"   # изменить, если EFI находится в другом месте  
EFI_MNT="$MOUNTROOT/boot/efi"  

# ------------------------------  
# Шаг 1: Импорт пула ZFS, если он ещё не импортирован  
# ------------------------------  
if ! zpool list "$POOL" &>/dev/null; then  
   echo "[1/6] Импорт пула $POOL..."
   zpool import -f -R "$MOUNTROOT" "$POOL"  
else  
   echo "[1/6] $POOL уже импортирован"
fi  

# ------------------------------  
# Шаг 2: Установка точек монтирования  
# ------------------------------  
echo "[2/6] Установка точек монтирования для root и boot..."
zfs set mountpoint=/ "$POOL/zd1"  
zfs set mountpoint=/boot "$POOL/zd0"  

# ------------------------------  
# Шаг 3: Монтирование всех датасетов  
# ------------------------------  
echo "[3/6] Монтирование всех датасетов ZFS..."
zfs mount -a  

# ------------------------------  
# Шаг 4: Монтирование EFI-раздела  
# ------------------------------  
echo "[4/6] Монтирование EFI-раздела $EFI_PART в $EFI_MNT..."
mkdir -p "$EFI_MNT"  
mount | grep -q "$EFI_MNT" || mount "$EFI_PART" "$EFI_MNT"  

# ------------------------------  
# Шаг 5: Привязка системных директорий  
# ------------------------------  
echo "[5/6] Привязка /dev, /proc, /sys, /run..."
for dir in dev proc sys run; do  
   mkdir -p "$MOUNTROOT/$dir"  
   mount --bind "/$dir" "$MOUNTROOT/$dir"  
done  

# ------------------------------  
# Шаг 6: Вход в chroot  
# ------------------------------  
echo "[6/6] Вход в chroot..."
chroot "$MOUNTROOT" /bin/bash  

Дальше я сначала проверяю, что конкретно не так со скриптом:

Code: #!/bin/bash  
#  
# Этот скрипт проверяет состояние пула ZFS, датасеты, точки монтирования, EFI-раздел, конфигурацию GRUB и initramfs  
# внутри chroot среды восстановления. Используется для проверки загрузки и настройки ZFS перед перезагрузкой.  
#  

set -e  

echo "=== [1/6] Статус пула ZFS ==="
zpool status  
echo  

echo "=== [2/6] Датасеты ZFS ==="
zfs list -o name,mountpoint,readonly,canmount  
echo  

echo "=== [3/6] Проверка readonly и точек монтирования ==="
for ds in zp0/zd1 zp0/zd0; do  
   echo "$ds readonly:"  
   zfs get readonly "$ds"  
   echo "$ds mountpoint:"  
   zfs get mountpoint "$ds"  
   echo  
done  

echo "=== [4/6] Проверка монтирования ==="
mount | grep zp0 || echo "Датасеты zp0 не смонтированы"  
echo  

echo "=== [5/6] EFI-раздел ==="
lsblk -f | grep EFI_SYSPART  
mount | grep /boot/efi || echo "/boot/efi не смонтирован"  
echo "Содержимое /boot/efi/EFI:"  
ls -1 /boot/efi/EFI || echo "Загрузочных записей EFI не найдено"  
echo  

echo "=== [6/6] GRUB и initramfs ==="
echo "Проверка записей root=ZFS в grub.cfg:"  
grep "root=ZFS=" /boot/grub/grub.cfg || echo "Записей root=ZFS не найдено"  
echo  
echo "Проверка включения ZFS в initramfs:"  
for k in $(ls /boot/initrd.img*); do  
   echo "$k содержит модули ZFS:"  
   lsinitramfs "$k" | grep -E 'zfs|zpool' || echo "Модули ZFS не найдены"  
done  
echo  
echo "Проверка кэша ZFS:"  
ls -l /etc/zfs/zpool.cache || echo "/etc/zfs/zpool.cache отсутствует"  

echo  
echo "✅ Если все выводы OK, загрузка должна пройти успешно!"  

Далее мой скрипт для реальной починки:

Code: #!/bin/bash  
#  
# Этот скрипт ремонтирует загрузку в chroot среде восстановления:  
# - Обновляет initramfs для всех ядер  
# - Переустанавливает GRUB (UEFI)  
# - Регенерирует конфигурацию GRUB  
# - Обновляет кеш ZFS  
# - Синхронизирует диски перед перезагрузкой  

set -euo pipefail  

echo "=== [1/5] Обновление initramfs для всех ядер ==="
for k in $(ls /lib/modules); do  
   echo " -> Ядро: $k"  
   update-initramfs -c -k $k || update-initramfs -u -k $k  
done  

echo "=== [2/5] Переустановка GRUB (UEFI) ==="
# при необходимости изменить --bootloader-id (отображается в BIOS меню загрузки)  
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Proxmox --recheck  

echo "=== [3/5] Регенерация конфигурации GRUB ==="
update-grub  

echo "=== [4/5] Обновление кеш-файла ZFS ==="
for pool in $(zpool list -H -o name); do  
   echo " -> Установка cachefile для $pool"  
   zpool set cachefile=/etc/zfs/zpool.cache "$pool" || true  
done  

echo "=== [5/5] Синхронизация дисков ==="
sync  

echo "✅ Ремонт загрузки завершён. Выйдите из chroot и аккуратно размонтируйте/экспортируйте пулы перед перезагрузкой."  

Перед повторной загрузкой на жёсткий диск можно снова воспользоваться скриптом для проверки. Надеюсь, кто-то найдёт это полезным.

Спасибо, что указал, @sbraz. Я проверил, и /boot/efi монтировался с /dev/sda1, в то время как последний ESP с обновлёнными файлами GRUB был на /dev/sdb1. Я запустил твой скрипт синхронизации ESP, чтобы убедиться, что всё в порядке. Теперь всё нормально, спасибо!

@sbraz : ===> ОГРОМНОЕ СПАСИБО <=== Ты меня выручил!

@sbraz: ===> ОГРОМНОЕ ОГРОМНОЕ ОГРОМНОЕ СПАСИБО <=== Ты меня тоже спас!