Successfully (?) updated from 14.3 to 15-ALPHA5 a pkgbase-converted system.

F

fmc000

I just finished updating my test system. It ended up fine but it wasn't easy to say the least.

First of all I had to adjust the base repository config file to track "base_latest" (as expected) and the kmod repository config file to track "latest" (otherwise the following step doesn't work).

Second step set the ABI and launch the upgrade. This step failed many times because of conflicts generated within /usr/local/lib/compat/pkg. My solution was to remove everything from that directory and relaunch the upgrade command. It took maybe 20-30 iterations but it eventually the upgrade finished.

Third step: reboot of course. The system came up without errors. It even loaded the radeonkms driver and all the relative firmware stuff but no X.

The fourth step was completely unexpected to me: I had to reinstall all the ports that I had explicitly installed before (xorg, xorg-drivers, cinnamon, librewolf, roxterm, lightdm, mpv to name a few). Rebooted and all was fine.

Now pkg complains about a couple of conflicts but I haven't looked at them yet.

Hope this helps and I would like to know if I did something wrong.
 
SirDice said:
You have to do this with every major version upgrade. After a major version upgrade you must reinstall all ports/packages due to ABI changes in the base OS.
Click to expand...
Ok I didn't know that, thank you. That's my first major upgrade, as I started using FreeBSD with 14.1 .
 
fmc000 said:
That's my first major upgrade
Click to expand...
With a minor version upgrade, from 14.1 to 14.3 for example, the ABI is not allowed to change. So any userland application built on 14.0 will work just fine on 14.9 (fictitious version, to illustrate the point). With a major version change the ABI is allowed to change. Due to the ABI changes you have rebuild everything in order to correctly link to various base OS libraries that have been updated.

There's a 'stop-gap' you could use misc/compat14x, this will allow you to run (userland) applications built for 14 to run on 15. But it's a cludge and should really only be used if you can't rebuild (or reinstall) the application (closed source, third party software for example).
 
fmc000 said:
Second step set the ABI and launch the upgrade. This step failed many times because of conflicts generated within /usr/local/lib/compat/pkg. My solution was to remove everything from that directory and relaunch the upgrade command. It took maybe 20-30 iterations but it eventually the upgrade finished.
Click to expand...
are you using the BACKUP_LIBRARIES option with pkg? there is a known issue where this doesn't work properly with pkgbase (although it should): https://github.com/freebsd/pkg/issues/2501

also for future reference, you should first upgrade the kernel (pkg upgrade FreeBSD-kernel-generic), then reboot, then upgrade everything else and reboot again. not doing that may work by accident, but it can easily leave you with a broken system. this is the same way you upgrade using freebsd-update or with a non-pkgbase source upgrade, and pkgbase doesn't change it.
 
anguisette said:
are you using the BACKUP_LIBRARIES option with pkg? there is a known issue where this doesn't work properly with pkgbase (although it should): https://github.com/freebsd/pkg/issues/2501

also for future reference, you should first upgrade the kernel (pkg upgrade FreeBSD-kernel-generic), then reboot, then upgrade everything else and reboot again. not doing that may work by accident, but it can easily leave you with a broken system. this is the same way you upgrade using freebsd-update or with a non-pkgbase source upgrade, and pkgbase doesn't change it.
Click to expand...
I don't use that option, at least I did not set it explicitly.

Four the second part, can this be documented in the pkgbase page in the wiki? I followed that page and the kernel upgrade procedure is not mentioned at all.
 
fmc000 said:
BTW, would something like pkg install -af be sufficient for this purpose?
Click to expand...
I would just nuke the localbase and reinstall everything from scratch with a fresh pkg database. Specificially by doing this:
Code: 
pkg query -e '%a = 0' %o > ~/pkgs.txt
pkg remove -a
pkg upgrade -f pkg
pkg install $(cat ~/pkgs.txt)
 
kenrap said:
I would just nuke the localbase and reinstall everything from scratch with a fresh pkg database. Specificially by doing this:
Code: 
pkg query -e '%a = 0' %o > ~/pkgs.txt
pkg remove -a
pkg upgrade -f pkg
pkg install $(cat ~/pkgs.txt)
Click to expand...
Mmhhh, I don't feel confident in removing all the packages in a pkgbase system, especially as it is just after a major release upgrade.
 
fmc000 said:
Four the second part, can this be documented in the pkgbase page in the wiki? I followed that page and the kernel upgrade procedure is not mentioned at all.
Click to expand...
the upgrade documentation on the wiki is extremely out of date... i think it makes more sense to document this properly in the Handbook, which needs to happen at some point before release anyway.
 
fmc000 said:
BTW, would something like pkg install -af be sufficient for this purpose?
Click to expand...
No, pkg doesn't have a -a option for pkg-install(8). The Handbook recommended way, 26.2.3.2. Upgrading Packages After a Major Version Upgrade, is using pkg-static upgrade -f
With a major upgrade new binaries, including libraries, will have been installed. "Ordinary" pkg(8) relies on these to-be-dynamically linked libraries to function. Using pkg-static(8) instead gives extra assurances that the old pkg and matching (statically) linked libraries function as intended; one of the first things that gets upgraded is pkg(8) itself. Therefore, you could split this into:
  1. # pkg-static upgrade -f pkg
  2. # pkg upgrade -f

fmc000 said:
Mmhhh, I don't feel confident in removing all the packages in a pkgbase system, especially as it is just after a major release upgrade.
Click to expand...
There have been quite lot of discussions on the pkgbase and current MLs about the fundamental change in reach of pkg(8) and its companions. pkg(8) now affects base packages too as I noted earlier.

I think the number of base packages labelled vital has been increased. If, however, you want for what ever reason to focus your pkg-x command, such as pkg-delete(8), solely on the traditional packages from the ports tree, you could consider something like:
Code: 
# pkg query -e '%o ~ base/* && %k != 1' '%n' > lock-unlock.list
# pkg lock -y $( cat lock-unlock.list )

 <desired operations on other packages>

# pkg unlock -y $( cat lock-unlock.list )
This way any already locked base packages persist.

I still recommend using the two-step upgrade process for packages from the remote package servers wrt respect to the FreeBSD and FreeBSD-kmods repositories because I haven't seen conclusive changes where pkg (including v 2.3.1) is able to work with multiple enabled repositories in the most general case; though I don't have extensive experience in a pkgbasified environment if that changes things at all.
 
So this is my plan for my future upgrades:

Code: 
# user root

vi /usr/local/etc/pkg/repos/FreeBSD-base.conf
 
url = "pkg+https://pkg.freebsd.org/${ABI}/base_latest";
 
vi /usr/local/etc/pkg/repos/FreeBSD-kmods.conf
 
url: "pkg+https://pkg.freebsd.org/${ABI}/kmods_latest";
 
env ABI=FreeBSD:15:amd64 pkg-static upgrade FreeBSD-kernel-generic
 
(reboot)

env ABI=FreeBSD:15:amd64 pkg-static upgrade

(reboot)
 
env ABI=FreeBSD:15:amd64 pkg-static upgrade -f pkg
env ABI=FreeBSD:15:amd64 pkg upgrade -f
 
You must log in or register to reply here.
Back
Top