# Updating FreeBSD With ZFS Boot Environments (beadm)



## Scribner (Apr 18, 2022)

(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.


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`
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."
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`
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."
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`
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`
Is there anything else I'm supposed to do?
Thanks in advance for helping!


----------



## mer (Apr 19, 2022)

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.


----------



## tuxador (Apr 19, 2022)

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.


----------



## Scribner (Apr 19, 2022)

mer said:


> 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?



tuxador said:


> - 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!


----------



## Erichans (Apr 19, 2022)

`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.


----------



## mer (Apr 19, 2022)

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.


----------



## Scribner (Apr 19, 2022)

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?


----------



## mer (Apr 19, 2022)

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`


----------



## xtaz (Apr 20, 2022)

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:


```
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.


----------



## Scribner (Apr 20, 2022)

xtaz said:


> 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)?


----------



## mer (Apr 20, 2022)

I think following your original post is the best idea at this point.  Get one successful one under your belt and then explore options.


----------



## xtaz (Apr 21, 2022)

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.


----------



## Erichans (Apr 21, 2022)

xtaz said:


> [...] 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.





xtaz said:


> 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.


----------



## Scribner (Apr 22, 2022)

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?


----------



## mer (Apr 22, 2022)

"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.


----------



## grahamperrin@ (Apr 23, 2022)

Scribner said:


> … more information on this feature …











						Solved - freebsd-update(8) and boot environments
					

With freebsd-update(8) in FreeBSD 12.3 and 13.1 on ZFS:  a single upgrade will typically add two boot environments:    freebsd-update.conf(5) % uname -KU ; tail -n 3 /etc/freebsd-update.conf 1400056 1400056  # Create a new boot environment when installing patches # CreateBootEnv yes %...




					forums.freebsd.org
				




Please join me there.


----------



## Erichans (Apr 23, 2022)

Scribner said:


> [...] 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:

`man pkg` --> goto the SEE ALSO section --> pkg-upgrade --> `man pkg-upgrade`
`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.


----------



## mer (Apr 23, 2022)

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.


----------



## Erichans (Apr 23, 2022)

mer said:


> [...] 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:

```
% pkg help prime-list
`prime-list` is an alias to `query -e '%a = 0' '%n'`

% pkg alias
<snip - all defined pkg aliases>
```


----------



## grahamperrin@ (Apr 23, 2022)

Scribner said:


> … 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:

`pkg clean -a` before creating the new environment
create, activate then boot the environment before the installation
`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:


```
% 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.


----------



## Scribner (Apr 26, 2022)

Erichans said:


> 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?


----------



## grahamperrin@ (Apr 27, 2022)

Scribner said:


> … 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.



Scribner said:


> 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.


----------



## xtaz (Apr 29, 2022)

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.


```
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
```


----------



## mer (Apr 29, 2022)

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.


----------



## xtaz (Apr 29, 2022)

mer said:


> 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.


----------



## mer (Apr 29, 2022)

I recall there was discussion on the -o wasn't sure if it made it into anything for 13.0-RELEASE (I think currently it's at p11).


----------



## Erichans (Apr 29, 2022)

Considering the OP perhaps somewhat unfortunate that with these latest messages we're taking a deeper dive into BEs—and bectl.


There is a difference in complexities, impact of changes and usefulness of keeping old BEs around or on stand by, when:

 going from one patch level to the next one, as in going from FreeBSD 13.0-p5 FreeBSD 13.0-p6
 going from one RC to the next one, as in going from FreeBSD 13.1-RC4 to FreeBSD 13.1-RC5
 going from 13.0-RELEASE to 13.1-RELEASE; this is a _minor_ version upgrade
 going from 12.2-RELEASE to 13.1-RELEASE; this is a _major_ version upgrade
This difference may relate to how users perceive the necessity to being able to go back (to a previous BE).

Your command sequence shows an upgrade from 13.0-RELEASE to 13.1-RELEASE (right now, the latter does not exist), immediately after installing 13.1-RELEASE you are destroying the 13.0-RELEASE BE. That may be exactly what you want but one might prefer to keep that one around a little bit longer—especially if that is your only one of the 13.0-RELEASE. Sometimes upgrade problems may only show up after some time and it would be useful to be able to easily fall back to an old working BE—even though the underlying origin has not been destroyed. 



xtaz said:


> 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.


I think the circumstances are somewhat different; looking at the commit message:


> *bectl(8): destroy: use BE_DESTROY_AUTOORIGIN if -o is not specified*
> 
> -o will force the origin to be destroyed unconditionally.
> BE_DESTROY_AUTOORIGIN, on the other hand, will only destroy the origin if it
> ...


The way I interpret this commit message is that if the `-o` option is not used, and when the origin of the BE (i.e. the snapshot on which it is based) is clearly not user-managed then the origin is destroyed. When it _is_ user-managed the origin it is not destroyed. If this is to be interpreted in another way, I'd like to know.

Non-user-managed BEs would probably be those BEs that are generated by the (more than one) `freebsd-update` commands normally needed (see earlier message about the auto creation of BEs when using `freebsd-update`). If I understand xtaz's command sequence correctly, you're bypassing that by using a mnt as target for the successive `freebsd-update`'s that is "not-active", that is: not part of the _running OS_; resulting in needing only one reboot.



mer said:


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


I guess that you won't be able to destroy the underlying origin (snapshot) of the 13.0-RELEASE BE, especially when the origin is user-managed.  This is because the 13.1-RELEASE BE depends on the 13.0-RELEASE BE.  When you cloned it (as part of the creation of the 13.1-RELEASE BE a clone was made), the clone of the 13.1-RELEASE depends on the snapshot of the 13.0-RELEASE. If this is indeed the case, then you'll have to use `zfs promote` ( zfs-promote(8) ); see _Promoting Clones_ in Advanced ZFS Snapshots 



xtaz said:


> `zpool upgrade -a`


This might not be a good idea and in general I would recommend not doing that—at least not immediately. I think 13.1-RELEASE is based on a new OpenZFS version (compared to 13.0-RELEASE), so possibly it has new pool features. Using `zpool upgrade -a` is like burning one's bridges: you'll have no fall back option. Booting from an external  13.0-RELEASE source, such as an image on a flash drive, will fail to use the pool that has the new features activated. zpool-upgrade(8): 

```
DESCRIPTION
     zpool upgrade
	     Displays pools which do not have all supported features enabled
	     and pools formatted using a legacy	ZFS version number.  These
	     pools can continue to be used, but some features may not be
	     available. Use zpool upgrade -a to enable all features on all
	     pools.
```

`zpool status test`mentions this*:

```
# zpool status test
pool:   test
state:  ONLINE
status: The pool is formatted using an older on-disk format. The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using ’zpool upgrade’. Once this is done, the
        pool will no longer be accessible on older software versions.
```
In general: leave your pool features alone if you might possibly need to revert an OS upgrade.

___
* see also: the section _More Information_ in Should I Upgrade to OpenZFS 2.1?


----------



## xtaz (Apr 29, 2022)

All good points and I agree with everything you’ve said. I take more risks, for me if it works on boot then I will fix forward rather than revert.

I edited the release names slightly to make it more generic rather than having RC4 and RC5 in there as I mentioned in the original post.

However, I may have picked the wrong commit, I’m not sure now, but in the past without -o it did leave snapshots around but roughly since the time of that commit it doesn’t any longer.

I ran it this morning to upgrade to RC5 without -o and it deleted the snapshot.


----------



## grahamperrin@ (Apr 29, 2022)

xtaz said:


> `bectl mount 13.1-RELEASE /mnt`



I'd use a subdirectory of /mnt (not /mnt itself). No need to make the subdirectory before the mount.


----------



## grahamperrin@ (Apr 29, 2022)

Erichans said:


> … The way I interpret this commit message is …



It might help to view <https://bz-attachments.freebsd.org/attachment.cgi?id=223539>, the one and only line where an origin is left _intact_.


----------



## grahamperrin@ (Apr 30, 2022)

xtaz said:


> `gpart bootcode -b /mnt/boot/pmbr -p /mnt/boot/gptzfsboot -i 1 ada0 # this assumes ZFS on the root of ada0`



Please, is this consistent with the advice to _stop_ using gpart(8) for updates to old EFI system partitions?


----------



## grahamperrin@ (Apr 30, 2022)

xtaz said:


> `pkg-static -c /mnt upgrade -f`



As far as I can tell, the resulting upgrades are not logged.

An upgrade: 



Spoiler: pkg-static -c /tmp/up upgrade -r FreeBSD





```
root@mowa219-gjp4-8570p-freebsd:~ # file /tmp/up
/tmp/up: cannot open `/tmp/up' (No such file or directory)
root@mowa219-gjp4-8570p-freebsd:~ # pkg clean -a
Nothing to do.
root@mowa219-gjp4-8570p-freebsd:~ # pkg autoremove
Checking integrity... done (0 conflicting)
Nothing to do.
root@mowa219-gjp4-8570p-freebsd:~ # 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 -      -          6.62G 2022-04-09 18:50
n254693-d7696096209-f -      -          1.01G 2022-04-27 17:41
n255078-e140d551b78-a NR     /          198G  2022-04-28 01:33
root@mowa219-gjp4-8570p-freebsd:~ # bectl create n255078-e140d551b78-b
root@mowa219-gjp4-8570p-freebsd:~ # bectl mount n255078-e140d551b78-b /tmp/up
Successfully mounted n255078-e140d551b78-b at /tmp/up
root@mowa219-gjp4-8570p-freebsd:~ # mount -t devfs devfs /tmp/up/dev
root@mowa219-gjp4-8570p-freebsd:~ # pkg-static -c /tmp/up upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
pkg-static: file:///usr/local/poudriere/data/packages/main-default/meta.txz: No such file or directory
repository poudriere has no meta file, using default settings
pkg-static: file:///usr/local/poudriere/data/packages/main-default/packagesite.pkg: No such file or directory
pkg-static: file:///usr/local/poudriere/data/packages/main-default/packagesite.txz: No such file or directory
Unable to update repository poudriere
Error updating repositories!
root@mowa219-gjp4-8570p-freebsd:~ # pkg-static -c /tmp/up upgrade -r FreeBSD
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (62 candidates): 100%
Processing candidates (62 candidates): 100%
The following 64 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        gssdp14: 1.4.0.1 [FreeBSD]
        gupnp14: 1.4.3 [FreeBSD]
        libsoup3: 3.0.3_4 [FreeBSD]

Installed packages to be UPGRADED:
        atril: 1.26.0_6 -> 1.26.0_7 [FreeBSD]
        cantor: 22.04.0_2 -> 22.04.0_3 [FreeBSD]
        cups-filters: 1.28.10_3 -> 1.28.10_4 [FreeBSD]
        efl: 1.26.2_2 -> 1.26.2_3 [FreeBSD]
        eog: 42.0 -> 42.1 [FreeBSD]
        firefox: 99.0.1_2,2 -> 100.0,2 [FreeBSD]
        freerdp: 2.6.1 -> 2.7.0 [FreeBSD]
        gdal: 3.4.2_2 -> 3.4.2_3 [FreeBSD]
        gegl: 0.4.34_2 -> 0.4.34_3 [FreeBSD]
        gimp-app: 2.10.30_2,1 -> 2.10.30_3,1 [FreeBSD]
        gnome-online-accounts: 3.40.1_2 -> 3.44.0 [FreeBSD]
        goffice: 0.10.50_2 -> 0.10.52 [FreeBSD]
        graphene: 1.10.6 -> 1.10.8 [FreeBSD]
        graphviz: 2.50.0_1 -> 2.50.0_2 [FreeBSD]
        gssdp: 1.4.0.1 -> 1.5.0 [FreeBSD]
        gupnp: 1.4.3_2 -> 1.5.0 [FreeBSD]
        inkscape: 1.1.2_3 -> 1.1.2_4 [FreeBSD]
        keepassxc: 2.7.0 -> 2.7.1 [FreeBSD]
        kf5-kfilemetadata: 5.93.0 -> 5.93.0_1 [FreeBSD]
        kitinerary: 22.04.0_3 -> 22.04.0_4 [FreeBSD]
        libgcrypt: 1.9.4 -> 1.9.4_1 [FreeBSD]
        libgxps: 0.3.1 -> 0.3.2 [FreeBSD]
        libhandy: 1.6.1 -> 1.6.2 [FreeBSD]
        libmediaart: 1.9.5 -> 1.9.5_1 [FreeBSD]
        libpci: 3.7.0_1 -> 3.8.0 [FreeBSD]
        libreoffice: 7.3.2.2_2 -> 7.3.2.2_4 [FreeBSD]
        libsecret: 0.20.4_2 -> 0.20.5 [FreeBSD]
        libunwind: 20211201 -> 20211201_1 [FreeBSD]
        lumina-pdf: 1.6.2_1 -> 1.6.2_2 [FreeBSD]
        meson: 0.62.0 -> 0.62.1 [FreeBSD]
        nano: 6.0 -> 6.2 [FreeBSD]
        nnn: 4.4 -> 4.5 [FreeBSD]
        obs-studio: 27.2.3_1 -> 27.2.4 [FreeBSD]
        okular: 22.04.0_1 -> 22.04.0_2 [FreeBSD]
        pciutils: 3.7.0 -> 3.8.0 [FreeBSD]
        phoronix-test-suite-php80: 10.8.2 -> 10.8.3 [FreeBSD]
        poppler: 22.01.0_1 -> 22.04.0 [FreeBSD]
        poppler-glib: 22.01.0_1 -> 22.04.0 [FreeBSD]
        poppler-qt5: 22.01.0_1 -> 22.04.0 [FreeBSD]
        poppler-utils: 22.01.0_1 -> 22.04.0 [FreeBSD]
        protobuf: 3.20.0,1 -> 3.20.1,1 [FreeBSD]
        py38-atspi: 2.38.1 -> 2.38.2 [FreeBSD]
        py38-metadata-cleaner: 2.2.1 -> 2.2.2 [FreeBSD]
        py38-pdftotext: 2.2.2_1 -> 2.2.2_2 [FreeBSD]
        py38-pikepdf: 5.1.1 -> 5.1.2 [FreeBSD]
        py38-pyzmq: 22.3.0 -> 22.3.0_1 [FreeBSD]
        py38-typing-extensions: 4.1.1 -> 4.2.0 [FreeBSD]
        python38: 3.8.13 -> 3.8.13_1 [FreeBSD]
        python39: 3.9.12 -> 3.9.12_1 [FreeBSD]
        qpdfview: 0.4.18_27 -> 0.4.18_28 [FreeBSD]
        ruby30-gems: 3.3.11 -> 3.3.12 [FreeBSD]
        sane-backends: 1.1.1_3 -> 1.1.1_4 [FreeBSD]
        sdl2: 2.0.20_1 -> 2.0.22 [FreeBSD]
        simplescreenrecorder: 0.4.3_2 -> 0.4.4 [FreeBSD]
        texlive-base: 20210325_2 -> 20210325_3 [FreeBSD]
        texworks: 0.6.2_38 -> 0.6.2_39 [FreeBSD]
        tikzit: 2.1.6_14 -> 2.1.6_15 [FreeBSD]
        tor: 0.4.6.10 -> 0.4.7.7 [FreeBSD]
        xfce4-tumbler: 4.16.0_15 -> 4.16.0_16 [FreeBSD]
        xournal: 0.4.8.2016_35 -> 0.4.8.2016_36 [FreeBSD]
        xreader: 3.2.2_4 -> 3.2.2_5 [FreeBSD]

Number of packages to be installed: 3
Number of packages to be upgraded: 61

The operation will free 38 MiB.
358 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/64] Fetching xreader-3.2.2_5.pkg: 100%  880 KiB 901.6kB/s    00:01   
[2/64] Fetching xournal-0.4.8.2016_36.pkg: 100%  227 KiB 232.5kB/s    00:01   
[3/64] Fetching xfce4-tumbler-4.16.0_16.pkg: 100%  143 KiB 146.8kB/s    00:01   
[4/64] Fetching tor-0.4.7.7.pkg: 100%    2 MiB   2.3MB/s    00:01   
[5/64] Fetching tikzit-2.1.6_15.pkg: 100%  303 KiB 309.8kB/s    00:01   
[6/64] Fetching texworks-0.6.2_39.pkg: 100%    2 MiB   2.4MB/s    00:01   
[7/64] Fetching texlive-base-20210325_3.pkg: 100%    4 MiB   4.5MB/s    00:01   
[8/64] Fetching simplescreenrecorder-0.4.4.pkg: 100%    1 MiB   1.3MB/s    00:01   
[9/64] Fetching sdl2-2.0.22.pkg: 100%    1 MiB   1.1MB/s    00:01   
[10/64] Fetching sane-backends-1.1.1_4.pkg: 100%    4 MiB   3.9MB/s    00:01   
[11/64] Fetching ruby30-gems-3.3.12.pkg: 100%  432 KiB 442.1kB/s    00:01   
[12/64] Fetching qpdfview-0.4.18_28.pkg: 100%  588 KiB 602.3kB/s    00:01   
[13/64] Fetching python39-3.9.12_1.pkg: 100%   18 MiB   6.1MB/s    00:03   
[14/64] Fetching python38-3.8.13_1.pkg: 100%   18 MiB   6.1MB/s    00:03   
[15/64] Fetching py38-typing-extensions-4.2.0.pkg: 100%   33 KiB  34.0kB/s    00:01   
[16/64] Fetching py38-pyzmq-22.3.0_1.pkg: 100%  400 KiB 409.4kB/s    00:01   
[17/64] Fetching py38-pikepdf-5.1.2.pkg: 100%  429 KiB 439.8kB/s    00:01   
[18/64] Fetching py38-pdftotext-2.2.2_2.pkg: 100%    8 KiB   8.5kB/s    00:01   
[19/64] Fetching py38-metadata-cleaner-2.2.2.pkg: 100%  161 KiB 165.3kB/s    00:01   
[20/64] Fetching py38-atspi-2.38.2.pkg: 100%   62 KiB  63.3kB/s    00:01   
[21/64] Fetching protobuf-3.20.1,1.pkg: 100%    3 MiB   3.2MB/s    00:01   
[22/64] Fetching poppler-utils-22.04.0.pkg: 100%  169 KiB 172.8kB/s    00:01   
[23/64] Fetching poppler-qt5-22.04.0.pkg: 100%  179 KiB 183.0kB/s    00:01   
[24/64] Fetching poppler-glib-22.04.0.pkg: 100%  195 KiB 199.6kB/s    00:01   
[25/64] Fetching poppler-22.04.0.pkg: 100%    1 MiB   1.1MB/s    00:01   
[26/64] Fetching phoronix-test-suite-php80-10.8.3.pkg: 100%    2 MiB   2.5MB/s    00:01   
[27/64] Fetching pciutils-3.8.0.pkg: 100%   55 KiB  56.1kB/s    00:01   
[28/64] Fetching okular-22.04.0_2.pkg: 100%    6 MiB   6.6MB/s    00:01   
[29/64] Fetching obs-studio-27.2.4.pkg: 100%    5 MiB   5.1MB/s    00:01   
[30/64] Fetching nnn-4.5.pkg: 100%  111 KiB 113.9kB/s    00:01   
[31/64] Fetching nano-6.2.pkg: 100%  568 KiB 581.7kB/s    00:01   
[32/64] Fetching meson-0.62.1.pkg: 100%    1 MiB   1.3MB/s    00:01   
[33/64] Fetching lumina-pdf-1.6.2_2.pkg: 100%   66 KiB  67.8kB/s    00:01   
[34/64] Fetching libunwind-20211201_1.pkg: 100%  127 KiB 130.0kB/s    00:01   
[35/64] Fetching libsecret-0.20.5.pkg: 100%  163 KiB 166.9kB/s    00:01   
[36/64] Fetching libreoffice-7.3.2.2_4.pkg: 100%  124 MiB   5.9MB/s    00:22   
[37/64] Fetching libpci-3.8.0.pkg: 100%   54 KiB  55.6kB/s    00:01   
[38/64] Fetching libmediaart-1.9.5_1.pkg: 100%   50 KiB  51.2kB/s    00:01   
[39/64] Fetching libhandy-1.6.2.pkg: 100%  427 KiB 437.2kB/s    00:01   
[40/64] Fetching libgxps-0.3.2.pkg: 100%   86 KiB  87.8kB/s    00:01   
[41/64] Fetching libgcrypt-1.9.4_1.pkg: 100%  839 KiB 858.9kB/s    00:01   
[42/64] Fetching kitinerary-22.04.0_4.pkg: 100%  925 KiB 947.2kB/s    00:01   
[43/64] Fetching kf5-kfilemetadata-5.93.0_1.pkg: 100%  167 KiB 171.4kB/s    00:01   
[44/64] Fetching keepassxc-2.7.1.pkg: 100%    7 MiB   7.4MB/s    00:01   
[45/64] Fetching inkscape-1.1.2_4.pkg: 100%   17 MiB   5.8MB/s    00:03   
[46/64] Fetching gupnp-1.5.0.pkg: 100%  114 KiB 116.6kB/s    00:01   
[47/64] Fetching gssdp-1.5.0.pkg: 100%   44 KiB  45.0kB/s    00:01   
[48/64] Fetching graphviz-2.50.0_2.pkg: 100%    3 MiB   2.7MB/s    00:01   
[49/64] Fetching graphene-1.10.8.pkg: 100%  194 KiB 198.9kB/s    00:01   
[50/64] Fetching goffice-0.10.52.pkg: 100%    2 MiB   2.1MB/s    00:01   
[51/64] Fetching gnome-online-accounts-3.44.0.pkg: 100%  559 KiB 572.6kB/s    00:01   
[52/64] Fetching gimp-app-2.10.30_3,1.pkg: 100%   18 MiB   6.4MB/s    00:03   
[53/64] Fetching gegl-0.4.34_3.pkg: 100%    2 MiB   2.2MB/s    00:01   
[54/64] Fetching gdal-3.4.2_3.pkg: 100%   17 MiB   5.8MB/s    00:03   
[55/64] Fetching freerdp-2.7.0.pkg: 100%    1 MiB   1.4MB/s    00:01   
[56/64] Fetching firefox-100.0,2.pkg: 100%   55 MiB   5.8MB/s    00:10   
[57/64] Fetching eog-42.1.pkg: 100%    1 MiB   1.1MB/s    00:01   
[58/64] Fetching efl-1.26.2_3.pkg: 100%   29 MiB   6.2MB/s    00:05   
[59/64] Fetching cups-filters-1.28.10_4.pkg: 100%  887 KiB 907.8kB/s    00:01   
[60/64] Fetching cantor-22.04.0_3.pkg: 100%    2 MiB   2.1MB/s    00:01   
[61/64] Fetching atril-1.26.0_7.pkg: 100%    1 MiB   1.4MB/s    00:01   
[62/64] Fetching gssdp14-1.4.0.1.pkg: 100%   44 KiB  44.6kB/s    00:01   
[63/64] Fetching gupnp14-1.4.3.pkg: 100%  115 KiB 117.4kB/s    00:01   
[64/64] Fetching libsoup3-3.0.3_4.pkg: 100%  343 KiB 351.1kB/s    00:01   
Checking integrity... done (2 conflicting)
  - gssdp14-1.4.0.1 [FreeBSD] conflicts with gssdp-1.4.0.1 [installed] on /usr/local/include/gssdp-1.2/libgssdp/gssdp-client.h
  - gupnp14-1.4.3 [FreeBSD] conflicts with gupnp-1.4.3_2 [installed] on /usr/local/bin/gupnp-binding-tool-1.2
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 66 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        gssdp14: 1.4.0.1 [FreeBSD]
        gupnp14: 1.4.3 [FreeBSD]
        libsoup3: 3.0.3_4 [FreeBSD]

Installed packages to be UPGRADED:
        atril: 1.26.0_6 -> 1.26.0_7 [FreeBSD]
        cantor: 22.04.0_2 -> 22.04.0_3 [FreeBSD]
        cups-filters: 1.28.10_3 -> 1.28.10_4 [FreeBSD]
        efl: 1.26.2_2 -> 1.26.2_3 [FreeBSD]
        eog: 42.0 -> 42.1 [FreeBSD]
        firefox: 99.0.1_2,2 -> 100.0,2 [FreeBSD]
        freerdp: 2.6.1 -> 2.7.0 [FreeBSD]
        gdal: 3.4.2_2 -> 3.4.2_3 [FreeBSD]
        gegl: 0.4.34_2 -> 0.4.34_3 [FreeBSD]
        gimp-app: 2.10.30_2,1 -> 2.10.30_3,1 [FreeBSD]
        gnome-online-accounts: 3.40.1_2 -> 3.44.0 [FreeBSD]
        goffice: 0.10.50_2 -> 0.10.52 [FreeBSD]
        graphene: 1.10.6 -> 1.10.8 [FreeBSD]
        graphviz: 2.50.0_1 -> 2.50.0_2 [FreeBSD]
        gssdp: 1.4.0.1 -> 1.5.0 [FreeBSD]
        inkscape: 1.1.2_3 -> 1.1.2_4 [FreeBSD]
        keepassxc: 2.7.0 -> 2.7.1 [FreeBSD]
        kf5-kfilemetadata: 5.93.0 -> 5.93.0_1 [FreeBSD]
        kitinerary: 22.04.0_3 -> 22.04.0_4 [FreeBSD]
        libgcrypt: 1.9.4 -> 1.9.4_1 [FreeBSD]
        libgxps: 0.3.1 -> 0.3.2 [FreeBSD]
        libhandy: 1.6.1 -> 1.6.2 [FreeBSD]
        libmediaart: 1.9.5 -> 1.9.5_1 [FreeBSD]
        libpci: 3.7.0_1 -> 3.8.0 [FreeBSD]
        libreoffice: 7.3.2.2_2 -> 7.3.2.2_4 [FreeBSD]
        libsecret: 0.20.4_2 -> 0.20.5 [FreeBSD]
        libunwind: 20211201 -> 20211201_1 [FreeBSD]
        lumina-pdf: 1.6.2_1 -> 1.6.2_2 [FreeBSD]
        meson: 0.62.0 -> 0.62.1 [FreeBSD]
        nano: 6.0 -> 6.2 [FreeBSD]
        nnn: 4.4 -> 4.5 [FreeBSD]
        obs-studio: 27.2.3_1 -> 27.2.4 [FreeBSD]
        okular: 22.04.0_1 -> 22.04.0_2 [FreeBSD]
        pciutils: 3.7.0 -> 3.8.0 [FreeBSD]
        phoronix-test-suite-php80: 10.8.2 -> 10.8.3 [FreeBSD]
        poppler: 22.01.0_1 -> 22.04.0 [FreeBSD]
        poppler-glib: 22.01.0_1 -> 22.04.0 [FreeBSD]
        poppler-qt5: 22.01.0_1 -> 22.04.0 [FreeBSD]
        poppler-utils: 22.01.0_1 -> 22.04.0 [FreeBSD]
        protobuf: 3.20.0,1 -> 3.20.1,1 [FreeBSD]
        py38-atspi: 2.38.1 -> 2.38.2 [FreeBSD]
        py38-metadata-cleaner: 2.2.1 -> 2.2.2 [FreeBSD]
        py38-pdftotext: 2.2.2_1 -> 2.2.2_2 [FreeBSD]
        py38-pikepdf: 5.1.1 -> 5.1.2 [FreeBSD]
        py38-pyzmq: 22.3.0 -> 22.3.0_1 [FreeBSD]
        py38-typing-extensions: 4.1.1 -> 4.2.0 [FreeBSD]
        python38: 3.8.13 -> 3.8.13_1 [FreeBSD]
        python39: 3.9.12 -> 3.9.12_1 [FreeBSD]
        qpdfview: 0.4.18_27 -> 0.4.18_28 [FreeBSD]
        ruby30-gems: 3.3.11 -> 3.3.12 [FreeBSD]
        sane-backends: 1.1.1_3 -> 1.1.1_4 [FreeBSD]
        sdl2: 2.0.20_1 -> 2.0.22 [FreeBSD]
        simplescreenrecorder: 0.4.3_2 -> 0.4.4 [FreeBSD]
        texlive-base: 20210325_2 -> 20210325_3 [FreeBSD]
        texworks: 0.6.2_38 -> 0.6.2_39 [FreeBSD]
        tikzit: 2.1.6_14 -> 2.1.6_15 [FreeBSD]
        tor: 0.4.6.10 -> 0.4.7.7 [FreeBSD]
        xfce4-tumbler: 4.16.0_15 -> 4.16.0_16 [FreeBSD]
        xournal: 0.4.8.2016_35 -> 0.4.8.2016_36 [FreeBSD]
        xreader: 3.2.2_4 -> 3.2.2_5 [FreeBSD]

Installed packages to be REINSTALLED:
        pkg-1.17.5_1 [FreeBSD]

Number of packages to be installed: 3
Number of packages to be upgraded: 60
Number of packages to be reinstalled: 1

The operation will free 38 MiB.
8 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching pkg-1.17.5_1.pkg: 100%    8 MiB   4.3MB/s    00:02   
[1/66] Upgrading python38 from 3.8.13 to 3.8.13_1...
[1/66] Extracting python38-3.8.13_1: 100%
…
root@mowa219-gjp4-8570p-freebsd:~ # umount /tmp/up/dev
root@mowa219-gjp4-8570p-freebsd:~ # grep firefox-100 /tmp/up/var/log/messages
grep: /tmp/up/var/log/messages: No such file or directory
root@mowa219-gjp4-8570p-freebsd:~ # bectl umount n255078-e140d551b78-b
root@mowa219-gjp4-8570p-freebsd:~ # grep firefox-100 /var/log/messages
root@mowa219-gjp4-8570p-freebsd:~ # bectl destroy n255078-e140d551b78-b
root@mowa219-gjp4-8570p-freebsd:~ # rm -r /tmp/up
root@mowa219-gjp4-8570p-freebsd:~ #
```


----------



## grahamperrin@ (Apr 30, 2022)

An upgrade of packages, _with_ logging, using the `--rootdir` option of pkg(8):


```
root@mowa219-gjp4-8570p-freebsd:~ # file /tmp/up
/tmp/up: cannot open `/tmp/up' (No such file or directory)
root@mowa219-gjp4-8570p-freebsd:~ # du -hs /var/cache/pkg
1.5M    /var/cache/pkg
root@mowa219-gjp4-8570p-freebsd:~ # bectl create n255078-e140d551b78-b
root@mowa219-gjp4-8570p-freebsd:~ # bectl mount n255078-e140d551b78-b /tmp/up
Successfully mounted n255078-e140d551b78-b at /tmp/up
root@mowa219-gjp4-8570p-freebsd:~ # time pkg -r /tmp/up upgrade --fetch-only --quiet --yes
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
13.197u 9.230s 1:58.92 18.8%    2487+519k 1965+45686io 2950pf+0w
root@mowa219-gjp4-8570p-freebsd:~ # time pkg -r /tmp/up upgrade --quiet --yes
===> Creating groups.
Using existing group '_tor'.
===> Creating users
Using existing user '_tor'.
===> Creating homedir(s)
===> Creating groups.
Using existing group 'saned'.
===> Creating users
Using existing user 'saned'.
=====
Message from qpdfview-0.4.18_28:

--
===>   NOTICE:

The qpdfview port currently does not have a maintainer. As a result, it is
more likely to have unresolved issues, not be up-to-date, or even be removed in
the future. To volunteer to maintain this port, please create an issue at:

https://bugs.freebsd.org/bugzilla

More information about port maintainership is available at:

https://docs.freebsd.org/en/articles/contributing/#ports-contributing
44.331u 49.918s 5:12.33 30.1%   2361+519k 21045+152460io 953pf+0w
root@mowa219-gjp4-8570p-freebsd:~ # grep firefox-100 /var/log/messages
root@mowa219-gjp4-8570p-freebsd:~ # grep firefox\ upgraded /var/log/messages
Apr 30 18:35:14 mowa219-gjp4-8570p-freebsd pkg[15148]: firefox upgraded: 99.0.1_2,2 -> 100.0,2
root@mowa219-gjp4-8570p-freebsd:~ # bectl umount n255078-e140d551b78-b
root@mowa219-gjp4-8570p-freebsd:~ # bectl activate n255078-e140d551b78-b
Successfully activated boot environment n255078-e140d551b78-b
root@mowa219-gjp4-8570p-freebsd:~ # 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 -      -          6.62G 2022-04-09 18:50
n254693-d7696096209-f -      -          1.01G 2022-04-27 17:41
n255078-e140d551b78-a N      /          15.5M 2022-04-28 01:33
n255078-e140d551b78-b R      -          199G  2022-04-30 18:28
root@mowa219-gjp4-8570p-freebsd:~ # exit
logout
% du -hs /var/cache/pkg
1.5M    /var/cache/pkg
%
```

(I'm lazily _not_ using devfs(5).)


----------

