Safely upgrade to 22.1 beta and possibly roll back - boot environments FTW!

[Patrick M. Hausen]

Prerequisites

• Installation with ZFS
• Running 21.7.4

Show current boot environments - this is the state when you never have used boot environments before

Code Select Expand


root@opnsense:~ # bectl list
BE      Active Mountpoint Space Created
default NR     /          775M  2021-07-31 21:46


N means "active now"
R means "active on reboot"

Create a backup BE for 21.7.4 and rename the active one to 21.7.5

Code Select Expand


root@opnsense:~ # bectl create 21.7.4
root@opnsense:~ # bectl rename default 21.7.5
root@opnsense:~ # bectl list
BE      Active Mountpoint Space Created
21.7.4  -      -          71.3M 2021-11-11 18:24
21.7.5  NR     /          775M  2021-07-31 21:46


Now do your update to 21.7.5 in the UI as always. All changes will end up in the BE 21.7.5. If there is a problem with that and SSH is still working you can always do:

Code Select Expand


root@opnsense:~ # bectl activate 21.7.4
root@opnsense:~ # bectl list
BE      Active Mountpoint Space Created
21.7.4  R      -          71.3M 2021-11-11 18:24
21.7.5  N      /          775M  2021-07-31 21:46
root@opnsense:~ # shutdown -r now

and boot back into 21.7.4 as if nothing ever happenend.

With the update to 21.7.5 as a warm up exercise let's try the beta ...

Rename the active BE for the new version and create a backup BE for the current one

Code Select Expand


root@opnsense:~ # bectl rename 21.7.5 22.1.b1
root@opnsense:~ # bectl create 21.7.5
root@opnsense:~ # bectl list
BE      Active Mountpoint Space Created
21.7.4  -      -          775M  2021-11-11 18:24
21.7.5  -      -          71.3M 2021-11-11 19:07
22.1.b1 NR     /          2.15G 2021-07-31 21:46


Now upgrade to the beta knowing that you can always rollback to 21.7.5.

If SSH does not work for some reason, you can pick boot environments at the loader prompt when you connect to the console (serial/IPMI/VGA/...)

Happy beta testing!

Patrick

[franco]

Super, thanks for this! :)

[Patrick M. Hausen]

As if I had had a foreboding. 22.1.b1 breaks my PPPoE uplink. Although this is a private system, it's still "sort of" production - at least for me and all people in the household. So no time to debug this on this particular installation.

I rolled back to 21.7.5. But then half of my services would not start at boot. AdGuard, BIND, WireGuard ... all red in the dashboard. Although I could start all of them manually.

Does the update to 22.1 change major things in /var that might not be part of the boot environment?

The BE contains (and rolls back/forward when switching) all of / and the directories below except:

Code Select Expand


zroot/tmp         247375828     240 247375588     0%    /tmp
zroot/var/log     247657724  282136 247375588     0%    /var/log
zroot/var/crash   247375676      88 247375588     0%    /var/crash
zroot/var/audit   247375676      88 247375588     0%    /var/audit
zroot/usr/home    247375676      88 247375588     0%    /usr/home
zroot/var/mail    247375700     112 247375588     0%    /var/mail
zroot/usr/ports   247375676      88 247375588     0%    /usr/ports
zroot/var/tmp     247375676      88 247375588     0%    /var/tmp
zroot/usr/src     247375676      88 247375588     0%    /usr/src


Anyway, rolling back to 21.7.4, re-applying the update to 21.7.5. All up and well now. I'll check out the beta in my Vagrant environment first, I guess.

[franco]

22.1 discontinues clog-style logging under /var/log. That might be it.


Cheers,
Franco

[Patrick M. Hausen]

I disabled that right after installation of 21.7 ... but possibly.

[franco]

Nevertheless I made a note to look at this more. I'm all here for beta reports. :)


Cheers,
Franco

[mimugmail]

I didn't use BE but update went fine and I updated the community repo for FreeBSD13 so your AdGuard Home should upgrade and run too :)

Finally also Kibana and Elastic compile again.

[aks0811]

Is there a downloadable ISO for 22.1 b1?

[mrancier]

I didn't use BE but update went fine and I updated the community repo for FreeBSD13 so your AdGuard Home should upgrade and run too :)

Finally also Kibana and Elastic compile again.

Upgraded to the beta with your repo configured ,but getting this :

Updating mimugmail repository catalogue...
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:13:amd64/meta.txz: Not Found
repository mimugmail has no meta file, using default settings
pkg: https://opn-repo.routerperformance.net/repo/FreeBSD:13:amd64/packagesite.txz: Not Found
Unable to update repository mimugmail
Error updating repositories!

What would be the best way to fix it ?

[franco]

Is there a downloadable ISO for 22.1 b1?

Images (as well as stable packages) will be available with 22.1 release candidates.


Cheers,
Franco

[cookiemonster]

Thanks for showing how easy it could be to use Boot Environments.
Did you mean

Code Select Expand

root@opnsense:~ # bectl rename 21.7.5 22.1.b1
by any chance? I think so as it is what it shows when listing all BEs afterwards.

Code Select Expand


root@opnsense:~ # bectl rename 21.7.5 21.1.b1
root@opnsense:~ # bectl create 21.7.5
root@opnsense:~ # bectl list
BE      Active Mountpoint Space Created
21.7.4  -      -          775M  2021-11-11 18:24
21.7.5  -      -          71.3M 2021-11-11 19:07
22.1.b1 NR     /          2.15G 2021-07-31 21:46


[Patrick M. Hausen]

Yes, of course. I'll fix the original article, thanks.

I had already done all of this, then came up with the idea to write a forum post about it.  ;)

[benyamin]

I've been using ZFS BE in my HBSD builds for a while now.

I don't think much of the default ZFS install on FreeBSD or HBSD. Both /usr and /var are not placed under the pool root, which IMHO, is not justified.

To fix that, issue something akin to the following:

Code Select Expand

zfs rename -u zroot/usr zroot/ROOT/default/usr
zfs rename -u zroot/var zroot/ROOT/default/var

Then zfs list should show you the magic.  ;)

[Patrick M. Hausen]

I've been using ZFS BE in my HBSD builds for a while now.

I don't think much of the default ZFS install on FreeBSD or HBSD. Both /usr and /var are not placed under the pool root, which IMHO, is not justified.

This is intentional for /var - you are free to disagree with that decision. I don't.

But /usr is placed under the BE root. The /usr dataset is created with canmount=off, which means all files placed under /usr/bin|lib|... are in the BE. This configuration is necessary to facilitate keeping /usr/local, /usr/src, ... separate from the BE.

Kind regards,
Patrick

[benyamin]

But /usr is placed under the BE root. The /usr dataset is created with canmount=off, which means all files placed under /usr/bin|lib|... are in the BE. This configuration is necessary to facilitate keeping /usr/local, /usr/src, ... separate from the BE.

That is true and worth pointing out.

I should have said "in the context of an appliance"... 8^d

In that context, I don't think there is any advantage to keeping /var and /usr/X datasets separate from the BE. In my experience, I prefer /usr/local, /var/db/pkg, etc. to be protected under the BE. The same for /usr/src and /usr/ports if running HBSD debug kernels with INVARIANTS.

If I'm developing an appliance, and the need arises for a persistent mount outside the BE, I use a separate partition for that purpose, e.g. a src repo that survives snapshot reversions.

The rename commands I posted are just the quickest means to an end. You could certainly be more creative.

If it was a workstation / desktop install, maybe a server (depending on purpose), I would feel differently about it.

Also, I thought it worth mentioning that I found beadm more mature than bectl, but it's been a while since I checked out the latter.