Problema

En entornos de virtualización con Proxmox, es frecuente montar el host en modo passthrough/JBOD y usar ZFS como raíz. Un síntoma recurrente es que, tras un corte de energía o una caída inesperada, el sistema arranca directamente en el prompt de busybox y muestra mensajes como “cannot import pool ‘rpool’” o “no such device”. Al inspeccionar /proc/partitions o ejecutar fdisk -l desde el entorno de recuperación, los discos aparecen como simples dispositivos sdX sin particiones (sdX1, sdX2, …). En contraste, arrancando desde un LiveUSB los mismos discos revelan sus particiones ZFS y EFI intactas. El problema no es corrupción física evidente, sino que el kernel de arranque no reconoce la tabla de particiones GPT y, por ende, no puede montar el pool ZFS.

Este patrón se repite en servidores con controladoras LSI/Lenovo, discos SSD en espejo y RAID‑Z, y suele aparecer después de eventos de energía, reinicios forzados o cambios en la configuración de la BIOS.

Causa

  1. GPT dañado o parcialmente leído – Un apagón puede interrumpir la escritura del encabezado secundario del GPT. Cuando el kernel solo ve el encabezado primario, algunos controladores (especialmente los que usan blkid en initramfs) fallan al crear los nodos de dispositivo y el busybox muestra discos sin particiones.

  2. Módulo ZFS ausente o no cargado en initramfs – Si la generación del initramfs quedó incompleta o el paquete zfs-initramfs se actualizó sin regenerar la imagen, el kernel arranca sin el driver necesario para interpretar los dispositivos ZFS, lo que lleva a que busybox no vea nada más que los discos crudos.

  3. Controladora en modo incorrecto – Cambios implícitos en la BIOS (por ejemplo, pasar de AHCI a RAID o activar Secure Boot) pueden hacer que el controlador presente los discos como “raw” sin exponer la tabla GPT al kernel.

  4. Problemas de udev/blkid – Si el directorio /run/udev se corrompe o el daemon no arranca, los enlaces de dispositivo (/dev/disk/by-id/...) no se crean, y el script de importación de ZFS no encuentra los dispositivos esperados.

  5. Kernel mismatch – Algunas versiones de Proxmox incluyen varios kernels con su propio busybox. Si se arranca con un kernel que no incluye el módulo ZFS, el mismo comportamiento se reproduce aunque el resto del sistema sea idéntico.

Solución

1. Verificar integridad del GPT desde un LiveUSB

Montar el disco y usar gdisk para inspeccionar y, si es necesario, reparar el encabezado secundario.

gdisk /dev/sda   # repetir para cada disco afectado

En el menú de gdisk, la opción v (verify) muestra errores. Si indica “GPT main header corrupted” o “secondary header not found”, usa w para escribir un nuevo encabezado secundario basado en el primario.

2. Regenerar el initramfs con soporte ZFS

Arrancar desde el LiveUSB, montar la raíz ZFS y chroot para reconstruir la imagen de arranque.

zpool import -R /mnt rpool
mount -t zfs rpool/ROOT/default /mnt
mount --rbind /dev /mnt/dev
mount --rbind /proc /mnt/proc
mount --rbind /sys /mnt/sys
chroot /mnt /bin/bash
apt-get update
apt-get install --reinstall zfs-initramfs
update-initramfs -c -k all
exit
zpool export rpool
reboot

Esto asegura que el módulo zfs esté incluido y que el script de importación encuentre los discos antes de montar la raíz.

3. Forzar la importación del pool en el prompt de busybox

Si el sistema sigue arrancando en busybox, se puede intentar una importación manual:

zpool import -f -R /mnt rpool

Si el pool se importa correctamente, montar la raíz y continuar el arranque:

mount -t zfs rpool/ROOT/default /mnt
exec switch_root /mnt /sbin/init

Esta técnica es útil para validar que el pool está saludable y que el problema radica en el script de initramfs.

4. Revisar la configuración de la BIOS/UEFI

  • Confirmar que el modo SATA está en AHCI y que Secure Boot está desactivado (o que el shim está presente).
  • Verificar que la controladora LSI está en IT (Initiator Target) mode, no en RAID.
  • Guardar los cambios y reiniciar.

5. Actualizar o volver a un kernel con ZFS integrado

Si el problema persiste en versiones más recientes del kernel, probar arrancar con una versión anterior que se haya usado sin incidentes:

  1. En el menú de GRUB, seleccionar Advanced options → Proxmox → kernel‑<versión‑antigua>.
  2. Si arranca, regenerar el initramfs con esa versión (update-initramfs -c -k <versión>).

Cuándo aplicar esta solución

  • Síntomas: busybox al boot, mensaje “cannot import pool”, discos listados sin particiones, fdisk -l muestra un único EFI que ocupa todo el disco.
  • Entorno: Proxmox, Debian‑based, ZFS como raíz, discos en passthrough/JBOD.
  • No aplicar: Si los discos presentan fallos SMART, sectores defectuosos o la BIOS muestra errores de detección; en esos casos la recuperación de datos precede a la reparación del arranque.

Código

# Paso 1: reparar GPT
gdisk /dev/sdX   # repetir para cada disco

# Paso 2: chroot y regenerar initramfs con ZFS
zpool import -R /mnt rpool
mount -t zfs rpool/ROOT/default /mnt
mount --rbind /dev /mnt/dev
mount --rbind /proc /mnt/proc
mount --rbind /sys /mnt/sys
chroot /mnt /bin/bash
apt-get install --reinstall zfs-initramfs
update-initramfs -c -k all
exit
zpool export rpool
reboot

Verificación

  1. Después de reiniciar, observar que GRUB carga el kernel y que el mensaje de busybox desaparece.
  2. Ejecutar zpool status para confirmar que rpool está ONLINE y sin errores.
  3. Verificar que lsblk muestra las particiones esperadas (sdX1 EFI, sdX2 ZFS_member) y que los dispositivos /dev/disk/by-id/* existen.
  4. Revisar los logs de arranque (journalctl -b) en busca de líneas que indiquen problemas de ZFS o de GPT.

Notas adicionales

  • Mantener siempre una copia de seguridad del encabezado GPT (sgdisk -b backup.gpt /dev/sdX) facilita la recuperación tras cortes de energía.
  • En servidores con varios discos, es buena práctica habilitar Write cache y Force Unit Access (FUA) en la controladora para reducir la probabilidad de corrupción de metadatos.
  • Si la importación manual funciona pero el arranque automático sigue fallando, inspeccionar /etc/initramfs-tools/conf.d/zfs y asegurarse de que la variable ZFS_IMPORT_POOL incluye el nombre del pool raíz.
  • En entornos con alta disponibilidad, considerar la replicación del pool a un segundo nodo para evitar tiempos de inactividad tras fallos de hardware o de firmware.