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.

1
2
3
4
5
6
7
8
9

pfctl -sT                                    # tablas cargadas
pfctl -t <tabla> -T show                     # contenido
pfctl -t <tabla> -T add 192.168.1.10         # añadir IP o red (también 10.20.0.0/16)
pfctl -t <tabla> -T delete 192.168.1.10
pfctl -t <tabla> -T test 192.168.1.10        # ¿está dentro? (match / no match)
pfctl -t <tabla> -T flush                    # vaciar la tabla
pfctl -t <tabla> -T replace -f /ruta/lista   # reemplazar todo el contenido desde un archivo

pfctl -t sshguard -T flush                   # pfSense: quitar el bloqueo por intentos de login fallidos

Qué es una tabla

Una tabla de PF es un conjunto de direcciones y redes al que las reglas hacen referencia como <nombre>. Se cambia en caliente, sin recargar el ruleset, y aguanta miles de entradas con búsqueda rápida; por eso PF la usa para listas de bloqueo, bogons y cualquier cosa que cambie más a menudo que las reglas.

En pf.conf:

1
2

table <blocklist> persist file "/etc/pf/blocklist.txt"
block in quick from <blocklist>

persist mantiene la tabla aunque ninguna regla la use en ese momento; file la carga desde un archivo (una IP o red por línea).

Comandos

Todos con la forma pfctl -t <tabla> -T <comando>:

Y sin -t:

1
2
3
4

pfctl -sT                    # nombres de todas las tablas
pfctl -vvsT                  # info global por tabla: entradas, evaluaciones, referencias
pfctl -T load -f /etc/pf.conf   # recarga solo las definiciones de tabla del pf.conf
pfctl -sr | grep '<nombre>'  # qué reglas usan una tabla

Tablas en pfSense

• Los aliases son tablas. Un alias de tipo Host, Network o URL Table llamado Admins existe en PF como <Admins>; pfctl -t Admins -T show te enseña lo que resolvió pfSense, incluidos los FQDN que ya convirtió a IPs.
• sshguard: donde caen las IPs bloqueadas por intentos de login fallidos a SSH o a la webGUI. Si te bloqueaste a ti mismo, pfctl -t sshguard -T flush (documentado por Netgate en Locked out of the WebGUI).
• virusprot: hosts bloqueados por superar los límites Max. src. conn. rate o Max. states de una regla. pfctl -t virusprot -T show y -T delete <ip> para soltar a uno.
• snort2c: bloqueos de Snort/Suricata en modo legacy. -T flush para desbloquear todo.
• bogons / bogonsv6: las listas que se actualizan solas cuando activas Block bogon networks en una interfaz.
• pfBlockerNG: cada lista es un alias pfB_*. Para saber si una IP está bloqueada por alguna: pfctl -t pfB_Top_v4 -T test 203.0.113.7.

En OPNsense la mecánica es la misma (pfctl -sT para ver los nombres); la tabla de bloqueo por login se llama sshlockout.

Lo que se pierde al recargar

Cualquier -T add, -T delete o -T flush vive hasta la siguiente recarga del filtro: guardar casi cualquier cosa en la GUI, Filter Reload en Status → Filter Reload, o el cron de actualización de aliases. En ese momento pfSense regenera cada tabla desde su alias y tus cambios a mano desaparecen. Para que algo sea permanente, edita el alias; para pruebas rápidas y desbloqueos, pfctl es perfecto.

Más allá de las tablas

Lo que más se usa junto a lo anterior:

1
2
3
4
5
6
7

pfctl -sr                    # reglas cargadas (con -vv, contadores y números de regla)
pfctl -ss                    # tabla de estados
pfctl -si                    # estadísticas globales
pfctl -k 192.168.1.10        # matar los estados de un host
pfctl -F states              # matar todos los estados (corta todas las conexiones)
pfctl -d / pfctl -e          # desactivar / activar PF (sin PF no hay NAT: úsalo solo para salir de un bloqueo)
pfctl -nf /etc/pf.conf       # comprobar sintaxis sin cargar

Referencia completa: pfctl cheat sheet del OpenBSD Handbook y man pfctl en FreeBSD.

Desde la consola (opción 8) o Diagnostics → Command Prompt:

1
2
3
4
5
6

certctl rehash
pkg-static clean -ay
pkg-static install -fy pkg
pkg-static install -xfy pfSense-repo pfSense-upgrade
pkg-static update -f
pfSense-upgrade -d -c        # muestra qué versión ofrece la rama configurada

Con pkg vivo otra vez, termina la actualización pendiente por System → Update (o pfSense-upgrade -d), no con pkg upgrade.

El error

1

ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

Lo verás al hacer pkg update, al instalar un paquete, o de forma indirecta: System → Package Manager aparece vacío y System → Update no puede comprobar versiones. A veces el binario que se queja es pfSense-repoc en vez de pkg; es el mismo problema.

Por qué pasa

pfSense es FreeBSD, y pkg es un binario enlazado dinámicamente contra la libssl del sistema. Cuando el repositorio configurado corresponde a una versión de pfSense construida sobre un FreeBSD más nuevo, sus paquetes vienen enlazados contra un OpenSSL más nuevo (libssl.so.30 = OpenSSL 3). Si pkg, o pfSense-repoc, se actualiza desde ese repo antes que el sistema base, el binario nuevo pide una biblioteca que en tu instalación todavía no existe.

Cómo se llega ahí:

• Un pkg upgrade a mano desde la shell. En pfSense no se hace nunca.
• Instalar o reinstalar un paquete después de cambiar la Branch en System → Update a una versión mayor, sin haber actualizado.
• Una actualización interrumpida a medias (fue típico en el salto 2.7.0 → 2.7.1/2.7.2, cuando la base cambió a OpenSSL 3).
• En pfSense Plus, volver a un boot environment anterior con el repo apuntando al nuevo (Redmine #15070).

El nombre de la biblioteca cambiará con las versiones; la mecánica y el arreglo son los mismos.

Arreglo

pkg-static es la copia de pkg enlazada estáticamente: no necesita libssl y por eso funciona cuando pkg no.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. Que pkg-static pueda hablar TLS con el repo (vale hasta el siguiente reinicio)
certctl rehash

# 2. Tirar la caché y reinstalar pkg y la configuración del repo
pkg-static clean -ay
pkg-static install -fy pkg
pkg-static install -xfy pfSense-repo pfSense-upgrade   # -x: regex, así entra también pfSense-repoc

# 3. Refrescar metadatos y comprobar
pkg-static update -f
pfSense-upgrade -d -c

Si pkg-static update sigue fallando, pkg-static -d update da la traza completa (certificados, DNS, rama equivocada).

Antes del paso 3 revisa la Branch en System → Update: debe ser la versión a la que quieres ir, no una intermedia. Y termina el trabajo por la GUI o con pfSense-upgrade -d: un pkg upgrade suelto te deja a medio camino otra vez.

Si el sistema base está tan mezclado que ni así arranca, el último recurso documentado por Netgate es pkg-static upgrade -f (reinstala todo), y tras eso reiniciar.

Trampas

• pkg upgrade no existe en pfSense. El único camino soportado es System → Update / pfSense-upgrade. Toda esta situación nace de saltárselo.
• Respaldo antes: Diagnostics → Backup & Restore. Con ZFS, además un boot environment (System → Boot Environments) te deja volver atrás en un reinicio.
• No copies libssl.so.30 de otro FreeBSD. Circula como truco; deja el sistema con bibliotecas de dos versiones y rompe la siguiente actualización.
• Paquetes primero, no. Con una actualización pendiente, actualiza el sistema y luego instala paquetes, no al revés.
• El repo y el upgrade usan HTTPS: si certctl rehash no basta, revisa hora del sistema y DNS del firewall.

Referencia: Upgrade Troubleshooting en la documentación de Netgate.