Solved Sequence of freebsd-update and bectl

P

Peacekeeper2000

I tried to find some hints how the sequence is, when you use freebsd-update and CreateBootEnv yes in /etc/freebsd-update.conf.
let me assume I am currently on patch level x and the next (x+1) is y. Is the sequence to create a snapshot first and name it ..px.. and then install the patches for ...py... so that the current (and running BE ) has this ...py.. patch level ? Or is the snapshot done and the patches are installed in that BE which is then not active ?

Maybe the real situation is a bit easier to understand. I know, that I renamed default into p5 at that time. So it looks like p5 is no longer the valid name as all snapshots sum up under this BE. Do I make the correct assumption that freebsd-update makes a snapshot of the current system (before patching) and also build with that snapshot a new BE ?
And also that after patching no snapshot is done ?

What is the best name für the current BE ? ( default or 13.1-RELEASE ?) I think I have ruined the numbering scheme by renaming to patch p5. I assume p6 is now the second p5 and the current p6 should be p7 ...

Code: 
% bectl list
BE                                Active Mountpoint Space Created
13.1-RELEASE-p2_2022-09-19_193909 -      -          504K  2022-09-19 19:39
13.1-RELEASE-p2_2022-11-04_203927 -      -          89.9M 2022-11-04 20:39
13.1-RELEASE-p3_2022-11-23_231327 -      -          101M  2022-11-23 23:13
13.1-RELEASE-p4_2022-12-01_211006 -      -          205M  2022-12-01 21:10
13.1-RELEASE-p5                   NR     /          2.85G 2022-11-04 20:20
13.1-RELEASE-p5_2023-02-10_150941 -      -          189M  2023-02-10 15:09
13.1-RELEASE-p6_2023-02-18_230748 -      -          44.7M 2023-02-18 23:07

Code: 
bectl list -a
BE/Dataset/Snapshot                                  Active Mountpoint Space Created

13.1-RELEASE-p2_2022-09-19_193909
  zroot/ROOT/13.1-RELEASE-p2_2022-09-19_193909       -      -          8K    2022-09-19 19:39
    zroot/ROOT/13.1-RELEASE-p5@2022-09-19-19:39:09-0 -      -          496K  2022-09-19 19:39

13.1-RELEASE-p2_2022-11-04_203927
  zroot/ROOT/13.1-RELEASE-p2_2022-11-04_203927       -      -          8K    2022-11-04 20:39
    zroot/ROOT/13.1-RELEASE-p5@2022-11-04-20:39:27-0 -      -          89.9M 2022-11-04 20:39

13.1-RELEASE-p3_2022-11-23_231327
  zroot/ROOT/13.1-RELEASE-p3_2022-11-23_231327       -      -          8K    2022-11-23 23:13
    zroot/ROOT/13.1-RELEASE-p5@2022-11-23-23:13:27-0 -      -          101M  2022-11-23 23:13

13.1-RELEASE-p4_2022-12-01_211006
  zroot/ROOT/13.1-RELEASE-p4_2022-12-01_211006       -      -          8K    2022-12-01 21:10
    zroot/ROOT/13.1-RELEASE-p5@2022-12-01-21:10:06-0 -      -          205M  2022-12-01 21:10

13.1-RELEASE-p5
  zroot/ROOT/13.1-RELEASE-p5                         NR     /          2.85G 2022-11-04 20:20

13.1-RELEASE-p5_2023-02-10_150941
  zroot/ROOT/13.1-RELEASE-p5_2023-02-10_150941       -      -          8K    2023-02-10 15:09
    zroot/ROOT/13.1-RELEASE-p5@2023-02-10-15:09:41-0 -      -          189M  2023-02-10 15:09

13.1-RELEASE-p6_2023-02-18_230748
  zroot/ROOT/13.1-RELEASE-p6_2023-02-18_230748       -      -          8K    2023-02-18 23:07
    zroot/ROOT/13.1-RELEASE-p5@2023-02-18-23:07:48-0 -      -          44.7M 2023-02-18 23:07
Code: 
bectl list -s
BE/Dataset/Snapshot                                  Active Mountpoint Space Created

13.1-RELEASE-p2_2022-09-19_193909
  zroot/ROOT/13.1-RELEASE-p2_2022-09-19_193909       -      -          8K    2022-09-19 19:39
    zroot/ROOT/13.1-RELEASE-p5@2022-09-19-19:39:09-0 -      -          496K  2022-09-19 19:39

13.1-RELEASE-p2_2022-11-04_203927
  zroot/ROOT/13.1-RELEASE-p2_2022-11-04_203927       -      -          8K    2022-11-04 20:39
    zroot/ROOT/13.1-RELEASE-p5@2022-11-04-20:39:27-0 -      -          89.9M 2022-11-04 20:39

13.1-RELEASE-p3_2022-11-23_231327
  zroot/ROOT/13.1-RELEASE-p3_2022-11-23_231327       -      -          8K    2022-11-23 23:13
    zroot/ROOT/13.1-RELEASE-p5@2022-11-23-23:13:27-0 -      -          101M  2022-11-23 23:13

13.1-RELEASE-p4_2022-12-01_211006
  zroot/ROOT/13.1-RELEASE-p4_2022-12-01_211006       -      -          8K    2022-12-01 21:10
    zroot/ROOT/13.1-RELEASE-p5@2022-12-01-21:10:06-0 -      -          205M  2022-12-01 21:10

13.1-RELEASE-p5
  zroot/ROOT/13.1-RELEASE-p5                         NR     /          2.85G 2022-11-04 20:20
  13.1-RELEASE-p5@2022-09-19-19:31:40                -      -          624K  2022-09-19 19:31
  13.1-RELEASE-p5@2022-09-19-19:39:09-0              -      -          496K  2022-09-19 19:39
  13.1-RELEASE-p5@2022-11-04-20:39:27-0              -      -          89.9M 2022-11-04 20:39
  13.1-RELEASE-p5@2022-11-23-23:13:27-0              -      -          101M  2022-11-23 23:13
  13.1-RELEASE-p5@2022-12-01-21:10:06-0              -      -          205M  2022-12-01 21:10
  13.1-RELEASE-p5@2023-02-10-15:09:41-0              -      -          189M  2023-02-10 15:09
  13.1-RELEASE-p5@2023-02-18-23:07:48-0              -      -          44.7M 2023-02-18 23:07

13.1-RELEASE-p5_2023-02-10_150941
  zroot/ROOT/13.1-RELEASE-p5_2023-02-10_150941       -      -          8K    2023-02-10 15:09
    zroot/ROOT/13.1-RELEASE-p5@2023-02-10-15:09:41-0 -      -          189M  2023-02-10 15:09

13.1-RELEASE-p6_2023-02-18_230748
  zroot/ROOT/13.1-RELEASE-p6_2023-02-18_230748       -      -          8K    2023-02-18 23:07
    zroot/ROOT/13.1-RELEASE-p5@2023-02-18-23:07:48-0 -      -          44.7M 2023-02-18 23:07
Code: 
freebsd-version -ukr
13.1-RELEASE-p6
13.1-RELEASE-p6
13.1-RELEASE-p7
 
Example,
You run kernel x.
You create a boot environment and name it x.
You freebsd-update towards kernel y.
Before reboot you still run kernel x but kernel y is installed.
You create a boot environment named y.
You reboot and run kernel y.

If there would be a problem you chose x in the bootloader.
 
freebsd-update is a shell script. You can check the section of # Create a boot environment if enabled inside less /usr/sbin/freebsd-update to see how the bectl is used there.

Code: 
 if [ ${CREATEBE} = yes ]; then
                        echo -n "Creating snapshot of existing boot environment... "
                        VERSION=`freebsd-version -ku | sort -V | tail -n 1`
                        TIMESTAMP=`date +"%Y-%m-%d_%H%M%S"`
                        bectl create ${VERSION}_${TIMESTAMP}
                        if [ $? -eq 0 ]; then
                                echo "done.";
                        else
                                echo "failed."
                                exit 1
                        fi
                fi
 
Thanks Alain. Just to be clear: currently I am not creating a BE. That is all done by freebsd-update (inc. the naming of the snapshot and BE ). Manually I would also do your sequence. But I let freebsd-update do the steps. And it seems for me, that the last step is missing: renaming the current BE into ...py... ( in the above example p7 )
 
VladiBG said:
freebsd-update is a shell script. You can check the section of # Create a boot environment if enabled inside less /usr/sbin/freebsd-update to see how the bectl is used there.

Code: 
 if [ ${CREATEBE} = yes ]; then
                        echo -n "Creating snapshot of existing boot environment... "
                        VERSION=`freebsd-version -ku | sort -V | tail -n 1`
                        TIMESTAMP=`date +"%Y-%m-%d_%H%M%S"`
                        bectl create ${VERSION}_${TIMESTAMP}
                        if [ $? -eq 0 ]; then
                                echo "done.";
                        else
                                echo "failed."
                                exit 1
                        fi
                fi
Click to expand...
So it is using the user patch level ( not kernel) and it is called before install_run - means it is the current previous level. It also looks like no touch/renaming of the current running BE
Maybe that is something I will add to the freebsd-update
 
I know this is marked solved, but for those finding it after a search, I found that Mike Lucas, as usual wrote a clear explanation. He is talking about beadm but the commands are identical.
mwl.io

FreeBSD and beadm - Michael W Lucas

One of Solaris' ZFS features is boot environments, where you can install multiple versions of the core operating systems and choose which one to boot into.
mwl.io

It's from 2015, but still valid.
 
Peacekeeper2000 said:
Thanks Alain. Just to be clear: currently I am not creating a BE. That is all done by freebsd-update (inc. the naming of the snapshot and BE ). Manually I would also do your sequence. But I let freebsd-update do the steps. And it seems for me, that the last step is missing: renaming the current BE into ...py... ( in the above example p7 )
Click to expand...
The thing is that the choice of a name for your active BE is purely personal and might not indicate the kernel patch level so there's no way that freebsd-update can determine if or how you might want to rename it. For example I create a new working BE every time I do any major package upgrades and my naming convention reflects the OS level, the package repository version and a fresh index letter for each upgrade. For example I currently have:
Code: 
BE                                Active Mountpoint Space Created
13.1-RELEASE-p5_2023-02-17_201646 -      -          33.6M 2023-02-17 20:16
fbsd13.1q1                        -      -          101M  2023-01-08 10:36
fbsd13.1q1a                       -      -          9.54M 2023-01-13 18:05
fbsd13.1q1b                       -      -          10.2M 2023-02-03 15:19
fbsd13.1q1c                       -      -          1.52M 2023-02-12 11:32
fbsd13.1q1d                       NR     /          34.8G 2023-02-17 20:18
fbsd13.1q4d                       -      -          6.16G 2022-11-11 10:34
I'm quite happy for freebsd-update to create the backup BE to fall back to if the upgrade failed but there's no way I want it to mess around with renaming my active BE
 
Yes, I agree the books from Michael are very good - I have some of them. I was not sure how freebsd-update integrate bectl - doing it by hand is what I have done in the past. From my point of view a last step inside freebsd-update is missing: After installation the renaming of the actual BE to the actual patch level. But that is a simple script that could be included in your private admin toolbox.
 
rawthey said:
The thing is that the choice of a name for your active BE is purely personal and might not indicate the kernel patch level so there's no way that freebsd-update can determine if or how you might want to rename it. For example I create a new working BE every time I do any major package upgrades and my naming convention reflects the OS level, the package repository version and a fresh index letter for each upgrade. For example I currently have:
Click to expand...

rawthey said:
I'm quite happy for freebsd-update to create the backup BE to fall back to if the upgrade failed but there's no way I want it to mess around with renaming my active BE
Click to expand...
Hmm, for those who are doing the standard a set of variables in /etc/freebsd-update.conf could be set.
Code: 
RenameBootEnvToPatchLevel = yes
RenameBootEnvToPatchLevelPrefix = 13.1-RELEASE-

But it is just optional as also the creating of BE through freebsd-update is only an option 😀
 
You must log in or register to reply here.
Back
Top