Please help me understand boot environments

[Vexz]

So with ZFS file system and bectl we can easily create snapshots of our system and always go pack to the point of time when we took the snapshot. I am familiar with snapshots with BTRFS but on OPNsense I'm very confused about them.

Here's the thing. In my experience all changes after the latest snapshot are saved and the latest snapshot + changes is the current status after a reboot. When I create a new snapshot with bectl, the active snapshot stays the currently running snapshot - not the latest snapshot.
What happens if I take a snapshot, do some changes on the system, then activate the new snapshot and reboot? Are my changes gone because I bootet into the snapshot I made before rebooting the system? Or are the changes applied to the latest snapshot? Or are my changes maybe gone?

I just can't wrap my head around it. It gives me headache the more I think about it and try to understand. Could you please explain to me how this works? In case I ever have to revert back to an old snapshot I wanna make sure to make it right.

[Patrick M. Hausen]

What happens if I take a snapshot, do some changes on the system, then activate the new snapshot and reboot? Are my changes gone because I bootet into the snapshot I made before rebooting the system?

Exactly. Although the "current snapshot" (if you want to phrase it that way) still exists and if you reboot a second time into that, your changes are back.

The boot environments are really snapshot backed r/w clones. The active one, too. So you can boot back and forth as you desire. Each BE keeps the changes you make while the BE is active.

HTH,
Patrick

[Vexz]

Aah! I think I get it now. So I can view the snapshots as some kind of individual "sessions" that I can boot into and they always keep all their changes.

Thank you very much for the clarification. :)

[Jose]

Hi, some time ago I've  created a TUI wrapper around beadm/bectl to ease the Boot Environments backups(exports) to either local or remote servers through SSH.

Each time I upgrade either FreeBSD and OPNsense to a major version I backup the current BE to my server and and after backup completes I create a new BE and reboot into it to perform the upgrade.

Here is the little utility: Bemanager
Here is the source: Bemanager at GitHub
There is no manual on how to configure it but the sample config have some hints.

Notes:
Be aware that after upgrading to a major version, if the user upgrades the bootcode GPT/BIOS/EFI, in order to rollback to a previous BE, the user must mount the previous BE containing the older bootcode and perform a downgrade from its files under "/boot", however if the user upgrades the ZFS pool feature flags, this may lock-down the ability to easily rollback to a previous BE*.

*The solution is to backup the wanted previous BE, then reinstall a FreeBSD/OPNsense version matching the previous version then import back the Boot Environment regardless of the disk layout, e.g. I've exported a BE from a single disk to later import that BE to a mirrored setup with good results.

Unfortunately haven't enough time to read the plugin development manual to make an Boot Environments manager plugin for the OPNsense GUI to perform basic tasks from.

ZFS Boot Environments Reloaded by Sławomir Wojciech Wojtczak (vermaden)

Regards

[Patrick M. Hausen]

Boot loaders are at least supposed to always be backwards compatible. If you ever upgrade your zpool, you need to upgrade your boot loader, too. But a downgrade should never be necessary.

[Jose]

Boot loaders are at least supposed to always be backwards compatible. If you ever upgrade your zpool, you need to upgrade your boot loader, too. But a downgrade should never be necessary.

Yeah it just happens that I've ran into boot issues/broken EFI console in the past and and I'm still skeptical about bootcode upgrade, though I think I should make some testing on VM's in this regards.

Also agreed that a downgrade should never happens, but sometimes jumping into bleeding edge makes you wanting to rollback when you later discover that something can't be easily fixable on time.

Regards

[Vexz]

I figured I'd use my old topic (this one right here) to ask another question about boot environments.

So yesterday I deleted an old snapshot with the -o parameter to delete the origin.
Used command:

Code Select Expand

bectl destroy -o <snapshot>
Actually I couldn't find out exactly what it means to "delete the origin" but everyone says you should always do it because there's no reason why you wouldn't want that.
Now after I deleted the old snapshot and rebooted my OPNsense many configurations were gone and I was on an old configuration state.

Do you think that happened because of the deleted origin? Will it keep my latest configurations if I don't delete the origin of snapshots?

[Alessandro Del Prete]

Hi, some time ago I've  created a TUI wrapper around beadm/bectl to ease the Boot Environments backups(exports) to either local or remote servers through SSH.

Each time I upgrade either FreeBSD and OPNsense to a major version I backup the current BE to my server and and after backup completes I create a new BE and reboot into it to perform the upgrade.

This should be integrated in the OPNsense update process. But a plugin would suffice too...maybe @mimugmail could help. :)

Questions:

1. If I understood correctly the BEs will also appear in the FreeBSD loader right? This is fantastic.
2. I'm reading the sample config file, but some options are not really clear, ins there any additional doc I can read about those with some examples for their usage?
3. Is there a substantial difference between bectl vs beadm?

Thanks a lot for your work Jose, hope this can become an integrated plugin one day.

[Patrick M. Hausen]

I explained the whole mechanism here:
https://forum.opnsense.org/index.php?topic=25540.msg122731#msg122731

beadm is the old deprecated tool that was created as a copy of Solaris beadm and available as a port/package. bectl is the new official one in the FreeBSD base system.

[Alessandro Del Prete]

Thank you so much for that post.

I would still like to test Jose's script/menu so will also wait for his reply, but it's nice to know how it works, thanks again.

[cookiemonster]

Would a test inside a VM not work for you?
I for one fail to see what would be the benefit of creating a plugin for it. It is a single file download and the single-line to get it installed is already provided.

[Alessandro Del Prete]

I didn't think of a plugin for the installation, but for the management part. The menu, etc.

I think that if OPNsense installation is made with ZFS, this kind of functionality should be part of the main functionalities, or at least as an official plugin. But it's just my personal opinion. :)

[Alessandro Del Prete]

I explained the whole mechanism here:
https://forum.opnsense.org/index.php?topic=25540.msg122731#msg122731

I finally had the chance to test the process you described with 23.1 final. I didn't dare to try rebooting to 23.1r2 though. :)

I think it's much easier from shell vs bemanager, the only thing I'd like to do is backing up these snaps to an external NFS share, and what is the process if I wanted to restore it from there, in case the hw fails completely. After all these snaps live on the local ssd storage.

Thank you again for explaining the process, it's an invaluable functionality, IMHO.

[36thchamber]

is this somewhere in menu, with snap actions defined after ①update, ②boot, ③package install? Or at least an action.d item? It only makes sense if this is defined somewhere I guess.

[Patrick M. Hausen]

It's all command line tools, most importantly bectl.