Solved Boot environment gets wrong name

Lord Bung · Feb 28, 2023

So, the other day I went to upgrade my 13.1-STABLE install from source. I created a new boot environment named 13.1-STABLE-20230224.072050 with the 13.1-STABLE derived from running freebsd-version -k . Well, after all the building and the upgrade, I noticed I was on 13.2-STABLE . So, my BE is named incorrectly. My question is, how do I get the freebsd-version of the STABLE branch of the source code I'm building? Basically, I want to know what freebsd-version -k will output after the upgrade and reboot but before I create the BE, so that I can name it correctly the first time and not need to rename it after the fact.

bsduck · Feb 28, 2023

You can find it in /usr/src/sys/conf/newvers.sh

Code:

TYPE="FreeBSD"
REVISION="13.2"
BRANCH="STABLE"

mer · Feb 28, 2023

bectl rename helps you correct it. I'm assuming you realized that, so just pointing it out.

A question on your procedure:
Did you intend the new BE to be the upgraded system or to be the previous running system?

Basically:
bectl list shows you in a BE named something like 13.1-STABLE-blah
bectl create NEW-BE-NAME
bectl activate NEW-BE-NAME
reboot
now you are in NEW-BE-NAME
upgrade from source
At this point your NEW-BE-NAME is the upgraded system, your old 13.1-STABLE-blah is the old one

OR
bectl list shows you in a BE named something like 13.1-STABLE-blah
bectl create NEW-BE-NAME
upgrade from source this upgrades 13.1-STABLE-blah to the new version, NEW-BE-NAME is the previous
reboot
now you are booted into 13.1-STABLE-blah that has been upgraded to 13.2-STABLE-blah from source

either way you can use the bectl rename command to get things the way you want them.

freebsd-update for binary upgrades creates a new BE by default that is actually the previous one so I routinely fix the names afterwards

Lord Bung · Mar 1, 2023

Thanks bsduck.

Re mer: Yes, I know I can rename it. I'd just rather get it correct the first time if I can, and now that I know where to find the REVISION that seems doable.

I'm pretty new to building from source. This is my second time actually, and the last time was last May. I'm currently building world and kernel in the existing boot environment, creating a new BE, rebooting and installing it in the new BE. Mainly, I think because of the difficulties I've had with this and the uncertainty around this process it has created. I've been using binary packages instead of building them myself, and I think that is what is causing the problem. I'm now trying to get poudriere working, and I'm hoping that by doing things the right way, I'll have many fewer issues.

I would like to change to the second approach you described where the new BE is the old un-upgraded system, but I'm waiting until my upgrades go more smoothly.

bsduck · Mar 1, 2023

Lord Bung said:
I've been using binary packages instead of building them myself, and I think that is what is causing the problem.

Ports and packages don't have any influence on building and upgrading the base system. In that regard it doesn't matter whether you use prebuilt packages or build them yourself.

What kind of problems did you encounter during the upgrade process?

Lord Bung · Mar 1, 2023

My upgrades to the base system have mostly gone fairly well, most of the problem seems to be with the packages. A couple of times now, after updating the packages, upon rebooting I've been left at the command line instead of the display manager starting up. I have not dug into these incidents terribly deeply, but on a previous occasion it was because the zpool wasn't being mounted automatically on reboot. I just figured that out recently. It turns out that a number of scripts had somehow lost executable permissions.

I did not dig into my most recent issue much at all. The base system upgrade went fine, but I did not create a BE before attempting to upgrade the packages. I won't make that mistake again. I instead started over. The base system upgrade went fine again. I'm booted into it now. This time however, I will be creating a BE, and I'm using Poudriere for the first time. It's been building packages for 10 hours now. Ugh. If it completes successfully, I intend to look at the ways to speed it up, i.e. ccache, etc.

Lord Bung · Mar 4, 2023

This is kind of off topic now, but I figured out what the underlying problem was. pkg , whether directed at my poudriere repo or the freebsd repo, was updating my my video driver, nvidia-driver to one that is not supported by my video card. I now have it pkg locked to nvidia-driver-470 .

On a side note, my god it takes a long time to build packages! I have an X11 workstation board with a Xeon E3 processor and 64GB of memory and it still took over 6 hours to build just Eclipse and Chromium.

rawthey · Mar 4, 2023

Lord Bung said:
On a side note, my god it takes a long time to build packages! I have an X11 workstation board with a Xeon E5 processor and 64GB of memory and it still took over 6 hours to build just Eclipse and Chromium.

Yes, compiling some packages can be a major task but unless you have a need to build them with 'non standard' options there's little benefit to be gained from building them from source. Installing binary packages from the FreeBSD repository is much quicker.