pkgbase vs bectl?

D

djfiander

The old freebsd-update system (which I'm still using on almost all my systems) created a new boot environment when it installed a patch, but pkg doesn't. I understand why; it's not like pkg knows that this "pkg upgrade" is upgrading base, necessarily, but it might be nice to add an option to pkg to create a boot environment during pkg installation/upgrade.

Also, the errata notices give information for performing a binary system update using freebsd-update, but don't provide instructions for doing so with pkgbase.
 
djfiander said:
I understand why; it's not like pkg knows that this "pkg upgrade" is upgrading base, necessarily, but it might be nice to add an option to pkg to create a boot environment during pkg installation/upgrade.
Click to expand...
Release 15 is something in between, pkgbase is supported, but not recommanded by the installer if I am not mistaken, it is "tech preview", so it says it all, if you want it then take it as it is(that's how I see it).
Give the devs some time to add all the features freebsd-update already have, release 16 might be better in this regard.

Personally I use my personal script for any upgrade, it creates a BE mount it then performs the upgrade in it. So far so good, I am not a professional, so careful it might not be bullet proof.
 
gotnull, that's correct, it's marked as Tech Preview. It was still marked that last time I tried FBSD-16-CURRENT snapshot, so I don't know if it will change by the time 16 comes out. (Snapshot is from 2026-01-13, if anyone cares).
 
djfiander said:
it's not like pkg knows that this "pkg upgrade" is upgrading base, necessarily, but it might be nice to add an option to pkg to create a boot environment during pkg installation/upgrade.
Click to expand...
This is a reasonable idea, but since "I" never know, creating a new BE would almost need to be the default; either I add the option or the option defaults to "true".
One could do magic with pkg upgrade -n | grep pkg base stuff to help decide "yep need to create a BE", but is that more work than just always create a new BE?
Always creating a new BE means you need to periodically do "bectl list" and "bectl destroy -o" to keep BEs managable (like snapshots, BE reproduce at the same rate as rabbits, nominally 5 litters per year after about 6 months, 3 to 4 babies per litter)
If one follows quarterly, perhaps managable, but one could miss out of band security updates.

I personally don't know the "right thing" to do, just we (the community) needs more documentation, comparing pkgbase to freebsd-update and really thinking about edge cases.

gotnull thanks for sharing script.
 
In Solaris 11.4 pkg decides whether or not to create a New Boot environment when a Patch or a monthly service repository upgrade is processed.


I believe that FreeBSD should also do that. The trigger for this New Boot environment should be provided in the PATCH !

as an example:

In a future upgrade from FreeBSD 16-Release to Freebsd 16-P1 a flag in the "Patch Header" should trigger a new Boot environment if Boot filesystem is ZFS.

Doing this may rescue a lot of installations in the event of an issue.

Regards
 
gotnull said:
Release 15 is something in between, pkgbase is supported, but not recommanded by the installer if I am not mistaken, it is "tech preview", so it says it all, if you want it then take it as it is(that's how I see it).
Give the devs some time to add all the features freebsd-update already have, release 16 might be better in this regard.

Personally I use my personal script for any upgrade, it creates a BE mount it then performs the upgrade in it. So far so good, I am not a professional, so careful it might not be bullet proof.
Click to expand...
Hi
Your script is very useful in my pkgbase zfs environment.
I've always used:
alias up 'pkg upg -n'
But this is cleaner:
alias upsafe '/root/bin/upsafe'
upsafe` (is your script.)
Thanks
 
scottro said:
gotnull, that's correct, it's marked as Tech Preview. It was still marked that last time I tried FBSD-16-CURRENT snapshot, so I don't know if it will change by the time 16 comes out. (Snapshot is from 2026-01-13, if anyone cares).
Click to expand...
I believe that pkgbase should be official when 16.0-RELEASE will be out, devs have 2 years to work on it, it surely will be in better shape than what it it now, will see :)

mer said:
gotnull thanks for sharing script.
Click to expand...
You're welcome ;)
I took a lot from the community (wise advice, good how-to, nice writings) for years so if I can share something useful from time to time, I do it.

fjdlr said:
Hi
Your script is very useful in my pkgbase zfs environment.
I've always used:
alias up 'pkg upg -n'
But this is cleaner:
alias upsafe '/root/bin/upsafe'
upsafe` (is your script.)
Thanks
Click to expand...
Glad it helps ;)
I agree the name is probably not easy to write for daily use.
I picked that name mainly because it is easy to remember what it does just by looking at its name, I do that now because after few months/years I usually forget why I called a script like this and what it does, so now I avoid troubles by picking a long and boring name ^^


drsnx60 nice, It sounds like a great idea for our FreeBSD devs.
 
pkg(8) seemingly has a 'plugin' infrastructure. Doesn't seem to be used at the moment, also couldn't find much documentation about it. But I suspect it might be possible to write a plugin that automatically creates a bectl(8) snapshot (similar to what freebsd-update(8) does) with every pkg upgrade run.

Code: 
dice@armitage:~ % pkg plugins -l
NAME       DESC                                          VERSION
dice@armitage:~ %

There's only a cursory mention in pkg(8), and there's no pkg-plugins(8). So I haven't quite figured out how you could use it.
 
I believe at some point freebsd-update is meant to be re-implemented to make use of pkgbase and as such would carry the boot environment functionality along with it. (hopefully I didn't imagine reading that but it's been a few months:)
 
SirDice said:
So I haven't quite figured out how you could use it.
Click to expand...

There is one plugin ports-mgmt/pkg-provides, I've already used it in the past but honestly I totally forgot that it was a so called "plugin".
This is the message displayed by pkg during its installation:

Code: 
~ > pkg info --pkg-message pkg-provides
pkg-provides-0.7.4:
On install:
In order to use the pkg-provides plugin you need to enable plugins in pkg.
To do this, uncomment the following lines in /usr/local/etc/pkg.conf file
and add pkg-provides to the supported plugin list:

PKG_PLUGINS_DIR = "/usr/local/lib/pkg/";
PKG_ENABLE_PLUGINS = true;
PLUGINS [ provides ];

After that run `pkg plugins' to see the plugins handled by pkg.

On upgrade:
To update the provides database run `pkg provides -u`.

So I did what the message says and it works.
Code: 
~ > pkg plugins    
NAME       DESC                                          VERSION   
provides   A plugin for querying which package provides a particular file 0.7.4

The package installs a binary written in C I believe:
Code: 
~ > file /usr/local/lib/pkg/provides.so
/usr/local/lib/pkg/provides.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 (1500068), stripped

At this point I am not sure shell scripts can work as plugins, C is probably more efficient for pkg, skilled coder will be needed for that, not me ^^
Also I failed to find other plugins other than pkg-provides, which makes me wonder if plugins are still a thing? I think odd not being able to find documentation about it except manpage pkg.conf() which is pretty light.
 
scottro said:
Yes, the handbook, last I looked, seemed a bit behind. I have a page on it, covering a few things that I didn't find at the time, much of it based upon posts here (and some reddit ones) at https://srobb.net/fbsd14_15.html, including using bectl to give you a fallback.
Click to expand...

Hi scottro,​

following your steps, I failed already at the first step,
gitup release
# Scanning local repository...
# Host: git.freebsd.org
# Port: 443
# Repository Path: /src.git
# Target Directory: /usr/src
# Want: 5cf7232732d5cb047e50233b1d668961ebbbf288
# Branch: releng/15.0
gitup: fetch_pack: malformed pack data:

: Inappropriate file type or format
Click to expand...
What am I missing here?
 
Hrrm, that's new. I've seen that on some CURRENT VMs, but haven't seen it on a RELEASE. I'm honestly not sure. It looks as if something's wrong with the branch, hopefully, someone with more knowledge can chime in.
 
I do not use gitup so I can't verify, but after reading this comment and looking at the gitup requirement which says:
For integrity of data and metadata:

if a working directory includes a .git subdirectory, a gitup command will not proceed
if a working directory is non-empty and lacks a .git subdirectory, git will not proceed.
Click to expand...

Then I would advice, if it's not already the case, to have a clean working directory where gitup can pull the source, again I didn't test this but it seems a good starting point.

PS:
I almost forgot to thank you scottro for your article. Keep it up mate!
 
I'm also wondering--maybe someone knows, sees this, and can answer--if we still need the
/usr/share/keys/pkgbase-15 or if you can now use what's in the wiki, the /usr/share/keys/pkg. If I have time today I might throw together a VM and see. If anyone knows and could answer, that would be good.
 
scottro said:
if we still need the
/usr/share/keys/pkgbase-15
Click to expand...
I assume this is going to stay this way for the duration of the 15 branch, commit - 2025-11-15:
Code: 
Add pkgbase signing keys for FreeBSD 15

These keys were generated by cperciva@ using the AWS Key Management
Service.  They will not be used for signing anything other than
FreeBSD 15.x pkgbase repositories.

Keys will be generated for FreeBSD 16 at a later date, and likely in
a different way.

With hat:	re
MFC after:	8 hours (needed in 15.0-RC1)
Differential Revision:	https://reviews.freebsd.org/D53768
IIRC, this wasn't what Colin Percival had in mind; and in the follow up commit you can see that there was a backup site created. During the pre-release cycle of FreeBSD 15.0-RELEASE the location of the keys changed rather unexpectedly (I think that was during the BETA-s).
 
Erichans said:
I assume this is going to stay this way for the duration of the 15 branch, commit - 2025-11-15:
Code: 
Add pkgbase signing keys for FreeBSD 15

These keys were generated by cperciva@ using the AWS Key Management
Service.  They will not be used for signing anything other than
FreeBSD 15.x pkgbase repositories.

Keys will be generated for FreeBSD 16 at a later date, and likely in
a different way.

With hat:    re
MFC after:    8 hours (needed in 15.0-RC1)
Differential Revision:    https://reviews.freebsd.org/D53768
IIRC, this wasn't what Colin Percival had in mind; and in the follow up commit you can see that there was a backup site created. During the pre-release cycle of FreeBSD 15.0-RELEASE the location of the keys changed rather unexpectedly (I think that was during the BETA-s).
Click to expand...
I'd wondered about this as well, but I can say that when I did a fresh install of a 15.0-STABLE snapshot last month the path in the fingerprints lines is /usr/share/keys/pkg.
 
You must log in or register to reply here.
Back
Top