Recuperación del pool de arranque ZFS: recuperar un sistema tras una actualización fallida

Un modelo mental útil: qué significa realmente “pool de arranque”

Los sistemas ZFS que «arrancan desde ZFS» suelen tener dos personalidades de almacenamiento distintas:
un pequeño pool de arranque (comúnmente bpool) que contiene kernel, initramfs y piezas amigables para el bootloader; y un pool raíz
(comúnmente rpool) que contiene todo lo demás. Algunas plataformas omiten la separación y arrancan directamente desde el pool raíz.
Otras plataformas usan UEFI y almacenan artefactos EFI en una ESP FAT, no en ZFS. Necesitas identificar en qué universo estás.

Una actualización fallida puede romper el arranque de varias maneras:

• El bootloader no encuentra su configuración o no puede leer ZFS.
• El kernel arranca pero initramfs no puede importar el pool raíz.
• Los módulos ZFS no coinciden con el kernel.
• Se habilitaron características del pool en una máquina y ahora un entorno más antiguo no puede importar.
• Un miembro del mirror falló y el firmware/orden de arranque elige el disco equivocado.

Tu trabajo no es «arreglar ZFS». Tu trabajo es responder una pregunta rápidamente:
¿en qué parte de la cadena de arranque falla? Etapa del bootloader, del kernel, del initramfs o del espacio de usuario.
Herramientas distintas; arreglos distintos.

Aquí está la cadena en términos sencillos:
firmware → bootloader (GRUB/systemd-boot) → kernel + initramfs → ZFS import → mount root → switch_root → servicios.
Cuando lo tratas como una cadena, dejas de reinstalar GRUB al azar como si fuera agua bendita.

Broma #1: GRUB no es malicioso; es simplemente un entusiasta de los mensajes de error interpretativos.

Guía de diagnóstico rápido (revisa esto primero)

Primero: identifica la etapa de fallo

• Atascado antes del menú de GRUB: firmware/ESP/orden de arranque, o bootloader ausente.
• El menú de GRUB aparece, la selección de kernel funciona, luego cae a la shell de initramfs: import de ZFS o problema con initramfs/módulos.
• El kernel arranca, luego panic: a menudo dataset raíz faltante, root= incorrecto, o módulo ZFS incompatible.
• Arranca en single-user/emergency: el pool se importó pero fallan puntos de montaje/datasets/servicios o las claves de cifrado.

Segundo: no mutar nada hasta poder leer los pools

• Arranca un entorno live que tenga herramientas ZFS que coincidan (o sean cercanas) a tu versión en disco.
• Importa los pools en modo solo lectura primero. Si se importan, tienes opciones. Si no, necesitas entender por qué.

Tercero: decide tu estrategia de recuperación

• Revertir a un entorno de arranque/snapshot conocido bueno si lo tienes. Es lo más rápido.
• Reparar el bootloader si el OS está intacto pero la entrada de arranque está rota.
• Reconstruir initramfs si los módulos ZFS no están disponibles temprano en el arranque.
• Arreglar la salud del pool (mirror degradado, disco de arranque equivocado) si la máquina está arrancando desde el miembro «equivocado».

Cuarto: preservar evidencia

Captura los últimos logs de arranque del sistema fallido (si son accesibles) y las versiones exactas de kernel + paquetes ZFS.
En sistemas con múltiples entornos de arranque, registra cuál se seleccionó. La recuperación es más sencilla cuando puedes demostrar qué cambió.

Hechos y contexto interesantes (porque la historia pega)

1. ZFS se diseñó con integridad de extremo a extremo como característica principal, por eso la «corrupción silenciosa» se toma muy en serio en toda la pila.
2. La separación de “pool de arranque” es en gran parte una restricción del bootloader: históricamente GRUB tenía soporte limitado para características ZFS, por lo que mantener /boot simple reducía problemas.
3. Se introdujeron flags de características para evitar el bloqueo por números de versión. Buena idea—hasta que habilitas una feature y tratas de importar en una imagen de rescate antigua.
4. Illumos y BSD han tratado a ZFS como ciudadano nativo, mientras que Linux con frecuencia lo trata como un módulo externo; esa diferencia importa durante actualizaciones de initramfs y kernel.
5. zpool.cache se volvió una dependencia silenciosa para muchos flujos de arranque; si está desactualizado o falta, las importaciones pueden convertirse en búsquedas exhaustivas.
6. UEFI cambió los modos de fallo del bootloader: puedes tener un pool ZFS perfecto y aun así fallar porque la entrada de la EFI System Partition desapareció.
7. Los entornos de arranque (boot environments) popularizaron flujos de «actualizar sin miedo» en el mundo Solaris/illumos; la gente de Linux redescubre esa comodidad mediante snapshots y clone de datasets.
8. El proyecto ZFS on Linux se fusionó en OpenZFS, lo que redujo la fragmentación pero no eliminó el problema de coordinación «kernel vs módulo».

Una frase que debería colgar en todas las paredes de on-call:
«La esperanza no es una estrategia.» — General Gordon R. Sullivan

Tareas prácticas de recuperación (comandos, salidas, decisiones)

Supuestos: has arrancado un ISO live o entorno de rescate que incluye herramientas ZFS (zpool, zfs) y utilidades básicas de disco.
Sustituye nombres de pool/dataset según sea necesario. Los comandos abajo están diseñados para ser ejecutables y producir evidencia significativa.

Tarea 1: Identificar discos, particiones y qué cambió

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE PARTTYPE                             PARTLABEL MOUNTPOINTS
nvme0n1   476.9G disk
├─nvme0n1p1   1G part vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI
├─nvme0n1p2   4G part zfs_member
└─nvme0n1p3 471G part zfs_member
nvme1n1   476.9G disk
├─nvme1n1p1   1G part vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI
├─nvme1n1p2   4G part zfs_member
└─nvme1n1p3 471G part zfs_member

Qué significa: ves si tratas con una ESP (vfat) más miembros ZFS, y si existen mirrors.
Decisión: si existe ESP, debes considerar las entradas de arranque UEFI. Si no hay ESP y usas BIOS, GRUB probablemente vive en el área MBR.

Tarea 2: Comprobar si los pools son visibles y por qué puede que no se importen

cr0x@server:~$ sudo zpool import
   pool: bpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        bpool        ONLINE
          nvme0n1p2  ONLINE
          nvme1n1p2  ONLINE

   pool: rpool
     id: 9876543210987654321
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        rpool        ONLINE
          mirror-0   ONLINE
            nvme0n1p3  ONLINE
            nvme1n1p3  ONLINE

Qué significa: el entorno live puede ver ambos pools; buena señal. Si en su lugar ves «cannot import» con feature flags,
la imagen de rescate probablemente tiene OpenZFS demasiado antiguo.
Decisión: si los pools aparecen, impórtalos solo-lectura primero. Si no, actualiza el entorno de rescate o usa un ISO de distro que coincida.

Tarea 3: Importar pools en solo lectura y sin montar (inspección segura)

cr0x@server:~$ sudo zpool import -N -o readonly=on rpool
cr0x@server:~$ sudo zpool import -N -o readonly=on bpool

Qué significa: los pools se importan pero los datasets no se montan; reduces escrituras accidentales.
Decisión: si la importación falla con «pool is busy», algo se auto-importó; comprueba zpool status y exporta/re-importa deliberadamente.

Tarea 4: Confirmar la salud del pool y detectar escenarios de “arranque desde disco equivocado”

cr0x@server:~$ sudo zpool status -v rpool
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:10:12 with 0 errors on Tue Dec 24 03:10:12 2025
config:

        NAME           STATE     READ WRITE CKSUM
        rpool          ONLINE       0     0     0
          mirror-0     ONLINE       0     0     0
            nvme0n1p3  ONLINE       0     0     0
            nvme1n1p3  ONLINE       0     0     0

errors: No known data errors

Qué significa: el pool raíz está sano. Si ves DEGRADED o un dispositivo UNAVAIL,
el arranque puede estar intentando la ruta muerta.
Decisión: si es mirror, asegúrate de que los artefactos de boot/EFI existan en ambos discos, no solo en el «primario».

Tarea 5: Listar datasets y encontrar los críticos para el arranque

cr0x@server:~$ sudo zfs list -o name,mountpoint,canmount,readonly -r rpool | head -n 12
NAME                         MOUNTPOINT  CANMOUNT  READONLY
rpool                        none        off       on
rpool/ROOT                    none        off       on
rpool/ROOT/ubuntu_1           /           noauto    on
rpool/home                    /home       on        on
rpool/var                     /var        on        on
rpool/var/log                 /var/log    on        on

Qué significa: puedes ver el dataset raíz (a menudo bajo rpool/ROOT/*) y si está configurado para montarse.
Decisión: identifica el dataset de entorno de arranque previsto. Si existen varios, puedes revertir seleccionando uno distinto.

Tarea 6: Identificar el entorno de arranque activo (o el que debería estar activo)

cr0x@server:~$ sudo zpool get -H bootfs rpool
rpool  bootfs  rpool/ROOT/ubuntu_1  local

Qué significa: bootfs apunta al dataset que se espera monte como /.
Decisión: si bootfs es incorrecto o apunta a un dataset ausente, configúralo a uno válido y reconstruye los artefactos de arranque.

Tarea 7: Montar el sistema de forma controlada (para reparar)

cr0x@server:~$ sudo mkdir -p /mnt
cr0x@server:~$ sudo zfs set readonly=off rpool/ROOT/ubuntu_1
cr0x@server:~$ sudo zfs mount rpool/ROOT/ubuntu_1
cr0x@server:~$ sudo mount --rbind /dev /mnt/dev
cr0x@server:~$ sudo mount --rbind /proc /mnt/proc
cr0x@server:~$ sudo mount --rbind /sys /mnt/sys
cr0x@server:~$ mount | head -n 5
rpool/ROOT/ubuntu_1 on / type zfs (rw,relatime,xattr,noacl)
udev on /mnt/dev type devtmpfs (rw,nosuid,relatime,size=16343656k,nr_inodes=4085914,mode=755)
proc on /mnt/proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /mnt/sys type sysfs (rw,nosuid,nodev,noexec,relatime)

Qué significa: montaste root y vinculaste los pseudo-sistemas del kernel para que las reparaciones con chroot funcionen.
Decisión: si el dataset raíz se monta pero rutas clave están vacías, puede que hayas montado el dataset equivocado (común con múltiples entornos de arranque).

Tarea 8: Comprobar la alineación entre kernel y módulo ZFS (fallo clásico por actualización)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'uname -r; dpkg -l | egrep "zfs|linux-image" | head'
5.15.0-92-generic
ii  linux-image-5.15.0-92-generic   5.15.0-92.102  amd64  Signed kernel image generic
ii  zfsutils-linux                  2.1.5-1ubuntu6 amd64  command-line tools to manage ZFS filesystems
ii  zfs-dkms                        2.1.5-1ubuntu6 amd64  OpenZFS kernel modules for Linux

Qué significa: confirmas qué kernel se espera y si ZFS DKMS está instalado.
Decisión: si el kernel se actualizó pero los módulos ZFS no se construyeron (o fueron purgados), initramfs no importará el pool. Reconstruye módulos/initramfs.

Tarea 9: Reconstruir initramfs y asegurar que los hooks ZFS estén presentes

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'update-initramfs -u -k all'
update-initramfs: Generating /boot/initrd.img-5.15.0-92-generic
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_12.bin for module i915

Qué significa: la generación de initramfs fue exitosa; una advertencia de firmware suele ser ajena al arranque ZFS.
Decisión: si ves errores sobre hooks de zfs o zpool ausente, corrige el estado de paquetes (instala zfs-initramfs donde aplique).

Tarea 10: Verificar que la línea de comandos del kernel apunte al dataset root correcto

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grep -R "root=ZFS=" -n /boot/grub/grub.cfg | head -n 3'
/boot/grub/grub.cfg:126:        linux   /ROOT/ubuntu_1/@/boot/vmlinuz-5.15.0-92-generic root=ZFS=rpool/ROOT/ubuntu_1 ro quiet

Qué significa: GRUB está configurado para montar el dataset ZFS esperado como root.
Decisión: si apunta a un dataset que ya no existe (renombrado, revertido, clonado), regenera la configuración de GRUB y ajusta bootfs adecuadamente.

Tarea 11: Regenerar la configuración de GRUB y reinstalar el bootloader (caso BIOS)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grub-mkconfig -o /boot/grub/grub.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-92-generic
Found initrd image: /boot/initrd.img-5.15.0-92-generic
done
cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grub-install /dev/nvme0n1'
Installing for i386-pc platform.
Installation finished. No error reported.

Qué significa: la configuración incluye kernels; GRUB se instaló en el disco. En arranques espejo, repite para el otro disco.
Decisión: si en realidad eres UEFI, no hagas instalaciones BIOS. En su lugar monta la ESP y usa la vía UEFI que sigue más abajo.

Tarea 12: Reparar artefactos y entradas de arranque UEFI (caso UEFI)

cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck'
Installing for x86_64-efi platform.
Installation finished. No error reported.
cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'efibootmgr -v | head -n 5'
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu  HD(1,GPT,2b3c...,0x800,0x32000)/File(\EFI\ubuntu\grubx64.efi)

Qué significa: GRUB está instalado en la ESP y existe una entrada de arranque.
Decisión: en sistemas mirror, también monta y popula la ESP del segundo disco. El orden de arranque del firmware puede cambiar inesperadamente tras fallos.

Tarea 13: Verificar el contenido de /boot vivo en el pool/dataset esperado

cr0x@server:~$ sudo zfs list -o name,mountpoint -r bpool
NAME            MOUNTPOINT
bpool           /boot
bpool/BOOT      /boot
bpool/BOOT/ubuntu_1 /boot
cr0x@server:~$ sudo ls -lh /mnt/boot | head
total 192M
-rw-r--r-- 1 root root  26M Dec 24 03:02 initrd.img-5.15.0-92-generic
-rw------- 1 root root  12M Dec 24 03:02 System.map-5.15.0-92-generic
-rw------- 1 root root 8.3M Dec 24 03:02 vmlinuz-5.15.0-92-generic

Qué significa: confirma si /boot está montado en ZFS y contiene el kernel/initrd que esperas.
Decisión: si /boot está vacío o no montado, estás reparando el sistema de ficheros equivocado. Monta correctamente los datasets de bpool y vuelve a ejecutar initramfs/GRUB.

Tarea 14: Confirmar el comportamiento de import ZFS en el arranque temprano (cachefile y hostid)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'ls -l /etc/hostid; zpool get -H cachefile rpool'
-rw-r--r-- 1 root root 4 Dec 22 10:10 /etc/hostid
rpool  cachefile  /etc/zfs/zpool.cache  local

Qué significa: hostid existe (ayuda a prevenir importaciones accidentales en el host equivocado) y cachefile está establecido.
Decisión: si cachefile es «-» o apunta a ningún sitio, configúralo y regénéralo desde una importación conocida buena para facilitar la vida al initramfs.

Tarea 15: Arreglar un zpool.cache roto (común después de chroot o clonado de imagen)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'zpool set cachefile=/etc/zfs/zpool.cache rpool; zpool set cachefile=/etc/zfs/zpool.cache bpool; ls -l /etc/zfs/zpool.cache'
-rw-r--r-- 1 root root 2430 Dec 26 18:02 /etc/zfs/zpool.cache

Qué significa: cachefile existe y contiene rutas de dispositivos/guid para la importación.
Decisión: regenera initramfs después de cambiar esto para que el arranque temprano vea el cache actualizado.

Tarea 16: Comprobar incompatibilidad de feature flags (por qué un ISO de rescate no puede importar)

cr0x@server:~$ sudo zpool import -o readonly=on rpool
cannot import 'rpool': unsupported feature(s)
  Pool 'rpool' uses the following feature(s) not supported by this system:
    com.delphix:spacemap_histogram
    org.openzfs:project_quota

Qué significa: el OpenZFS del entorno de rescate es demasiado antiguo para entender las features habilitadas en el pool.
Decisión: detente. No hagas «force» de nada. Arranca una imagen de rescate más nueva, o instala OpenZFS más reciente en el entorno live.

Tarea 17: Si GRUB cae a rescue, localizar /boot y cargar normal

cr0x@server:~$ ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) (hd1) (hd1,gpt1) (hd1,gpt2) (hd1,gpt3)
cr0x@server:~$ ls (hd0,gpt2)/
@/ BOOT/ grub/
cr0x@server:~$ set prefix=(hd0,gpt2)/grub
cr0x@server:~$ insmod normal
cr0x@server:~$ normal

Qué significa: apuntaste manualmente GRUB al filesystem correcto y cargaste el módulo normal para alcanzar el menú.
Decisión: una vez arrancado (o chrooteado), reinstala GRUB correctamente; el rescate manual es un paracaídas puntual, no un modo de vida.

Tarea 18: Revertir una actualización rota usando snapshots (cuando existan)

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -r rpool/ROOT/ubuntu_1 | tail -n 3
rpool/ROOT/ubuntu_1@pre-upgrade-2025-12-24  Tue Dec 24 02:55 2025
rpool/ROOT/ubuntu_1@post-upgrade-2025-12-24 Tue Dec 24 03:05 2025
cr0x@server:~$ sudo zfs rollback -r rpool/ROOT/ubuntu_1@pre-upgrade-2025-12-24

Qué significa: revertiste el estado del sistema de ficheros a un punto conocido. A menudo es la vía más rápida para salir de un conjunto de paquetes defectuosos.
Decisión: después del rollback, regenera initramfs/GRUB para alinear los artefactos de arranque con el estado restaurado, y luego reinicia.

Broma #2: Si tu plan de recuperación es «rebootear otra vez», felicitaciones—has implementado ingeniería del caos sin papeleo.

Tres mini-historias corporativas desde el campo

Incidente #1: El outage causado por una suposición equivocada

Una empresa mediana ejecutaba una flota de hosts Linux con NVMe en espejo y ZFS root. El equipo se había estandarizado recientemente en UEFI.
Su modelo mental: «discos en espejo significa arranque en espejo». Tenían media razón, que es el tipo de razón más peligroso.

Una actualización rutinaria incluyó una reinstalación de GRUB y un aumento de kernel. El cambio funcionó en staging y en la mayoría de nodos de producción.
Un nodo reinició y cayó directo al firmware. No hubo menú de GRUB. No se encontró disco. El on-call asumió problemas de import ZFS.
Pasaron una hora en fantasías de initramfs mientras la máquina ni siquiera llegaba a initramfs.

El problema real: solo la ESP de un disco se había montado durante el ciclo de actualización, así que solo ese disco recibió artefactos EFI actualizados.
El nodo había tenido un pequeño fallo silencioso en un NVMe y el firmware cambió el orden de arranque al otro disco—cuya ESP estaba obsoleta.
Los datos ZFS en espejo no importaron; el firmware no puede arrancar lo que no está ahí.

La solución fue vergonzosamente simple: montar ambas ESP, instalar GRUB en ambas y asegurar que un trabajo periódico las mantuviera sincronizadas.
La mejora duradera fue cultural: durante incidentes, empezaron a decir en voz alta la etapa de fallo.
«Estamos fallando antes de GRUB» se convirtió en una frase que la gente podía decir sin ser juzgada.

Incidente #2: La optimización que salió mal

Otra organización quería arranque más rápido y menos complejidad. Alguien propuso: «¿Para qué mantener un pool de arranque separado?
Pongamos /boot en el pool raíz y habilitemos características ZFS nuevas en todas partes. Un pool para gobernarlos a todos.»
Se presentó como simplificación. En realidad fue acoplamiento.

Durante meses funcionó. Luego una actualización de kernel coincidió con un escenario de rescate: un nodo falló por hardware no relacionado.
El equipo tomó un ISO de rescate genérico—más antiguo, pero «suficiente». El ISO no pudo importar el pool debido a features no soportadas.
Quedaron fuera de sus propios datos por una incompatibilidad de versión de herramientas que ellos mismos habían optimizado.

Eventualmente se recuperaron encontrando un entorno live más nuevo e importando en solo-lectura. Pero el tiempo de recuperación se disparó.
El postmortem no fue sobre culpables; fue sobre suposiciones.
«Siempre tendremos una imagen de rescate lo bastante nueva» resultó ser un cuento de hadas que no sobrevive fines de semana largos.

Después, restauraron el patrón de pool separado de arranque y trataron la habilitación de feature flags como un cambio de producción
que requiere un plan explícito de compatibilidad. A veces las «restricciones antiguas» existen porque el mundo es desordenado, no porque la gente fuera perezosa.

Incidente #3: La práctica aburrida que salvó el día

Un equipo de servicios financieros ejecutaba ZFS root con controles estrictos de cambio. Hicieron una cosa poco glamurosa de forma consistente:
antes de cualquier ventana de actualización, creaban snapshots del dataset raíz y registraban el bootfs previsto en el ticket.
Nada heroico. Solo disciplina.

Una actualización introdujo una descoordinación entre kernel y módulos ZFS. El nodo reinició a initramfs y se negó a importar root.
El on-call no empezó a reinstalar paquetes al azar. Importaron los pools en solo-lectura desde un entorno de rescate,
verificaron que los snapshots existían y hicieron rollback al snapshot pre-upgrade.

Luego regeneraron initramfs y GRUB, reiniciaron, y el sistema volvió con el kernel anterior y conocido bueno.
El incidente fue corto y profundamente poco interesante—exactamente lo que quieres cuando hay dinero en juego.

El trabajo posterior fue igualmente aburrido: ajustaron la pipeline de upgrades para validar el éxito de la construcción de DKMS antes de reiniciar.
No es glamuroso, pero convierte una «actualización mala» en un «retraso menor».

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: prompt de GRUB o “grub rescue>” después de una actualización

Causa raíz: GRUB no puede encontrar su prefix/módulos o cambió la numeración de disco/partición.

Solución: Desde el rescate, localiza la partición que contiene /boot/grub, establece prefix, carga normal, arranca una vez y luego reinstala GRUB correctamente en todos los discos de arranque.

2) Síntoma: el kernel carga, luego cae a initramfs con “cannot import rpool”

Causa raíz: initramfs sin módulos/herramientas ZFS, zpool.cache roto, o dataset root mal especificado.

Solución: Chroot, instala/verifica la integración ZFS en initramfs, reconstruye initramfs, asegura que root=ZFS=... apunte a un dataset real, regenera GRUB.

3) Síntoma: el ISO live no puede importar pool y se queja de features no soportadas

Causa raíz: el OpenZFS del entorno de rescate es más antiguo que el conjunto de features del pool.

Solución: Usa una imagen de rescate más nueva o instala paquetes ZFS más recientes en el entorno live. No fuerces la importación de forma que arriesgues corrupción.

4) Síntoma: arranca solo cuando está presente un disco específico

Causa raíz: ESP/GRUB instalado en un solo disco; el firmware cambia el orden de arranque al otro.

Solución: Instala el bootloader en ambos discos y mantiene las ESP sincronizadas; confirma entradas UEFI y rutas de fallback.

5) Síntoma: ZFS se importa en rescue, pero el sistema falla luego con errores de montaje

Causa raíz: propiedades de dataset incorrectas (mountpoint, canmount), o bootfs apunta al dataset/clone equivocado.

Solución: Revisa zfs get mountpoint,canmount, corrige la selección de dataset, configura bootfs, luego actualiza la config de arranque.

6) Síntoma: panic que menciona símbolos ZFS o errores de carga de módulos

Causa raíz: actualización de kernel sin la construcción/instalación correspondiente de módulos ZFS (fallo DKMS, actualización de paquete parcial).

Solución: Arranca un kernel más antiguo desde GRUB si está disponible; si no, chroot, reinstala zfs-dkms/zfsutils, reconstruye módulos e initramfs.

7) Síntoma: el pool se importa pero se exporta inmediatamente o se niega por “hostid mismatch”

Causa raíz: imagen clonada reutilizó hostid, o /etc/hostid cambió inesperadamente.

Solución: Confirma /etc/hostid en el sistema instalado, corrígelo si es necesario, y regenera initramfs para que el arranque temprano use la identidad correcta.

8) Síntoma: “No such device” para vmlinuz/initrd en GRUB

Causa raíz: /boot no montado en el momento de la actualización; initramfs y kernels escritos en otro sitio, o mismatch en datasets de bpool.

Solución: Monta bpool correctamente, vuelve a ejecutar update-initramfs y grub-mkconfig; verifica la presencia de archivos en /boot.

Listas de verificación / plan paso a paso

Checklist de recuperación (haz esto en orden, detente cuando el sistema arranque)

1. Identifica el modo de arranque: UEFI con ESP vs BIOS. Usa lsblk para detectar particiones vfat ESP.
2. Confirma la etapa de fallo: antes de GRUB, en GRUB, en initramfs, o más tarde.
3. Arranca un entorno de rescate compatible con herramientas ZFS cercanas al conjunto de features de tu pool.
4. Ejecuta zpool import y lee el error. No improvises.
5. Importa los pools en solo-lectura con -N para inspeccionar de forma segura.
6. Comprueba zpool status por mirrors degradados y miembros faltantes.
7. Encuentra el dataset root y el bootfs (zfs list, zpool get bootfs).
8. Monta root y chroot (bind /dev, /proc, /sys).
9. Reconstruye initramfs y valida que componentes ZFS estén incluidos.
10. Regenera la configuración de GRUB para que root=ZFS=... coincida con la realidad.
11. Reinstala el bootloader en el objetivo correcto:
    • BIOS: grub-install /dev/disk para cada disco de arranque.
    • UEFI: monta la ESP, grub-install --target=x86_64-efi ..., verifica con efibootmgr.
12. Reinicia una vez y observa. Si falla, captura el mensaje exacto y vuelve al modelo de cadena de fallo.

Checklist de prevención (tu yo del futuro merece cosas buenas)

• Crea un snapshot pre-upgrade del dataset raíz y usa una convención de nombres clara para las 3 AM.
• Valida que las construcciones DKMS/módulos finalicen con éxito antes de programar un reinicio.
• Mantén al menos un kernel anterior conocido bueno en GRUB.
• En arranques en espejo, instala/actualiza artefactos EFI o GRUB en ambos discos, no solo en «el que está montado hoy».
• Almacena un ISO de rescate (o opción de netboot) que pueda importar las features de tu pool. Actualízalo cuando cambies features.
• Documenta el layout de tu pool: qué particiones pertenecen a bpool/rpool, dónde vive la ESP y el bootfs esperado.

Preguntas frecuentes

1) ¿Siempre necesito un pool de arranque separado (bpool)?

No, pero es una apuesta pragmática. Un pool de arranque separado puede mantener /boot en un conjunto de features ZFS que los bootloaders manejan bien.
Si tu plataforma arranca sin problemas desde el pool raíz y controlas estrictamente la habilitación de features, un solo pool puede funcionar.
Si quieres rutas de rescate fiables, la separación suele valer la pequeña complejidad adicional.

2) ¿Por qué importar los pools en solo-lectura primero?

Porque el pánico hace que la gente escriba comandos destructivos. La importación solo-lectura te permite inspeccionar datasets, snapshots y salud sin comprometer cambios.
Una vez entiendas el fallo, remonta en modo lectura-escritura para reparaciones dirigidas.

3) Mi ISO de rescate no puede importar por features no soportadas. ¿Puedo «forzarlo»?

No lo hagas. Las features no soportadas significan que el software literalmente no entiende partes del formato en disco.
Tu solución es usar herramientas OpenZFS más nuevas, no apostar con tu pool raíz.

4) Si GRUB muestra el menú, ¿significa que mi bootloader está bien?

Significa que GRUB al menos se está ejecutando. Aún puedes tener rutas de kernel/initrd rotas, root=ZFS= incorrecto,
o una historia de módulos ZFS faltantes que aparece luego en initramfs.

5) ¿Cómo sé qué dataset debe arrancar?

Revisa zpool get bootfs rpool. Luego confirma que el dataset exista con zfs list.
Si usas múltiples entornos de arranque, el previsto suele reflejarse también en las entradas de GRUB.

6) ¿Cuál es la rotura más común tras una “mala actualización” en ZFS root?

Desajuste entre kernel y módulo ZFS. El kernel se actualiza, DKMS falla en silencio y initramfs arranca sin capacidad para importar ZFS.
La solución típica es: chroot, reparar paquetes, reconstruir initramfs y regenerar GRUB.

7) ¿Necesito exportar los pools antes de reiniciar desde rescue?

Idealmente, sí: zpool export rpool y zpool export bpool después de terminar, para que el siguiente arranque importe limpiamente.
Si usaste import solo-lectura y vas a reiniciar inmediatamente, sigue siendo buena higiene, especialmente en sesiones de rescate complejas.

8) ¿Puedo recuperar haciendo rollback de snapshots aunque el arranque esté roto?

A menudo sí, porque el rollback puede hacerse desde rescue tras importar el pool. La clave es revertir el dataset raíz correcto
y luego asegurarse de que los artefactos de arranque (initramfs/GRUB/EFI) coincidan con el estado restaurado.

9) ¿Por qué ZFS en espejo no garantiza arranque en espejo?

ZFS replica tus datos ZFS. El firmware arranca desde ubicaciones ESP/MBR/bootloader que pueden no estar replicadas a menos que lo asegures.
Trata la «redundancia de arranque» como un requisito de ingeniería separado.

10) ¿Debo habilitar nuevas feature flags ZFS en mi pool de arranque?

Sé conservador. Los pools de arranque existen para arrancar, no para ser cutting-edge. Habilita features en el pool raíz cuando las necesites,
y solo después de confirmar que tus bootloaders y herramientas de rescate aún funcionan.

Conclusión: qué hacer la próxima vez (antes de que sean las 2 AM)

La recuperación del pool de arranque ZFS no es magia negra. Es una secuencia: identifica la etapa de fallo, importa de forma segura, verifica el dataset de arranque previsto,
y luego repara exactamente lo que está roto—bootloader, initramfs o alineación de paquetes.

Pasos prácticos que deberías realizar en un sistema sano:

• Apunta el layout de tus pools (bpool/rpool, ESPs, mapeo de discos) y guárdalo con tus runbooks.
• Automatiza snapshots pre-upgrade y convierte el rollback en una opción de primera clase.
• Asegura que los artefactos de arranque se instalen en todos los discos arrancables, no solo en el que el OS montó ese día.
• Mantén un entorno de rescate conocido bueno que pueda importar las features de tu pool—y renuévalo cuando cambies features.
• Prueba la ruta de «actualización fallida» en un host no crítico: rómpelo intencionalmente, recupéralo deliberadamente y cronometra el proceso.

Cuando la próxima actualización se tuerza, quieres menos sorpresas y más tickets con pruebas. Los sistemas no premian el optimismo. Premian la preparación.