Updating FreeBSD With ZFS Boot Environments (beadm)

(Disclaimer: I'm a noob. Structure your replies accordingly.)

I installed FreeBSD 13.0-RELEASE last fall with the help of this forum. I haven't updated the computer since then, and have basically just ensured that, with my current install, the OS and KDE work and I am able to use Firefox. Therefore, I need to patch my computer (a Lenovo ThinkPad X270).

I started by reading the relevant chapter in Absolute FreeBSD by Michael W. Lucas. In it, he writes, "If you're using ZFS, always create a new boot environment before upgrading or patching!" Because he used an exclamation mark, I take it this is an important point. Since he doesn't provide any other information on new boot environments, I did a web search and found a blog post he made on the topic. To me, ZFS boot environments (beadm) sound like a great, though probably unnecessary, feature.

I will save readers the time of typing out instructions and post what I think are the instructions for updating to the latest patch level while using beadm. Keep in mind I am a complete noob and have never updated FreeBSD before, so readers should look over these instructions carefully and let me know if this is the correct process.

  1. Starting with the link to the author's blog post, I will install beadm first. Since I've already used # pkg install to install KDE and Firefox, I take it I can skip his first instruction of running the aforementioned instruction to set up the package management system.
    # pkg install -y beadm
  2. Next, see which boot environments I have.
    # beadm list
    BE Active Mountpoint Space Created
    default NR / 494.0M 2015-04-08 07:18

    The code underneath the command was taken from his blog post. He notes, "The only boot environment is named default. Under active, N means the environment is active now. An R means the environment will be active on reboot."
  3. I am going to update the host to the latest version of FreeBSD 13.0, p#. Someone please tell me how I can find the latest patch level of FreeBSD 13.0, so I know what to name the boot environment(!!!). In every instance, the number sign ("#") should be replaced with the number of the current patch level. I'll name the boot environment after the latest release and patch level.
    # beadm create 13.0-p#
    Created successfully
    # beadm list
    BE Active Mountpoint Space Created
    default N / 186.0K 2015-04-08 07:18
    13.0-p# R - 646.2M 2015-04-08 11:43
  4. Activate the new boot environment.
    # beadm activate 13.0-p#
    Activated successfully
    # beadm list
    BE Active Mountpoint Space Created
    default N / 186.0K 2015-04-08 07:18
    13.0-p# R - 646.2M 2015-04-08 11:43

    He notes, "While the default environment has an N, indicating it’s active now, the 10.1-p9 environment has an R, so it will be active after a reboot."
  5. He writes, "Reboot. After the reboot, you’ll see the new environment is running."
    # shutdown -r now
    # beadm list
    BE Active Mountpoint Space Created
    default - - 538.0K 2015-04-08 07:18
    13.0-p# NR / 646.3M 2015-04-08 11:43
  6. He writes, "Now I can install the latest FreeBSD patches without damaging my default system. If it fails, I can fall back by activating the default boot environment."

    What follows are how I understand one should update to the latest patch level on FreeBSD. Please correct me if I'm wrong. N.B.: In Absolute FreeBSD, which was published in 2018, the author includes the following footnote: "Various FreeBSD developers have spent the last several releases working toward packaging the base system so that the packaging tools can handle upgrades. I expect that the release of this book will prompt them to immediately solve the remaining problems and obsolete this section." Does anyone know what this means? Is he saying this section ("Binary Updates" in the chapter "Upgrading FreeBSD") is will be or already is obsolete, thereby making # freebsd-update obsolete? I see the FreeBSD Handbook advises updating to the latest patch level the same way as the book, so it's probably not obsolete yet--if this is what he's talking about. Should I check with the FreeBSD Handbook before doing every update or upgrade to make sure the instructions are current?

    # freebsd-update fetch
    # freebsd-update install
  7. Is there anything else I'm supposed to do?
Thanks in advance for helping!
 
That should be good. After the freebsd-update install I would reboot and run freebsd-update install again followed by pkg upgrade.
Sometimes the first freebsd-update install only installs a new kernel and some initial changes, a reboot followed by a second freebsd-update install gets the rest of the userland.
The pkg upgrade gets all your packages to the latest versions.

freebsd-update install tells you if it has nothing to do, so no harm in running it an extra time or two.

Anything about "packaging the base system" can be filed away as "interesting, for future reference" because it's still a work in progress.
freebsd-update is still the command to use for binary upgrades.
 
Today I did the "jump" to 13.1RC3 using beadm to create a dedicated boot environnement.
All I did was :
- sudo freebsd-update upgrade -r 13.1-RC3.
- sudo freebsd-update install
- sudo shutdown -R now
- sudo pkg upgrade.
- this worked as expected, but I will keep the 13.0 boot environnement until the release of FreeBSD 13.1-Release.
 
That should be good. After the freebsd-update install I would reboot and run freebsd-update install again followed by pkg upgrade.
Thanks. So, after the reboot I should just run # freebsd-update install without running # freebsd-update fetch again? Thanks also for mentioning "pkg upgrade"--I'd been meaning to ask about that as well, since I haven't upgraded any of my packages (KDE and Firefox, for example). To do this, do I just run # pkg upgrade? And this is all I have to ever do to get the latest versions of packages? Should I reboot after running the command?

- this worked as expected, but I will keep the 13.0 boot environnement until the release of FreeBSD 13.1-Release.
Your post reminded me of some questions I had. Should you remove old boot environments? Do they take up a lot of space?

--

If someone could tell me how I can find the latest patch level of FreeBSD 13.0, so I know what to name the boot environment, that would be helpful!
 
freebsd-update fetch will fetch the latest patch (files). To have the patch installed, you use freebsd-install. When installing a specific patch, downloading again the files belonging to that patch level is not necessary: you don't need to issue freebsd-update fetch again (only if there was an error in fetching the patch). If, occasionally, the install of a patch needs another freebsd-install, it will tell you.

It is good that you contemplate an appropriate name for a boot environment beforehand. When you issue freebsd-update fetch you'll see the patch level, if there is a patch available. Executing that command will only download files but does not install the new patch; that happens when you issue freebsd-update install. However, beadm(8) comes also with
beadm rename origBeName newBeName
so you can easily change the name of a boot environment at anytime.

For the base install of FreeBSD it is wise to check regularly for available patches (use freebsd-update fetch): you'll get the latest security updates. Package management occurs on the basis of a "quarterly" or "latest" setting. Packages can also have security updates, so it is good to check regularly for any upgrades: use pkg upgrade -n just to check what is available. Whether you are on quarterly or latest, check regularly.
 
Thanks Erichans about the "beadm rename" command. It's one of those commands you forget about but it is very useful.

Scribner yes, freebsd-update install without a fetch in between, Erichans explains it better than I did and the process does tell you if it needs it.

I typically run pkg upgrade -n once a week just to see if anything can be updated, I also pay attention to the output of pkg audit -F which tells you about known vulnerabilities. Funny how often chromium shows up....
As for base I pay attention to the security announcements mailing list and if there is anything I care about I'll plan an update if it's fixed.
 
Thank you both!

It sounds like I'll probably need to use the beadm rename command, since I won't run freebsd-update fetch until after creating the boot environment. In other words, I won't know what to call the boot environment until after I create it. (If there is a way to see the latest patch level without downloading anything or making any changes to the computer, please let me know!)

Could someone tell me the difference between pkg upgrade and pkg upgrade -n and when to run each? I read the man page for pkg, but I'm still not really sure what -n does.

If at least one more person could look through my instructions in the original post and confirm they are good, that would be helpful!

Lastly, I will ask again: Should you remove old boot environments? Do they take up a lot of space?
 
I went through this recently and current 13.0-RELEASE is p11. So use "p11" when creating your BE and you'll be fine.

The "-n" on the pkg upgrade means "do nothing." Basically it forces the pkg command to run the upgrade process, but it will not download or try to install anything. It's a handy way of seeing what would get upgraded.

Here's on my system that is currently up to date. Yes, I'm using the bectl command (it's in base) instead of beadm. The commands are functionally equivalent, some minor differences (mostly around destroy), so consider them interchangeable.

bectl list BE Active Mountpoint Space Created 13.0-RELEASE-p11 NR / 15.5G 2022-04-06 13:22 13.0-RELEASE-p7 - - 2.95G 2021-07-08 08:27 default - - 5.64G 2019-12-06 07:34
 
You don't actually need the sysutils/beadm package any longer. There is a bectl(8) in the base now that does exactly the same thing. You can actually do full major version upgrades easily in a chroot (or jail). I do this which cuts down on the number of reboots:

Code:
bectl create 13.0-RELEASE          
bectl mount 13.0-RELEASE /mnt                                            
zfs set mountpoint=/mnt/usr/src zroot/usr/src                            
mount -t devfs devfs /mnt/dev                                            
chroot /mnt /bin/sh
freebsd-update upgrade -r 13.0-RELEASE                                                                                                                
freebsd-update install                                                                                                                                
freebsd-update install                                                                                                                                
exit                                                                                                                                                  
umount /mnt/dev                                                          
zfs set mountpoint=/usr/src zroot/usr/src
bectl umount 13.0-RELEASE                                                                                                                            
bectl activate 13.0-RELEASE                                              
shutdown -r now                  
pkg-static -f install pkg                                                
pkg upgrade                                                              
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
zpool upgrade -a                                                                                                                                      
shutdown -r now                                                                                                                                      
freebsd-update install                                                    
bectl destroy -o 12.2-RELEASE

There are some improvements that can be made now though. freebsd-update(8) has a -b option which can be used to point it to /mnt without bothering to enter the chroot or mount /dev. And also freebsd-update(8) now automatically creates a new boot environment when it runs, so you don't necessarily need to do this yourself either now. This can be controlled with the CreateBootEnv option in /etc/freebsd-update.conf.
 
And also freebsd-update(8) now automatically creates a new boot environment when it runs, so you don't necessarily need to do this yourself either now. This can be controlled with the CreateBootEnv option in /etc/freebsd-update.conf.
Thanks! Does anyone know if this is what I should do instead of following the instructions for beadm in my original post? Could I get more information on this feature and exactly what steps I should follow to update to the latest patch level with a new boot environment (keeping in mind I am a complete noob)?
 
Yes. Do what you were originally doing, see how it works, then when you list the boot environments you will likely see three new ones. The one you originally created, and two that freebsd-update created when you ran install. Then you can decide how you want to handle it next time around.
 
[...] And also freebsd-update(8) now automatically creates a new boot environment when it runs, so you don't necessarily need to do this yourself either now. This can be controlled with the CreateBootEnv option in /etc/freebsd-update.conf.
Yes. Do what you were originally doing, see how it works, then when you list the boot environments you will likely see three new ones. The one you originally created, and two that freebsd-update created when you ran install. Then you can decide how you want to handle it next time around.
As far as I know and can deduce from the man pages*:
  • freebsd-update(8) in FreeBSD 13.0-RELEASE can not automatically create a BE
    You cannot use the option CreateBootEnv in freebsd-update.conf (5)
  • freebsd-update(8) in FreeBSD 13.1-(pre)RELEASE can automatically create a BE
    You can use the option CreateBootEnv in freebsd-update.conf(5)
Note: Scribner runs FreeBSD 13.0-RELEASE at the moment.

When FreeBSD 13.1-RELEASE will have been released and behaves as described in the P.S. below then, the option suggested by grahamperrin:
  • to not create a boot environment, CreateBootEnv no
seems appropriate when you do not want BEs to be created automatically. Do create BEs by hand as needed.

___
* compare FreeBSD’s 13.0-RELEASE freebsd-update.conf(5) with freebsd-update.conf(5); the latter is what will probably be in FreeBSD 13.1-RELEASE.

P.S. looking at freebsd-update(8) and boot environments of grahamperrin, regarding CreateBootEnv, somethings have to be ironed out I think. freebsd-update.conf(5) states:
CreateBootEnv
The single parameter following this keyword must
be "yes" or "no" and specifies whether
freebsd-update(8) will create a new boot envi-
ronment using bectl(8) when installing patches.
As I read that description, it implies that this option only relates to patches. grahamperrin's message shows that it also applies to non-patches. In his case, moving from one pre-release to another, a BE is being created with every call of freebsd-update install. Because non-patch updates generally need more than one call of freebsd-update install (more than two even), it seems that for every one a separate BE will be created. That might be what you desire but I suspect most of the time it is not.
 
Last edited:
Thanks, all.

As xtaz mentions above, do you think I should use bectl instead of beadm, since it ships with the base? If so, could someone post noob-friendly instructions that do the same thing as my instructions in my original post?
 
"noob friendly" instructions:
everywhere you see "beadm" type "bectl"
Yes, the commands are that equivalent.

Do I think you should do that? "6s and 3s" I've used beadm for a while (before bectl) so still use it by default. I don't think you should worry about bectl at the moment.
 
… more information on this feature …


Please join me there.
 
[...] To me, ZFS boot environments (beadm) sound like a great, though probably unnecessary, feature.
Generally speaking, the concept or idea of BEs is fairly straightforward. By creating a BE, things that are important for the system parts of the FreeBSD OS are set apart and those things are taken together in such a way that you’ll be able to select them to easily to boot from (you "boot into" a specific BE). Hence the name Boot Environment. An older BE comes in very handy when updating (usually not updates involving only patches); when you are upgrading to the next minor and major version of FreeBSD (or when experimenting with -STABLE or -CURRENT versions) and then ... some things go wrong. That could even be that the system does not boot anymore. Of course you can rely on restoring a backup of the system but that takes time and isn't very convenient. (Restoring from backup also does not encourage exploring or experimenting.) When you have a BE containing a previous state of your system, say a previous patch level, then you can choose that older BE from the loader menu (aka the beastie menu).

BEs are not always as easy to understand in all of its details and require some insight and work. I’d suggest, if you choose to work with BEs, take it slowly and begin with reading the chapter on Boot Environments in Michael Lucas’ Absolutely FreeBSD again. Then if you want to practice a little bit, try activating an old BE (for example of a FreeBSD version of previous patch level) and boot into it. After that return to the BE from which you started. If you have no pressing reason otherwise, I advise you to wait to upgrade to 13.1-RELEASE until its official release; currently for 13.1 only release cadidates (RCs) are available. When the official release of 13.1-RELEASE sees the light of day, 13.0-RELEASE will be supported for another three months, plenty of time to choose your upgrade.

You could look at an older BE like a time capsule that captures the system at a certain moment in time. A time capsule is frozen in time but with a BE you can go back to it, possibly change things and even work with that particular BE as your standard current BE. With the normal settings a standard BE is not the whole (FreeBSD) system but only "that part" of the system that it considers to belong to its basic system set of files which also allows FreeBSD to boot itself and run. “That part” is actually a ZFS dataset; more specifically: a particular kind of snapshot. If you change things when booted into an older BE (i.e.: that older BE is active), then changes made to files that belong to that older BE stay confined to that older BE. If you change things that fall outside that active older BE (for example to a file in a user home directory—not being root), the changes are not confined to that older BE: you'll see those changes as well when you return to your current BE.

As for the management of BEs: take a managerial view. If one has a lot of BEs lying around, for example 13.0-RELEASE-p0 through 13.0-RELEASE-p11, I think it is clear to see that you probably won’t have a need for all of them.

Because of the underlying technology (ZFS), the creation of a BE is easy and it is also cheap. BEs are cheap to create initially but when, over time, the differences between various BEs grow, they will become less cheap and start to consume more disk space. Because standard BEs only relate to a part of the OS, they are not the biggest space consumers on your disk but I advise you to clean up once in a while. If only to keep the number of BEs you see—from which to choose one—limited: the managerial view.




■ How to find a specific pkg man pages?

Revisiting pkg upgrade, some useful hints at how to get information for a specific pkg command such as pkg upgrade. pkg-upgrade(8) gives direct access to the man page that documents the -n option (or --dry-run). As you might have guessed, the reason for this structuring is that there is a lot information for every pkg command: it would be very unwieldy to have that in one single man page.

Although there is no command pkg-upgrade (note the dash in the middle), this is used as a moniker to find and access its separate man page. There are two other ways however:
  1. man pkg --> goto the SEE ALSO section --> pkg-upgrade --> man pkg-upgrade
  2. pkg help --> (notice the upgrade command) --> pkg help upgrade, this opens the requested man page as if you would have typed man pkg-upgrade
You can do this with other (sub)commands of pkg as well.
 
I have to say how much I agree with everything Erichans wrote in #17. Re-read Michael Lucas books; almost mandatory. I'd also recommend his FreeBSD Mastery: ZFS, Advanced ZFS and Storage Essentials books.

BE management: think of them as Browser tabs. You know how some people seem to have 1000 tabs open at the same time and then they have to open every single one to find what they're looking for? Too many BEs are like that. If you are not actively experimenting or developing, most people seem to wind up with about 3 BEs. The one they are currently using, a previous working one (typically this used to be the one always used) and a "default" one from the initial install. That also keeps the list short in the loader and easier to navigate.

There are also a few interesting commands on both bectl and beadm; I find the "mount" command most useful. If something is not working quite right in the current one, mount the previous working one and then you can easily compare things like /etc/rc.conf and other config files.

The man page tip on pkg: a lot of other items follow similar patterns on man pages for subcommands.
 
[...] The man page tip on pkg: a lot of other items follow similar patterns on man pages for subcommands.
Indeed, however poudriere (even the development version) not. Hoping on future implementation :)

Also, when a certain pkg "subcommand" doesn't reveil itself with pkg help, it might be an alias:
Code:
% pkg help prime-list
`prime-list` is an alias to `query -e '%a = 0' '%n'`

% pkg alias
<snip - all defined pkg aliases>
 
… Should you remove old boot environments? Do they take up a lot of space?

Loosely speaking: the more frequently you update, the less space will be taken by each environment. See below re: the likely effect of destroying an environment.

For any use of pkg-upgrade(8) to install, I routinely:
  1. pkg clean -a before creating the new environment
  2. create, activate then boot the environment before the installation
  3. pkg clean -a -y then pkg autoremove after the installation.

bectl(8) (with option -c)​


Below, I have 200 G free, so I'm not immediately concerned by the spaces taken:

Code:
% zpool list august
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
august   912G   712G   200G        -         -    46%    78%  1.00x    ONLINE  -
% bectl list -c creation
BE                    Active Mountpoint Space Created
n250511-5f73b3338ee-d -      -          4.94G 2021-11-13 15:43
n252381-75d20a5e386-b -      -          6.81G 2022-01-12 23:23
n252450-5efa7281a79-a -      -          6.49G 2022-01-14 19:27
n252483-c8f8299a230-b -      -          4.84G 2022-01-17 14:24
n252505-cc68614da82-a -      -          4.90G 2022-01-18 14:26
n252531-0ce7909cd0b-h -      -          5.71G 2022-02-06 12:24
n252997-b6724f7004c-c -      -          6.17G 2022-02-11 23:07
n253116-39a36707bd3-e -      -          5.66G 2022-02-20 07:03
n253343-9835900cb95-c -      -          1.54G 2022-02-27 14:58
n253776-d5ad1713cc3-b -      -          7.94G 2022-03-18 09:31
n253861-92e6b4712b5-e -      -          7.41G 2022-04-02 16:02
n254268-50e244964e9-d -      -          2.92G 2022-04-09 18:50
n254693-d7696096209-b -      -          820M  2022-04-17 03:38
n254693-d7696096209-c -      -          383M  2022-04-17 23:55
n254693-d7696096209-d NR     /          191G  2022-04-22 04:43
% sudo bectl destroy n254693-d7696096209-b
grahamperrin's password:
% bectl list -c creation
BE                    Active Mountpoint Space Created
n250511-5f73b3338ee-d -      -          4.94G 2021-11-13 15:43
n252381-75d20a5e386-b -      -          6.81G 2022-01-12 23:23
n252450-5efa7281a79-a -      -          6.49G 2022-01-14 19:27
n252483-c8f8299a230-b -      -          4.84G 2022-01-17 14:24
n252505-cc68614da82-a -      -          4.90G 2022-01-18 14:26
n252531-0ce7909cd0b-h -      -          5.71G 2022-02-06 12:24
n252997-b6724f7004c-c -      -          6.17G 2022-02-11 23:07
n253116-39a36707bd3-e -      -          5.66G 2022-02-20 07:03
n253343-9835900cb95-c -      -          1.54G 2022-02-27 14:58
n253776-d5ad1713cc3-b -      -          7.94G 2022-03-18 09:31
n253861-92e6b4712b5-e -      -          7.41G 2022-04-02 16:02
n254268-50e244964e9-d -      -          3.18G 2022-04-09 18:50
n254693-d7696096209-c -      -          887M  2022-04-17 23:55
n254693-d7696096209-d NR     /          191G  2022-04-22 04:43
%

Spaces​


Note (from the above), before and after destroying n254693-d7696096209-b:

n254268-50e244964e9-d - - 2.92G 2022-04-09 18:50 n254693-d7696096209-b - - 820M 2022-04-17 03:38 n254693-d7696096209-c - - 383M 2022-04-17 23:55

n254268-50e244964e9-d - - 3.18G 2022-04-09 18:50 n254693-d7696096209-c - - 887M 2022-04-17 23:55
  • in this example, environments 'adjacent' to the destroyed environment occupy more space following destruction
– this type of thing is to be expected.
 
If you have no pressing reason otherwise, I advise you to wait to upgrade to 13.1-RELEASE until its official release; currently for 13.1 only release cadidates (RCs) are available. When the official release of 13.1-RELEASE sees the light of day, 13.0-RELEASE will be supported for another three months, plenty of time to choose your upgrade.
Thanks for the thorough and helpful response. Are you saying I shouldn't create a new boot environment and update to the latest patch level, but rather wait until 13.1-RELEASE is released to update? Or are you saying I should I update to the latest patch level and just not create a new boot environment for it?
 
… Are you saying I shouldn't create a new boot environment and update to the latest patch level, but rather wait until 13.1-RELEASE is released to update?

I should not ignore FreeBSD-provided patches.

Or are you saying I should I update to the latest patch level and just not create a new boot environment for it?

Good practices include:
  • applying FreeBSD-provided patches to the FreeBSD operating system (OS), without delay
  • creating a boot environment before any update or upgrade to the OS
  • creating a boot environment before any upgrade to packages.


Order and naming​

I habitually activate then boot the new environment before performing the installation.

Some other methods reboot after performing the installation, with the same boot environment e.g. default used before and after the reboot. A potential disadvantage:
  • the name of the environment
– if a problem occurs, and you find it necessary to activate (then boot) something other than default:
  • your default boot environment will not be default.
 
I mentioned my procedure earlier in this thread for doing major version upgrades using boot environments and minimising the reboots and I said that there were probably better ways to do it. I have now successfully upgraded my server from 13.1-RC4 to 13.1-RC5 using this method, although I've edited the release names to be a bit more generic and obvious.

Code:
bectl create 13.1-RELEASE
bectl mount 13.1-RELEASE /mnt
freebsd-update upgrade -b /mnt -d /mnt/var/db/freebsd-update -r 13.1-RELEASE
freebsd-update -b /mnt -d /mnt/var/db/freebsd-update install
freebsd-update -b /mnt -d /mnt/var/db/freebsd-update install
freebsd-update -b /mnt -d /mnt/var/db/freebsd-update install # yes run three times
gpart bootcode -b /mnt/boot/pmbr -p /mnt/boot/gptzfsboot -i 1 ada0 # this assumes ZFS on the root of ada0
mount -t devfs devfs /mnt/dev # pkg needs devfs mounted
pkg-static -c /mnt upgrade -f
umount /mnt/dev
bectl umount 13.1-RELEASE
bectl activate 13.1-RELEASE
shutdown -r now # only one reboot!
zpool upgrade -a
bectl destroy 13.0-RELEASE
 
xtaz thanks, good info to have.
So you are not doing chroot into the new BE, you are simply telling each command where to operate.

Obviously the gpart command should be done on every boot device (say if you have a mirror).

Interesting about the devfs: it should be mounted on /dev, but the pkg-static -c /mnt does a chroot so
you need to explicitly mount it there.
If you chroot into the new BE you need to do that same mount.

Would there be any benefit to adding "-o" on the bectl destroy? That would avoid a hidden build up of snapshots and such.
 
xtazWould there be any benefit to adding "-o" on the bectl destroy? That would avoid a hidden build up of snapshots and such.

There used to be when bectl first came out, but there was a commit which made it do it automatically and made the behaviour of bectl identical to beadm.

And yes, agree about the rest of what you said. That's why I commented the gpart command. That has to be changed to suit your setup. If it uses EFI boot there's a whole different procedure there.

The -d is kind of optional too. That makes it use the new boot environment for its working files rather than the old one, which means rollback would work in the new environment. But if you don't care about that then you don't need it. And obviously we don't really need rollback to work as that's what boot environments are for anyway. In fact I may just remove that.
 
  • Like
Reactions: mer
Back
Top