Disco bueno ada0, disco nuevo ada3, el muerto era ada1:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

zpool status zroot                                  # ada1p4 FAULTED / UNAVAIL
gpart backup ada0 | gpart restore -F ada3           # clona la tabla de particiones
gpart show ada3                                     # p1 efi, p2 freebsd-boot, p3 freebsd-swap, p4 freebsd-zfs

# Bootcode BIOS: el índice es el de la partición freebsd-boot
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada3

# UEFI: rellena la ESP
newfs_msdos -F 32 -c 1 /dev/ada3p1
mount -t msdosfs /dev/ada3p1 /mnt
mkdir -p /mnt/EFI/BOOT /mnt/EFI/FREEBSD
cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.EFI
cp /boot/loader.efi /mnt/EFI/FREEBSD/LOADER.EFI
umount /mnt

# El disco nuevo entra al mirror en el lugar del muerto
zpool replace zroot ada1p4 ada3p4
zpool status zroot                                  # resilver en curso

Cuando zpool status diga ONLINE en los dos, prueba a arrancar solo con el disco nuevo.

Antes de empezar

• Identifica el disco. zpool status nombra el miembro muerto (ada1p4, o un GUID largo si ya no está). camcontrol devlist lista los discos con modelo y serie para saber cuál bahía tocar.
• Si el disco malo sigue conectado, sácalo del pool antes de tirar del cable: zpool offline zroot ada1p4.
• Layout. Una instalación por defecto de FreeBSD 13/14 con zroot crea, por disco: p1 efi, p2 freebsd-boot, p3 freebsd-swap, p4 freebsd-zfs. Instalaciones antiguas o a mano varían: mira gpart show ada0 y ajusta los índices. El -i del bootcode es el de freebsd-boot.
• El disco nuevo tiene que ser igual o mayor. gpart restore copia tamaños exactos; si es mayor, el resto queda libre y lo puedes usar después.

Por qué particiones y no el disco entero

En un pool de arranque cada disco lleva las particiones de boot además de la de ZFS. Si haces zpool replace zroot ada1p4 ada3 con el disco crudo, el mirror funciona pero ese disco no puede arrancar: el día que ada0 muera, tendrás los datos y ningún cargador. Por eso el orden es: particionar igual, bootcode, y solo entonces zpool replace con la partición.

Paso a paso

1. Clonar la tabla de particiones.

1
2

gpart backup ada0 | gpart restore -F ada3
gpart show ada3

-F destruye lo que hubiera en ada3. Si el pool usa etiquetas GPT (gpt/zfs0 en zpool status) en vez de nombres adaXpY, ponle la suya al nuevo: gpart modify -i 4 -l zfs1 ada3, y usa gpt/zfs1 en el zpool replace.

2. Bootcode. Instala los dos: así arranca tanto si la placa está en modo BIOS/CSM como en UEFI.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# BIOS: MBR protector + gptzfsboot en la partición freebsd-boot (p2 en el layout por defecto)
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada3

# UEFI: la ESP (p1) es un FAT32 con loader.efi en las rutas estándar
newfs_msdos -F 32 -c 1 /dev/ada3p1
mount -t msdosfs /dev/ada3p1 /mnt
mkdir -p /mnt/EFI/BOOT /mnt/EFI/FREEBSD
cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.EFI
cp /boot/loader.efi /mnt/EFI/FREEBSD/LOADER.EFI
umount /mnt

Las guías viejas dicen gpart bootcode -p /boot/boot1.efifat -i 1; boot1.efi está obsoleto en FreeBSD actual y el camino documentado en loader.efi(8) es copiar loader.efi a la ESP. Si quieres una entrada propia en el firmware: efibootmgr -c -l /mnt/EFI/FREEBSD/LOADER.EFI -L FreeBSD-ada3 -a.

3. Reemplazar en el pool.

1

zpool replace zroot ada1p4 ada3p4

Si el miembro muerto ya no aparece y el mirror quedó con un solo disco, en vez de replace se añade al superviviente: zpool attach zroot ada0p4 ada3p4.

4. Resilver.

1

zpool status zroot           # scan: resilver in progress ... % done

Horas, según lo lleno que esté el pool. Opcional, para que el resilver no ceda tanto el turno a la carga normal:

1

sysctl vfs.zfs.resilver_min_time_ms=5000

5. Swap. Si /etc/fstab tenía /dev/ada1p3 como swap, cámbialo a /dev/ada3p3 (o mejor, a etiquetas gpt/swapN que no cambien con el nombre del disco) y swapon -a.

6. Comprobar el arranque. Con el resilver terminado, apaga, desconecta ada0 (o cambia el orden de arranque) y arranca desde el nuevo. Si entra, vuelve a conectar y zpool status debe seguir ONLINE sin quejas. Una zpool scrub zroot de cierre no está de más.

Trampas

• gpart restore -F no pregunta. Revisa dos veces cuál es el disco nuevo; camcontrol devlist y diskinfo -v ada3 (serie) antes de escribir.
• Bootcode de un solo tipo deja el disco arrancable solo en un modo de firmware. Pon los dos.
• Sector físico distinto (512 vs 4K) puede hacer que zpool replace se queje del ashift; en un mirror moderno con ashift=12 un disco 4Kn entra sin problema, uno con ashift=9 no.
• Disco más grande: tras el resilver, gpart resize -i 4 ada3 y zpool online -e zroot ada3p4; cuando los dos discos del mirror sean grandes, el pool crece.
• Los nombres adaX cambian al quitar discos; las etiquetas GPT y los GUID no. Para la operación usa lo que muestre zpool status en ese momento.

Ver también

• Reemplazar un disco en un pool ZFS — la versión Linux/Proxmox, sin particiones de arranque.
• Importar un pool después de un apagón.
• FreeBSD: man 8 loader.efi, man 8 gpart, y el artículo de Babak Farrokhi sobre el reemplazo en BIOS.

Arranca la ISO de Proxmox → Advanced Options → Install Proxmox VE (Debug mode); en el primer shell pulsa Ctrl+D para llegar al segundo, que ya tiene LVM:

1
2
3
4

vgscan
vgchange -ay
lvcreate -L 4M pve -n grubtemp   # cualquier cambio en los metadatos de LVM sirve
reboot

Con el nodo ya arriba, limpia y deja el arreglo permanente:

1
2
3

lvremove pve/grubtemp
[ -d /sys/firmware/efi ] && apt install grub-efi-amd64     # UEFI
# BIOS legacy: grub-install /dev/sdX && update-grub        # el disco, no la partición

El error

1
2
3

error: disk 'lvmid/Xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx/Yyyyyy-yyyy-yyyy-yyyy-yyyy-yyyy-yyyyyy' not found.
Entering rescue mode...
grub rescue>

El disco está bien, el VG pve está bien y los datos están bien. A veces el mismo bug avisa antes, durante un apt full-upgrade:

1

/usr/sbin/grub-probe: error: disk `lvmid/...' not found.

Si ves eso en update-grub, aplica el arreglo antes de reiniciar.

Por qué pasa

LVM guarda sus metadatos en disco en un ring buffer. Cada cambio (crear, borrar o redimensionar un LV) escribe una copia nueva más adelante en el buffer, y tarde o temprano el texto da la vuelta al final. GRUB 2.06 de Debian 11 (PVE 7, 2.06-3) no sabe leer esa vuelta: no encuentra el VG, no encuentra el LV pve/root y cae a grub rescue.

Por eso “arreglarlo” es tan raro como hacer un cambio cualquiera en LVM: los metadatos se reescriben en otra posición, normalmente sin vuelta, y GRUB los vuelve a leer. Y por eso vuelve a pasar semanas o meses después, cuando el buffer da la vuelta otra vez, si el GRUB instalado en el disco sigue siendo el viejo.

En el lab el cambio que sacó del apuro fue lvextend -L +1G /dev/pve/root. Funciona igual, pero deshacerlo con lvreduce sobre el root montado es jugar con fuego; si lo hiciste así, mejor conserva el 1G (resize2fs /dev/pve/root) o usa el LV de usar y tirar del En corto.

Procedimiento completo

1. Entra al sistema. Dos vías desde la ISO de Proxmox:

   • Rescue Boot (Advanced Options): la ISO busca la instalación y arranca su kernel saltándose el GRUB roto. Si funciona, ya estás dentro del sistema real y puedes pasar al paso 3.
   • Debug mode: shell de rescate. Ctrl+D en el primer prompt; en el segundo ya están los módulos de LVM.

2. Dispara un cambio de metadatos (solo si entraste por Debug mode):

   1 2 3 4

   vgscan vgchange -ay lvcreate -L 4M pve -n grubtemp reboot

3. Ya en el sistema normal, quita el LV temporal y mira si los metadatos siguen dando la vuelta:

   1 2	lvremove pve/grubtemp vgscan -vvv 2>&1 | grep 'Reading metadata'

   Una salida que termina en (+0) significa sin vuelta; cualquier otro valor, que el problema va a repetirse hasta que reinstales GRUB.

4. Reinstala el GRUB con el fix. El paquete de PVE 8 y 9 (2.06-13 o más nuevo) ya lo trae, pero el binario que está en el ESP o en el MBR solo se reescribe cuando el paquete se (re)instala:

   1 2 3 4 5 6 7 8

   # UEFI: en nodos actualizados desde PVE 7 suele estar grub-pc y no grub-efi-amd64 dpkg -l | grep -E '^ii +grub-' apt install grub-efi-amd64 efibootmgr -v # confirma la entrada "proxmox" # BIOS legacy grub-install /dev/sdX update-grub

   En PVE 7 el arreglo de verdad es actualizar a PVE 8; el workaround solo te compra tiempo.

Trampas

• grub rescue> no te va a sacar de esta. ls (lvm/pve-root) no muestra nada porque el módulo lvm es precisamente el que no entiende los metadatos. No pierdas tiempo ahí.
• Root en ZFS no pasa por aquí. Los nodos con rpool arrancan con proxmox-boot-tool; ese es otro camino y otros errores.
• Apunta a las particiones correctas si haces grub-install a mano: el disco (/dev/sda), no /dev/sda1; el ESP montado en /boot/efi para UEFI.
• En clúster, arreglado un nodo revisa los demás con vgscan -vvv | grep 'Reading metadata'; la instalación es la misma y el buffer también.

Referencias: Recover From Grub Failure en la wiki de Proxmox y el hilo del foro.