En corto

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.