Boot Environments en FreeBSD con bectl: guía práctica desde cero

Las tres capas de seguridad

CAPA 3 Boot Environment bectl create -r

Sistema completo arrancable. El rollback "nuclear": si todo falla, arrancas desde el BE anterior y listo.

▼

CAPA 2 Script de rollback rollback-whitesur.sh

Dataset por dataset, con dry-run y confirmación interactiva. El rollback quirúrgico.

▼

CAPA 1 Snapshot ZFS zfs snapshot -r

Todo el árbol en segundos. La red de seguridad instantánea antes de tocar nada.

Tres capas que se complementan y cubren escenarios distintos.

Versión del documento: 1.0
Ámbito: FreeBSD 12+ con ZFS (con notas para 13/14/15)
Caso práctico conductor: proteger el sistema antes de instalar el tema WhiteSur en XFCE

Índice

1. Introducción
2. Conceptos clave
3. Crear un BE
4. Listar e inspeccionar
5. Montar un BE
6. Activar un BE
7. Integración con el cargador de arranque
8. Destruir y limpiar
9. Renombrar y otras operaciones
10. Caso práctico completo: WhiteSur en XFCE
11. Tabla resumen de comandos
12. Apéndice: beadm para quien venga de ahí

1. Introducción

1.1 Qué es un Boot Environment

Un Boot Environment (BE) es una copia completa y coherente del sistema operativo (y, opcionalmente, de los datos que tú decidas) que puedes arrancar como si fuera el sistema real. Internamente, un BE no es una copia física: es un clon ZFS de un snapshot, lo que significa que:

• Ocupa muy poco espacio inicialmente (solo los bloques que cambian respecto al snapshot original).
• Es atómico: se crea en una sola operación, sin estados intermedios.
• Es reversible: puedes volver al estado anterior en segundos.

La idea es la misma que los "boot environments" de Solaris/illumos o los snapshots de sistema de otras plataformas: una red de seguridad de bajo coste y alta fiabilidad.

1.2 bectl vs beadm: la transición al estándar moderno

Históricamente, la herramienta de gestión de BEs en FreeBSD era beadm, instalada desde ports. A partir de FreeBSD 12, el sistema base incluye bectl, llamada a ser su reemplazo definitivo. Las diferencias prácticas son importantes:

Aspecto	beadm (legacy)	bectl (moderno)
Origen	Port (pkg install beadm)	Sistema base
Recursivo por defecto	✅ Sí	❌ No (requiere -r)
Confirmación al destruir	✅ Sí	❌ No (cuidado)
Estado	Mantenido por la comunidad	Estándar oficial

⚠️ Advertencia clave: el hecho de que bectl no sea recursivo por defecto es la diferencia más importante que debes interiorizar. Si vienes de beadm, esto te puede pillar desprevenido. Lo detallamos en la sección 2.

1.3 Requisitos

• FreeBSD con el sistema raíz sobre ZFS.
• Versión 12.0 o superior (para tener bectl en el sistema base).
• El script /etc/rc.d/zfsbe presente para la integración con el cargador de arranque (lo está por defecto en versiones modernas).
• Privilegios de root para la mayoría de operaciones.

Comprobación rápida del entorno:

# Verificar que ZFS está activo y cuál es el pool raíz
zpool list
zfs list

# Verificar que bectl está disponible
bectl --version 2>/dev/null || which bectl

# Verificar el script de integración con el loader
ls -l /etc/rc.d/zfsbe

2. Conceptos clave

2.1 Relación entre BE, snapshot ZFS y clon

Un BE se compone de tres piezas:

1. Snapshot ZFS: una "foto" inmutable del dataset en un instante concreto.
2. Clon ZFS: un dataset nuevo que comparte los bloques del snapshot y solo diverge cuando se escribe en él (copy-on-write).
3. Entrada en el menú de arranque: el loader de FreeBSD detecta los clones y te permite elegir cuál arrancar.

Cuando ejecutas bectl create mi-be, internamente se hace algo equivalente a:

zfs snapshot zroot/ROOT/default@mi-be
zfs clone zroot/ROOT/default@mi-be zroot/ROOT/mi-be

(Los nombres exactos varían según la configuración, pero la lógica es esta.)

2.2 El matiz del -r: beadm era recursivo, bectl no

Este es el punto que más confusión genera y el que tienes que tener grabado a fuego.

• beadm create mi-be: creaba un snapshot recursivo (zfs snapshot -r) y un clon de todos los datasets bajo el punto de montaje raíz. Esto incluía zroot/usr/home, zroot/var/log, etc. Tu home quedaba protegido automáticamente.
• bectl create mi-be: solo actúa sobre el dataset de nivel superior del BE (normalmente zroot/ROOT/default). Tu home NO se incluye.
• bectl create -r mi-be: replica el comportamiento de beadm, incluyendo recursivamente todos los datasets hijos.

Implicación práctica: si quieres que tu directorio personal (/usr/home) quede protegido en el BE, debes usar -r. Esto es especialmente importante en el caso de WhiteSur, porque el tema se instala en ~/.themes.

# Solo protege el sistema base
sudo bectl create antes-whitesur

# Protege el sistema base Y el home
sudo bectl create -r antes-whitesur

2.3 Arrancar desde un BE vs activar un BE

Son dos operaciones distintas y conviene no confundirlas:

• Arrancar desde un BE (selección puntual en el menú del loader): afecta solo a este arranque. En el siguiente reinicio, volverás al BE por defecto.
• Activar un BE (bectl activate): cambia el BE por defecto de forma permanente (hasta que lo cambies otra vez).

Esto te da dos modos de uso:

• Modo "prueba": seleccionas el BE en el menú del loader, compruebas que funciona, y si te convence, lo activas.
• Modo "rollback": activas directamente el BE anterior y reinicias. El BE roto queda como "el otro" por si acaso.

3. Crear un BE

3.1 Creación básica (solo sistema base)

sudo bectl create antes-whitesur

Esto crea un BE llamado antes-whitesur a partir del estado actual de zroot/ROOT/default. No incluye /usr/home, /var/log, ni otros datasets hijos.

3.2 Creación recursiva (sistema + home + resto)

sudo bectl create -r antes-whitesur

Este es el comando que debes usar si quieres una red de seguridad completa, como la que ofrecía beadm por defecto. Incluye recursivamente todos los datasets bajo el punto de montaje raíz.

3.3 Cuándo usar cada uno

Escenario	Comando recomendado
Solo vas a tocar el sistema base (kernel, drivers, actualizaciones)	bectl create nombre
Vas a instalar software que escribe en tu home (temas, dotfiles)	bectl create -r nombre
Quieres una red de seguridad "total" antes de algo riesgoso	bectl create -r nombre
Quieres un BE mínimo para pruebas rápidas de kernel	bectl create nombre

3.4 Verificación inmediata

bectl list

Deberías ver el nuevo BE en la lista. Si usaste -r, también puedes verificar los datasets incluidos:

bectl list -a

O directamente con ZFS:

zfs list -r zroot/ROOT

4. Listar e inspeccionar

4.1 bectl list: interpretación de columnas

bectl list

Salida típica:

BE               Active Mountpoint Space Created
default          NR     /          12.5G 2026-11-10 09:00
antes-whitesur   -      -          245M  2026-11-11 12:30

Columna	Significado
BE	Nombre del Boot Environment
Active	N = activo ahora, R = activo en el próximo arranque, - = inactivo
Mountpoint	Punto de montaje (solo si está montado)
Space	Espacio que ocupa (incluye lo compartido con otros BEs)
Created	Fecha de creación

4.2 bectl list -a: todos los datasets incluidos

bectl list -a

Muestra, para cada BE, todos los datasets que lo componen. Es la forma de confirmar que tu home está o no incluido.

4.3 Comparación con zfs list

Para ver los clones ZFS subyacentes:

zfs list -r -t all zroot/ROOT

Verás los datasets zroot/ROOT/default, zroot/ROOT/antes-whitesur, y sus snapshots asociados.

5. Montar un BE

Esta es, probablemente, la funcionalidad más útil y menos conocida de bectl. Te permite inspeccionar, reparar o extraer archivos de un BE sin arrancar desde él.

5.1 Montar

sudo bectl mount antes-whitesur

Salida:

/tmp/be_mount.XXXX

Ese directorio temporal contiene el BE montado en modo lectura-escritura. Puedes navegar por él como si fuera tu sistema:

ls /tmp/be_mount.XXXX/etc
cat /tmp/be_mount.XXXX/etc/rc.conf

5.2 Casos de uso típicos

• Recuperar un archivo borrado: si borraste accidentalmente algo y el BE anterior lo tiene, puedes copiarlo desde el montaje.
• Revisar logs del estado anterior: comparar /var/log del BE con el actual.
• Reparar configuración: si el sistema no arranca porque rompiste /etc/fstab o /etc/rc.conf, puedes editar el archivo desde el BE montado.
• Inspeccionar un BE sospechoso: antes de arrancar desde él, verificar que tiene lo que esperas.

5.3 Desmontar

sudo bectl umount antes-whitesur

O especificando el punto de montaje:

sudo umount /tmp/be_mount.XXXX

5.4 bectl jail: ejecutar comandos dentro del BE

Una variante muy potente: en lugar de montar y editar a mano, puedes ejecutar un comando dentro del BE como si fuera un jail:

sudo bectl jail antes-whitesur

Esto te deja en una shell dentro del BE. Desde ahí puedes:

• Regenerar la configuración de red.
• Reparar paquetes con pkg.
• Recompilar el kernel.
• Ejecutar freebsd-update sobre ese BE.

Salir con exit desmonta y limpia automáticamente.

Nota: bectl jail requiere que el BE no esté activo. Es una herramienta de reparación, no de uso diario.

6. Activar un BE

6.1 Activación permanente

sudo bectl activate antes-whitesur

En el próximo arranque, el sistema usará antes-whitesur como BE por defecto. Verifica con:

bectl list

La columna Active mostrará R en antes-whitesur y N en el actual hasta que reinicies.

6.2 Activación temporal (solo próximo arranque)

sudo bectl activate -t antes-whitesur

Esto es oro puro para pruebas: el próximo arranque usará antes-whitesur, pero si no te convence, el siguiente volverá al BE original. Ideal para:

• Probar un rollback en un servidor remoto sin riesgo.
• Validar que un BE recién creado arranca correctamente.
• Hacer cambios experimentales sin compromiso.

6.3 Verificar cuál se usará en el próximo arranque

bectl list

La columna Active te lo dice: R marca el que se usará en el próximo arranque.

7. Integración con el cargador de arranque

7.1 El menú automático

Si tu sistema arranca desde ZFS y /etc/rc.d/zfsbe está presente, el loader de FreeBSD añade automáticamente una entrada al menú (típicamente la opción #7, "Boot Environments") que lista todos los BEs disponibles.

Flujo típico:

1. Reinicias.
2. En el menú del loader, seleccionas la opción de Boot Environments.
3. Eliges el BE que quieres arrancar.
4. El sistema arranca desde ese BE solo para esta vez (a menos que luego lo actives).

7.2 Selección puntual sin cambiar el BE por defecto

Esta es la combinación más segura para probar un rollback:

1. Arrancas desde el BE anterior vía menú del loader.
2. Compruebas que todo funciona.
3. Si te convence, sudo bectl activate antes-whitesur y reinicias.
4. Si no, reinicias normalmente y vuelves al BE original.

7.3 Solución de problemas

El menú de BEs no aparece:

• Verifica que /etc/rc.d/zfsbe existe y es ejecutable.
• Comprueba que /boot/loader.conf tiene zfs_load="YES".
• Revisa que el pool ZFS es arrancable (zpool get bootfs).

El sistema se cuelga al seleccionar un BE:

• Puede ser un problema del propio BE (kernel corrupto, fstab mal).
• Alternativa robusta: arrancar en el BE por defecto y usar bectl activate desde ahí.

8. Destruir y limpiar

8.1 Destruir un BE

sudo bectl destroy antes-whitesur

⚠️ Crítico: bectl destroy no pide confirmación. Un typo y adiós BE. Verifica siempre el nombre con bectl list antes de ejecutar.

8.2 Destruir forzando

sudo bectl destroy -F antes-whitesur

La -F fuerza el desmontaje y la destrucción incluso si hay problemas. Útil en scripts, peligroso en uso interactivo.

8.3 Qué NO puedes destruir

• El BE activo (N en la columna Active): el sistema no te deja, obviamente.
• El BE que se usará en el próximo arranque (R): tampoco, hasta que cambies la activación.

8.4 Estrategia de limpieza periódica

Los BEs consumen espacio (aunque poco, gracias a copy-on-write). Una rutina saludable:

# 1. Ver todos los BEs y su espacio
bectl list

# 2. Identificar los que ya no necesitas (por fecha, por nombre)
# 3. Destruir los antiguos, uno por uno
sudo bectl destroy nombre-viejo

# 4. Verificar el espacio liberado
zfs list -o name,used,refer

Regla práctica: mantén 2-3 BEs como máximo (el actual, el anterior estable, y quizás uno de "por si acaso"). Más que eso es acumular basura.

9. Renombrar y otras operaciones

9.1 Renombrar un BE

sudo bectl rename nombre-viejo nombre-nuevo

Útil para poner nombres descriptivos (antes-whitesur → pre-whitesur-2026-11).

9.2 Export / Import (según versión)

Algunas versiones de bectl soportan export e import para mover BEs entre sistemas. Consulta man bectl para tu versión concreta, porque la disponibilidad varía.

9.3 bectl en scripts

Todos los comandos son aptos para scripting. Recomendaciones:

• Usa -F en destroy para evitar prompts.
• Verifica siempre con bectl list antes de operaciones destructivas.
• Combina con zfs list para monitorizar espacio.

10. Caso práctico completo: WhiteSur en XFCE

Nota: esta sección usa WhiteSur como ejemplo de flujo de trabajo con BE + snapshot + rollback. La instalación del tema en sí se documenta en un artículo aparte (enlace en 10.2), porque el install.sh original no funciona en FreeBSD.

10.1 Fase 1: crear la red de seguridad

# Opción A: BE recursivo (protege sistema + home)
sudo bectl create -r antes-whitesur

# Opción B: snapshot ZFS adicional (cinturón y tirantes)
sudo zfs snapshot -r zroot@antes-whitesur

# Verificar
bectl list
zfs list -t snapshot | grep antes-whitesur

10.2 Fase 2: instalar el tema

⚠️ Importante: el script install.sh de WhiteSur no funciona en FreeBSD. Está diseñado para GNU/Linux y depende de herramientas como sed, readlink y setterm, que en FreeBSD se comportan de forma distinta y hacen que el script falle.

Para la instalación real, sigue la guía específica para FreeBSD, que explica el método manual (descarga de paquetes compilados y copia de iconos) paso a paso:

📖 Tutorial completo: Guía: Transforma FreeBSD y XFCE con el tema macOS WhiteSur (MacBook Pro 2012)

Resumen del método que describe la guía (para que tengas el contexto, pero sigue el enlace para los detalles):

• Tema GTK: descargar el .tar.xz compilado desde la página de Releases (no el "Source code") y extraerlo en ~/.themes/.
• Iconos: descargar el código fuente, copiar src/* a ~/.local/share/icons/WhiteSur/ y corregir el index.theme manualmente (el sed de FreeBSD requiere -i '', y aun así el script original falla).

10.3 Fase 3: aplicar el tema en XFCE

1. Apariencia → Estilo: WhiteSur o WhiteSur-Dark (tema GTK).
2. Apariencia → Iconos: WhiteSur (paquete de iconos).
3. Gestor de ventanas → Estilo: WhiteSur (bordes de ventana).
4. Gestor de ventanas → Botones: arrastrar botones a la izquierda.

O por línea de comandos (solo el layout de botones):

xfconf-query -c xfwm4 -p /general/button_layout -s "O|HMC"

10.4 Fase 4a: si algo falla (rollback vía BE)

Escenario: XFCE no arranca o se ve fatal.

# 1. Reiniciar
# 2. En el menú del loader, seleccionar opción de Boot Environments
# 3. Elegir "antes-whitesur"
# 4. El sistema arranca en el estado anterior
# 5. Si todo va bien, activar permanentemente:
sudo bectl activate antes-whitesur
# 6. Reiniciar de nuevo

10.5 Fase 4b: si algo falla (rollback vía snapshot ZFS + script)

Escenario: prefieres un rollback quirúrgico solo del home.

# 1. Arrancar en single-user (opción 2 o 4 del loader)
# 2. Ejecutar el script de rollback
./rollback-whitesur.sh zroot/usr/home antes-whitesur --dry-run
./rollback-whitesur.sh zroot/usr/home antes-whitesur
# 3. Reiniciar

10.6 Fase 5: limpieza

Una vez confirmado que el sistema funciona con el tema (o sin él, tras el rollback):

# Destruir el BE que ya no necesitas
sudo bectl destroy antes-whitesur

# Destruir el snapshot ZFS si ya no lo necesitas
sudo zfs destroy -r zroot@antes-whitesur

10.7 Las tres capas de seguridad (resumen)

Capa	Herramienta	Alcance	Cuándo usarla
1	Snapshot ZFS (zfs snapshot -r)	Todo el árbol	Red de seguridad instantánea
2	Script rollback-whitesur.sh	Dataset por dataset	Rollback quirúrgico
3	Boot Environment (bectl create -r)	Sistema completo arrancable	Rollback "nuclear"

11. Tabla resumen de comandos

Acción	Comando	Notas
Crear BE (solo sistema)	sudo bectl create nombre	No incluye home
Crear BE (recursivo)	sudo bectl create -r nombre	Incluye home y resto
Listar BEs	bectl list	Ver columna Active
Listar datasets del BE	bectl list -a	Ver qué incluye cada BE
Montar BE	sudo bectl mount nombre	Devuelve punto de montaje
Desmontar BE	sudo bectl umount nombre	O umount /tmp/...
Jail en BE	sudo bectl jail nombre	Shell dentro del BE
Activar BE (permanente)	sudo bectl activate nombre	Próximo arranque en adelante
Activar BE (temporal)	sudo bectl activate -t nombre	Solo próximo arranque
Renombrar BE	sudo bectl rename viejo nuevo	—
Destruir BE	sudo bectl destroy nombre	⚠️ Sin confirmación
Destruir BE (forzado)	sudo bectl destroy -F nombre	Para scripts
Ver versión	bectl --version	—
Ayuda	man bectl	Documentación completa

12. Apéndice: beadm para quien venga de ahí

12.1 Tabla de equivalencias

Acción	beadm	bectl
Crear	beadm create nombre	bectl create nombre
Crear recursivo	beadm create nombre (ya lo es)	bectl create -r nombre
Listar	beadm list	bectl list
Montar	beadm mount nombre /mnt	bectl mount nombre
Desmontar	beadm umount nombre	bectl umount nombre
Activar	beadm activate nombre	bectl activate nombre
Activar temporal	(no soportado)	bectl activate -t nombre
Destruir	beadm destroy nombre	bectl destroy nombre
Destruir forzado	beadm destroy -F nombre	bectl destroy -F nombre

12.2 Diferencias de comportamiento a recordar

1. Recursividad: beadm era recursivo por defecto; bectl requiere -r.
2. Confirmación al destruir: beadm pedía confirmación; bectl no.
3. Activación temporal: bectl activate -t es una novedad muy útil que beadm no tenía.
4. bectl jail: funcionalidad nueva y potente para reparar BEs.
5. Integración en el sistema base: bectl no requiere instalación; beadm sí.

12.3 Migración práctica

Si tienes scripts con beadm, la migración a bectl requiere:

• Añadir -r a los create que deban ser recursivos.
• Añadir -F a los destroy que no deban pedir confirmación (o gestionar el prompt).
• Revisar la salida de list (el formato es ligeramente distinto).
• Aprovechar activate -t para pruebas.

Notas finales

• Versión de FreeBSD: en 14.x y 15.x, bectl es plenamente funcional y recomendado. En 12.x y 13.x también funciona, pero conviene consultar man bectl por si algún flag difiere.
• Documentación oficial: man bectl, man zfs, y el Handbook de FreeBSD (sección de ZFS y Boot Environments).
• Combinación recomendada: snapshot ZFS + BE recursivo + script de rollback. Las tres capas se complementan y cubren escenarios distintos.
• Higiene: revisa y limpia BEs antiguos periódicamente. Copy-on-write es eficiente, pero no infinito.

---

Fin del tutorial. Versión 1.0 — 2026-11-15.

FreeBSD es genial!