Solved Do I run the wrong BE? no.

  • Thread starter Deleted member 43773
  • Start date
D

Deleted member 43773

Guest
I'm trying to get a bit into BE stuff,
looking for obsolete stuff to delete.
So I stumbled over this, which causes me a question:

bectl list gives me:

Code: 
BE                                Active Mountpoint Space Created
13.1-RELEASE-p2_2022-11-06_142413 -      -          1.98G 2022-11-06 14:24
13.1-RELEASE-p3_2022-12-03_094943 -      -          2.67G 2022-12-03 09:49
13.1-RELEASE-p5_2023-02-13_144614 -      -          62.8M 2023-02-13 14:46
13.1-RELEASE-p6_2023-02-16_214715 -      -          110M  2023-02-16 21:47
13.1-RELEASE_2022-09-01_160420    -      -          12.1G 2022-09-01 16:04
default                           NR     /          45.7G 2022-04-06 11:59

So there have been some updates, and new BEs were installed.
I thought, switching to a new BE would be part of the update,
but it seems to me still the BE is used from the original installation I did a year ago, right?

Is this right, or, what I presume, shall i activate say 13.1-RELEASE-p6_2023-02-16_214715 manually?

Do one always have to activate the new BE manually after an update,
or is something messed up with my machine?

Thanks for your answers.
 
BEs are wrappers around zfs snapshots/clones, so you have basically two ways to work with them:
  • Create a new BE, mount it somewhere, install upgrades there "offline" (e.g. using DESTDIR when installing from source), then when done switch to it, while your currently active BE stays untouched.
  • Create a new BE, but carry on with the upgrades in your live system. Then the new BE will just preserve the old state and you could switch to it in case you need to rollback.
It seems freebsd-update(8) is doing the latter approach.
 
Have you just been doing freebsd-update or manually creating new BE and then updating? If you are just doing freebsd-update I believe that it creates a new BE before it updates into the currently active BE, so the new BE is "system state before applying updates" as zirias@ says.

If you look at the timestamps, I'm guessing you installed the system somewhere around 2022-04-06 and last ran freebsd-update 2023-02-16.
That said you could bectl destroy -o everything but the BE named "default" if everything is running correctly.
 
mer said:
I'm guessing you installed the system somewhere around 2022-04-06 and last ran freebsd-update 2023-02-16.
Click to expand...
Yep, exactly.
(well, no, I did the last freebsd-update an hour ago, but there were no new updates available so far. 🤓 )

So, to get this right:
The date of default just shows when it was first installed,
but being updated automatically, when I do freebsd-update (which I only did so far; so never created/removed, did anything with BE manually by myself yet.)
So all the rest are fallback-positions.
Their dates show the last time one may fall back to,
but by default update procedures the most recent one is within default?
 
Yep, that sounds about right to me.
Since my systems are "daily drivers" not test systems, I tend to keep my current BE and the one previous, but others keep more.

from your list, you could bectl destroy -o 13.1-RELEASE_2022-09-01_160420 13.1-RELEASE-p2_2022-11-06_142413 13.1-RELEASE-p3_2022-12-03_094943 13.1-RELEASE-p5_2023-02-13_144614 if you wanted to. You would regain some space and have 2 BEs. The one you are currently using (named default) and what you were running before you ran freebsd-update.

The fun thing is do them one at a time then do bectl list and look at the space. See how it moves around; that's the way snapshots work. Not the way you would expect most of the time
 
I tend to even remove the latest BE after a few weeks of successful operation of the new version on "daily driver" systems. And for patchlevel-upgrades, I don't even use BEs (I always install from source, so have to manage BEs manually anyways). It's all a matter of personal taste and how you personally assess the risks ;)
 
zirias@ said:
I tend to even remove the latest BE after a few weeks of successful operation of the new version on "daily driver" systems.
Click to expand...
Yep. If one is not careful BEs multiply just like rabbits. Crossing releases (say from 12.x to 13.x) I keep the old one around longer until new one is proven successful.

One thing I've learned to be careful with:
zpool upgrade

You can screw yourself if you're not careful and wind up in a non-bootable but recoverable situation.
 
cool.
THANK YOU VERY MUCH, guys!
mer said:
The fun thing is do them one at a time then do bectl list and look at the space. See how it moves around; that's the way snapshots work.
Click to expand...

Yeah, that was I supposed to do.
Since I'm no professional root, I mostly do system administration things, when I have to look at things, e.g. there is an issue.
So my progress of learning is slow 🙃
At the moment I'm still about this ssh-issue i've started another thread about [update will come as soosn as I have more conclusions],
so time again to look for other things.

zirias@ said:
it's all a matter of personal taste and how you personally assess the risks
Click to expand...
😋
I just learned about that BE-stuff in decembre,
and now I gave it a closer look.
What you mention is three steps beyond my horizon.
I recently ddgoed you - you're way out of my league 😁
BUT
I keep such things in mind,
and see them as an inspiration for what else can be done,
and a motiviation to become better. 😎

Thanks again!
 
You must log in or register to reply here.
Back
Top