Call for testing: pkgbase support in 15.0

jrm@

jrm@

Developer
In 2003, freebsd-update arrived, allowing users to perform binary updates from one FreeBSD release to another. That's a lot of collective time and energy saved by freeing regular users from building the same sources locally. After a solid 22-year run, freebsd-update support will end with the 14 branch. Its successor is pkgbase, which, as the name suggests, packages FreeBSD's base system. In short, the base system can now be managed similarly to third-party packages. To update from one point release to another, simply run pkg upgrade.

In late April, key work landed in the main branch to enable fresh installations of FreeBSD with pkgbase support [0]. Existing systems running 14.0 or later can also be managed with pkgbase after running pkgbasify, a tool created under sponsorship from the FreeBSD Foundation to convert existing systems.

We encourage everyone to test pkgbase on spare or test hardware, using either the installer from one of the latest 15.0 snapshot images or pkgbasify. Please note that while most of the preliminary feedback has been positive, this work is still experimental; you should only test on systems you can afford to lose and reinstall.

Some outstanding work is planned:
  • FreeBSD handbook documentation
  • Offline installation support (install media packages)
  • Working bootonly.iso
  • Pkgbase-based local and cloud VM images.
The 15.0 release schedule lists the code slush starting on August 8, so the deadline for this work is only a few months away. Please test early and often. Issues can be reported in Bugzilla using a bug subject prefixed with 'pkgbase:'

Thanks,
Joe

[0] For now, the installer only offers network pkgbase installs; support for installing from optical media or USB images will land soon. Also, a known problem with the bootonly.iso will be fixed soon.
 
I have read the wiki pkgbase entry and the forum thread on the subject, and (assuming the information is up-to-date) I am worried. It looks much more complicated than freebsd-update and there are many pitfalls for the less competent.

I did not know until recently that this was coming, and that it is a one-way transition with no going back. It is at an early stage in end-user testing yet a decision has already been made to go ahead with it.

I like Linux because it gave me a way to escape from Windows 8 when it was being forced on me, and I have been hoping that FreeBSD would give me a way to leave Linux (I feel that Linux is becoming more like commercial operating systems in that I have less control over what is installed and I don’t know what it’s doing). OpenBSD would not be a total solution because there are fewer books and articles about it than for FreeBSD, and there are some things that OpenBSD does not permit (or makes quite difficult for the sake of security).

Is it not possible to implement pkgbase as an alternative to freebsd-update so that the two systems can be compared? I have yet to see any compelling reason to adopt it.

Compelling users to migrate if they want to receive upgrades and security patches in future to an untested and uncertain future is not what I would expect from a free (as in FreeBSD) operating system.

I have started testing a 15.0 PRERELEASE snapshot but it will take several days because I have to build packages from source, and because had I already selected "Traditional" instead of "Packages (Experimental)" without realising the significance.

This is not intended to be a protest, I would just like to know the justification for pkgbase and why a decision has been made at such an early stage in testing. There must be something I am missing. (Thank you for your patience if you read this far.) :)
 
From what I've read, no.
Besides that issue, also related, discussed: a requested/suggested separation of 'pkg' commands whether acting on behalf of pkgbase packages or on 'ordinary' packages (derived from the ports tree) and the use of pkg delete -af (note the explicit use of -f) on base where, given the current set of labelled packages as vital is below 5, is quite impactful.
 
I would really like to save and restore the database for ports pkg (along with /usr/local).

But if that messes up the database for pkgbase that is no longer possible.
 
This sounds like a really good reason for ZFS and boot environments. Create a new BE for 14.x-RLEASE, pkgbasify then look at updating to 15.x
 
Useradd said:
This is not intended to be a protest, I would just like to know the justification for pkgbase and why a decision has been made at such an early stage in testing. There must be something I am missing. (Thank you for your patience if you read this far.) :)
Click to expand...
The forum has countless threads where users complain about freebsd-update (just make a quick research, you'll find them).
Personally I don't have anything against freebsd-update, but may be I've been lucky so far.
Some think freebsd-update is too old, considering its concept from a different time with different needs.
Some are just actually content with it.
It's difficult to make everybody happy ...

Anyway, devs have the last word, so let's move on and we'll see how it goes.
I am pretty sure people had the same debate in the past when pkg came in, now most users enjoy it.
My only request is a well documented procedure for jails upgrade/update.

For those who are afraid by the coming changes, 14-RELEASE will be EOL in March 2027, just saying.
 
I never had any trouble with freebsd-update, only thing that was bothering me is how it deals with changed .config files. I see how it can be very confusing for a new user that they need to manually edit bunch of files and look for <<< and >>>. I never understood why freebsd-update is doing it that way when we already have brilliant tool - etcupdate(8), which was such an improvement over mergemaster(8). Never had one problem on STABLE with
Code: 
make buildworld; make kernel; reboot; etcupdate -p; cd /usr/src/; make installworld; etcupdate -B
As for giving base to the pkg maybe another switch, like --base will be easy enough, sorta: pkg update; pkg upgrade will work as usual and only on pkgs, while pkg update –base; pkg upgrade –base will work only on a base? Similar to how --jail works.
 
Last edited:
In CURRENT and the pre-RELEASE snapshots, you are offered the option to choose pkg to install your system. (Though right now, the snapshots are missing a lot of packages, they have some catching up as they're preparing for the 15 alphas and such).
 
With the recent issues and questions I'm not quite clear on how pkgbase can go live (with no other option) in 15-RELEASE. I've managed to break a number of test systems with it without even trying.

I think I understand why some find it a good idea. However, while I think the backend portions are fine, the userland portion should have a freebsd-update equivalent, if for no other reason than tying in bectl. Also pkg update shouldn't update freebsd-base automatically, it should be an intentional choice not mixed in with the freebsd-ports and freebsd-ports-kmod. Doing all three together should be something that takes extra arguments rather than being the default, right now you can either do them all, do them one at a time, or play games with the configs.
 
dkh said:
With the recent issues and questions I'm not quite clear on how pkgbase can go live (with no other option) in 15-RELEASE. I've managed to break a number of test systems with it without even trying.

I think I understand why some find it a good idea. However, while I think the backend portions are fine, the userland portion should have a freebsd-update equivalent, if for no other reason than tying in bectl. Also pkg update shouldn't update freebsd-base automatically, it should be an intentional choice not mixed in with the freebsd-ports and freebsd-ports-kmod. Doing all three together should be something that takes extra arguments rather than being the default, right now you can either do them all, do them one at a time, or play games with the configs.
Click to expand...
From what I understand, with FreeBSD 15.n pkgbase will be an option during installation. I will wait for FreeBSD 16.n to switch
 
For what it's worth, I recently updated my system running 14.3-RELEASE to pkgbase using the pkgbasify script, and I had no issues whatsoever – it worked perfectly. I hated freebsd-update so much because it is extremely slow, and pkgbase has basically solved that problem.

The only real drawback has been that my system runs a bunch of jails that I set up using Bastille, and those jails still use freebsd-update. I don't think Bastille has been updated to permit jails to use pkgbase.

So, I'm wholly supportive of pkgbase and I think it's great. The only drawback is that it's unclear what the status of the base.txz distribution archive will be – I use that file to create sysroots for cross compilation, and it goes away, it's not clear what the alternative will be.
 
NiftySpace said:
For what it's worth, I recently updated my system running 14.3-RELEASE to pkgbase using the pkgbasify script, and I had no issues whatsoever – it worked perfectly. I hated freebsd-update so much because it is extremely slow, and pkgbase has basically solved that problem.

The only real drawback has been that my system runs a bunch of jails that I set up using Bastille, and those jails still use freebsd-update. I don't think Bastille has been updated to permit jails to use pkgbase.

So, I'm wholly supportive of pkgbase and I think it's great. The only drawback is that it's unclear what the status of the base.txz distribution archive will be – I use that file to create sysroots for cross compilation, and it goes away, it's not clear what the alternative will be.
Click to expand...
As a user of Bastille, I’m also wondering what the path forward is.

Will we still create jails by fetching and extraction base.txz?
 
I tried pkgbasify, and I am not sure what I missed, but suddenly my user didn't exist. I rebooted in single user reset root's pass and then re-added my scottro user. (home directory was intact, and once I reset scottro's password back the usual everything worked including key only log in from another machine.
It had created a pre pkgbasify BE that I could have used, but I wanted to see what had gone wrong--though I've not figured it out. But it's back to normal.
I don't feel I can report a bug to pkgbasify because I'm not sure what I missed and if it was just simple user error.

On a different note, I'd never had to boot into a saved working boot environment, and didn't realize that once you hit 8 for boot environments, you have to hit 2, which is for the default, and keep hitting 2 until you see the alternate environments. Just mentioning that in case it happens to others. I don't see any mention of it on the forums, but I doubt I'm the only one here who couldn't figure it out. Or...hey, maybe I am. https://srobb.net/stupid.mp4 (4 second video)

EDIT: In the end, I did have to boot into the pre-pkgbasify Boot Environtment. My pkg database is all messed up in the new one. So, I may try again, but not today I have a headache.
EDIT 2: I tried once again, and all went smoothly--don't know what happened the first time, it's just a matter of downloading the lua script and running pkgbasify.lua and it should all go smoothly. The second time, it did.
 
gotnull said:
The forum has countless threads where users complain about freebsd-update (just make a quick research, you'll find them).
Personally I don't have anything against freebsd-update, but may be I've been lucky so far.
Some think freebsd-update is too old, considering its concept from a different time with different needs.
Some are just actually content with it.
It's difficult to make everybody happy ...

Anyway, devs have the last word, so let's move on and we'll see how it goes.
I am pretty sure people had the same debate in the past when pkg came in, now most users enjoy it.
My only request is a well documented procedure for jails upgrade/update.

For those who are afraid by the coming changes, 14-RELEASE will be EOL in March 2027, just saying.
Click to expand...

The way I see it, FreeBSD makes massive controversial changes every 5 major releases.
  • The changes in FreeBSD 5.0 were enough to bring about the DragonFlyBSD fork
  • The changes in FreeBSD 10.0 didn't seem to bother anyone too much
  • So maybe FreeBSD 15.0 might bring about another fork? Who knows.
Me, I was originally excited about PKG base. However that's changed after learning more about how it's been implemented. I'm genuinely worried that FreeBSD is turning into a Linux Distro.
 
Apparently this was always "the BSD way". I guess it's fair enough if the developers make the decisions, since we don't pay for it and it's probably much quicker than trying to get a consensus among all users.

NetBSD discussion from 2000:
"the BSD way - find something that looks
to be better (in the opinion of the small group deciding such things),
implement it, and ship it."
 
Two of my sort of test installs of 14.3-RELEASE, which have been pkgbasified, when I ran pkg update, pkg upgrade, updated a whole lot of FreeBSD-base stuff. (These had already been upgraded to the latest freebsd-update upgrade. I let them upgrade, as I was curious (though I did create a boot environment of the working system), and they seem fine. Neither are too important, but both have continued working, one as a secondary workstation, the other as something to store backups on, so it probably doesn't use anything much besides ssh and rsync. I'm still getting used to pkgbase, not sure, for example, how to specify pkg should only update 3rd party packages unless called with something like
Code: 
pkg upgrade FreeBSD-base
 
scottro said:
how to specify pkg should only update 3rd party packages
Click to expand...
you can do this with pkg upgrade -r FreeBSD on 14.x, or if you're on a recent stable/15 or main, pkg upgrade -r FreeBSD-ports since the repository was renamed. you can also use pkg upgrade -r FreeBSD-base to only upgrade the base system and not ports.

note that base and ports are still in the same pkg(8) database, so if there are changed dependencies (like the recent libutil and OpenSSL changes in main) this might not work as expected -- always review pkg's proposed plan to make sure it's doing what you expect it to do. this shouldn't be an issue for release builds or post-release stable branches, since library sonames don't change there.

victort said:
Will we still create jails by fetching and extraction base.txz?
Click to expand...

you can still do that for 15.0 if you want, but in 16.0 freebsd-update will no longer work, so if you continue to use dist sets for jails you'll have to update them some other way. if you want to create jails with pkgbase, this is pretty simple: pkg -r /jails/myjail install FreeBSD-set-base. if you prefer to use bsdinstall jail, it now prompts you whether you want to use dist sets or pkgbase to install the jail. sorry, i don't know how Bastille will handle that.

NiftySpace said:
The only drawback is that it's unclear what the status of the base.txz distribution archive will be – I use that file to create sysroots for cross compilation, and it goes away, it's not clear what the alternative will be.
Click to expand...

you can cross-install the base system with pkg:

Code: 
# pkg -oABI=FreeBSD:16:powerpc64le -r /tmp/jail install freebsd-set-minimal
[...]
# file /tmp/jail/bin/ls
/tmp/jail/bin/ls: ELF 64-bit LSB pie executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 16.0 (1600000), FreeBSD-style, stripped
 
You must log in or register to reply here.
Back
Top