Does my 14.3 install look correct?

F

froggit9000

I upgraded my 14.1 system to 14.3 and I would like to know if I have everything updated now or not.

From memory I think I followed the update instructions shown at
www.freebsd.org

FreeBSD 14.3-RELEASE Installation Instructions

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org
.

The reason I am doubting everything has been upgraded is that I see different info using 'uname -a' and 'freebsd-version':

Code: 
# uname -a
FreeBSD freebsd 14.3-RELEASE FreeBSD 14.3-RELEASE releng/14.3-n271432-8c9ce319fef7 GENERIC amd64

Kernel:
Code: 
# freebsd-version -k
14.3-RELEASE

Userland:
Code: 
# freebsd-version -u
14.1-RELEASE-p8

So, to me it looks like the kernel is at version 14.3-RELEASE, but the userland is at version 14.1-RELEASE-p8.

So it looks like the fix is to upgrade the userland to 14.3-RELEASE too, is that correct, and if so how do I do that?

Sorry if this is a newbie question.
 
Assuming you've used freebsd-update(8) to upgrade.
Have you run second (and possbly more) run (as root) of freebsd-update install?

You may want to read Chapter 26.2.3 of the handbook.


Maybe excessive details:

I myself use source upgrades everytime (tried freebsd-update(8) almost only when it was first introduced and next major upgrade), but if I recall correctly, In some cases, it first installs updated kernel, and in next run, install updated userland.

As updated userland can require the functionalities that old kernel does NOT yet have, usually reboot is needed between two runs (otherwise, some processes invoked later can malfunction!).

And in some cases (not always), additional merges of configurations and / or installations of newly introduced components that cannot run unless sanely running new userland is ready need to be done in next run of freebsd-update install, which could need preceding restart.

And in some quite unfortunate edge cases, you'll need manual work to finish upgrades before you start reinstalling pkgs you've installed.
 
Rough instructions:
freebsd-update fetch (maybe need -r across releases)
freebsd-update install (this installs new kernel)
reboot
freebsd-update install (this installs new userland)
freebsd-update install (may clean up things)
pkg upgrade -f (force update of all packages)

freebsd-version -kru tells you:
-k version of installed kernel
-r version of the running kernel
-u version of installed userland

If you do -kru the order is always:
installed kernel version
running kernel version
userland version
 
T-Aoki said:
Assuming you've used freebsd-update(8) to upgrade.
Have you run second (and possbly more) run (as root) of freebsd-update install?

You may want to read Chapter 26.2.3 of the handbook.


Maybe excessive details:

I myself use source upgrades everytime (tried freebsd-update(8) almost only when it was first introduced and next major upgrade), but if I recall correctly, In some cases, it first installs updated kernel, and in next run, install updated userland.

As updated userland can require the functionalities that old kernel does NOT yet have, usually reboot is needed between two runs (otherwise, some processes invoked later can malfunction!).

And in some cases (not always), additional merges of configurations and / or installations of newly introduced components that cannot run unless sanely running new userland is ready need to be done in next run of freebsd-update install, which could need preceding restart.

And in some quite unfortunate edge cases, you'll need manual work to finish upgrades before you start reinstalling pkgs you've installed.
Click to expand...

Thanks for that explanation.

As far as I am aware, I followed the instructions at the link I gave above correctly so I'm not sure why the userland didn't also upgrade to 14.3.

You are the second person I've heard of saying they choose to upgrade their OS version via compiling the new release's source code. The first person mentioned that it preserved their configuration better than doing a binary package upgrade - does this sound about right? Another advantage stated was that you get to specify optimum processor-specific compilation flags to get best performance. I think they may have listed other benefits from this approach but I don't remember the details. Do you know of other advantages of the source code upgrade method?

Back to the issue here - upgrading my userland. One idea I had is to take a snapshot of the ZROOT fs so I can rollback if changes mess things up. Then re-execute the commands to upgrade the userland shown within the link above from the text stating:

"After rebooting, freebsd-update(8) needs to be run again to install the new userland components:"

i.e.

Code: 
# freebsd-update install
(rebuild ports maybe if prompted)
# freebsd-update install
# pkg upgrade -f (force update of all packages)
# shutdown -r now
 
mer said:
Rough instructions:
freebsd-update fetch (maybe need -r across releases)
freebsd-update install (this installs new kernel)
reboot
freebsd-update install (this installs new userland)
freebsd-update install (may clean up things)
pkg upgrade -f (force update of all packages)

freebsd-version -kru tells you:
-k version of installed kernel
-r version of the running kernel
-u version of installed userland

If you do -kru the order is always:
installed kernel version
running kernel version
userland version
Click to expand...

Thanks for this!

One thing I noticed is that you have the additional line - which I will add to the command list to be executed:

Code: 
# pkg upgrade -f (force update of all packages)

Thanks for the tips for the freebsd-version flags - very useful.
 
mer said:
Rough instructions:
freebsd-update fetch (maybe need -r across releases)
freebsd-update install (this installs new kernel)
reboot
freebsd-update install (this installs new userland)
freebsd-update install (may clean up things)
pkg upgrade -f (force update of all packages)

freebsd-version -kru tells you:
-k version of installed kernel
-r version of the running kernel
-u version of installed userland

If you do -kru the order is always:
installed kernel version
running kernel version
userland version
Click to expand...

After doing that userland upgrade, I see this, so it looks like it may have worked:

Code: 
# freebsd-version -kru
14.3-RELEASE
14.3-RELEASE
14.3-RELEASE-p1

I say may have worked because after executing
Code: 
# pkg upgrade -f

it said there were about 838 packages to upgrade and when I proceeded after about 300 packages the scrolling package list text turned into white outline box characters, so I couldn't read what was going on. System text like clock text on the menubar and other text and icons also became corrupted. After rebooting I reissued the 'pkg upgrade -f' command and it again stated there were about 838 packages to upgrade. This is what makes me wonder if the packages really did get upgraded or not.

However, 'freebsd-version -kru' states that userland has been upgraded to 14.3-RELEASE-p1...so...???
 
T-Aoki said:
It's because 14.3-RELEASE-p1 is already there.
Not sure why it's NOT 14.3-RELEASE-p2. Maybe next usual freebsd-update run would do.
Click to expand...

Yes that's right.

My point was that as the package update produced corruption in the form of screen/text corruption, and it stated twice there were 838 packages to upgrade, it wasn't certain to me that the package upgrade had completed successfully, if you see what I mean?

Yes, not sure why not 14.3-RELEASE-p2.

I understand binary packages, these can be manipulated via the pkg command etc, ports are source code that can be made into a binary package and installed, but what is the differentiation between 'pkg update/upgrade' and 'freebsd-update'?
 
Err...something is very wrong with my system. There are 'running' XFCE apps that appear on the XFCE menubar and I can't select them or kill them. They are the applications I couldn't kill when I shut the system down last. Even 'ps -el' as root doesn't show any running apps so I can't kill them that way - maybe kill the session as a last resort?

This all started after the update/upgrade I did, so if I can't kill the session and the running apps I will rollback to the previous snapshot.
 
froggit9000 said:
Err...something is very wrong with my system. There are 'running' XFCE apps that appear on the XFCE menubar and I can't select them or kill them. They are the applications I couldn't kill when I shut the system down last. Even 'ps -el' as root doesn't show any running apps so I can't kill them that way - maybe kill the session as a last resort?

This all started after the update/upgrade I did, so if I can't kill the session and the running apps I will rollback to the previous snapshot.
Click to expand...
You gotta run ps -flea ;)
 
froggit9000 said:
My point was that as the package update produced corruption in the form of screen/text corruption, and it stated twice there were 838 packages to upgrade, it wasn't certain to me that the package upgrade had completed successfully, if you see what I mean?
Click to expand...
Not sure what's happening for you (as it depends which branch [latest or quarterly] of pkg you're on, what pkgs you've installed, how often you're upgrading pkgs,...), but basically, non-kmod ports are built against oldest supported minor version of each major versions (i.e., for 14.x, currently built against 14.2), thus, all but except kmod ones are NOT needed to be upgraded if your pkgs are already up-to-date.

On the other hand, kmod (kernel module) ports are needed to be reinstalled, especially *-drm-*-kmod* ones that requres LinuxKPI to run.

Starting from 14.2 (at the moment, pkgs were built against 14.1), separate repo for kmods are prepared (initially for testing) and now officially available as FreeBSD-ports-kmods.

Unfortunately, pkg doesn't seem to work fine when multiple repo are used at the same time (looks confused when I last tried on several minor versions back).

If this is the issue, you can run pkg like below.
  1. pkg upgrade -r FreeBSD-ports -n
  2. pkg upgrade -r FreeBSD-ports
  3. pkg upgrade -r FreeBSD-ports-kmods -n
  4. pkg upgrade -r FreeBSD-ports-kmods
If 1. shows nothing to upgrade, 2. can be skipped.
Also, if 3. shows nothing to upgrade, 4. can be skipped.
 
T-Aoki said:
Not sure what's happening for you (as it depends which branch [latest or quarterly] of pkg you're on, what pkgs you've installed, how often you're upgrading pkgs,...), but basically, non-kmod ports are built against oldest supported minor version of each major versions (i.e., for 14.x, currently built against 14.2), thus, all but except kmod ones are NOT needed to be upgraded if your pkgs are already up-to-date.

On the other hand, kmod (kernel module) ports are needed to be reinstalled, especially *-drm-*-kmod* ones that requres LinuxKPI to run.

Starting from 14.2 (at the moment, pkgs were built against 14.1), separate repo for kmods are prepared (initially for testing) and now officially available as FreeBSD-ports-kmods.

Unfortunately, pkg doesn't seem to work fine when multiple repo are used at the same time (looks confused when I last tried on several minor versions back).

If this is the issue, you can run pkg like below.
  1. pkg upgrade -r FreeBSD-ports -n
  2. pkg upgrade -r FreeBSD-ports
  3. pkg upgrade -r FreeBSD-ports-kmods -n
  4. pkg upgrade -r FreeBSD-ports-kmods
If 1. shows nothing to upgrade, 2. can be skipped.
Also, if 3. shows nothing to upgrade, 4. can be skipped.
Click to expand...

After these upgrades my system seems unstable under XFCE, so I'm not sure what has happened.

If things went wrong I thought I would do a rollback, as I took a recursive snapshot of all filesystems within zroot, but instead perhaps I should have created a new boot environment as it seems things are still not working correctly despite doing a rollback of all the filesystems.

So whilst things are still not too fubar'd to be able to do things, I think I will print out some of these threads so after reinstalling 14.3-RELEASE I can get a reliable ethernet driver (realtek-re-kmod198 - see if I can install simply by 'pkg install realtek-re-kmod198' instead of using the ports method). I have persistent storage on another attached zpool where I keep all my files and notes so should be able to refer to this when reinstalling stuff.

Maybe a full reinstall is not necessary and a more knowledgeable FreeBSD user might be able to restore my system to health again, but I only know the full install method for now so that's what I will try.

It's a pity as everything looks like it is updated correctly now if you look at the versions displayed:
Code: 
# freebsd-version -kru
14.3-RELEASE-p2
14.3-RELEASE-p2
14.3-RELEASE-p2
 
Have you read /usr/ports/UPDATING and followed the instruction if any of pkg you have in your system is listed?
UPDATING for quarterly (2025Q3)
UPDATING for latest (aka main)

You can use pkg updating (see pkg-updating(8) or pkg help updating for details) instead.

Anyone using official pkg rarely affected (listed but shown something like "pkg users doesn't need special care") but NOT always. Anyone using old-school method are affected much more often.

And in some cases, pkg can need multiple run to finish (simply this case without additional cares, UPDATING would unlikely to be updated for it).
 
T-Aoki said:
Have you read /usr/ports/UPDATING and followed the instruction if any of pkg you have in your system is listed?
UPDATING for quarterly (2025Q3)
UPDATING for latest (aka main)

You can use pkg updating (see pkg-updating(8) or pkg help updating for details) instead.

Anyone using official pkg rarely affected (listed but shown something like "pkg users doesn't need special care") but NOT always. Anyone using old-school method are affected much more often.

And in some cases, pkg can need multiple run to finish (simply this case without additional cares, UPDATING would unlikely to be updated for it).
Click to expand...

Do those UPDATING links work for a 14.3-RELEASE version too or just 'quarterly or main' versions?

Anyway, good news - when I installed a new package, the XFCE odd behaviour (thunar window not displaying and unresponsive when run) seems to have gone away, so instead of abandoning this install and doing a reinstall of 14.3-RELEASE, I will continue with it.

Something with last night's upgrade actions seems to have upset XFCE but that seems to have gone away now, so...
When the forced package upgrade caused icons and text on the desktop to get corrupted I knew something strange had happened :(

I will now move on to trying to get the AMDGPU Raphael video driver installed as someone has pointed out a thread where it is said to be available and working now :D

Once I get the video driver installed and working, I will be interested in taking a deep dive into understanding how to upgrade my system using source compilation, so I may come back to you to pick your brains :)
 
froggit9000 said:
Do those UPDATING links work for a 14.3-RELEASE version too or just 'quarterly or main' versions?
Click to expand...
Not specific with OS version, as pkgs for each OS major version (13, 14, ... and only FreeBSD-kmods repo cares for minor versions) are built using same ports tree. So each UPDATING is common for all OS versions.
 
froggit9000 said:
I will now move on to trying to get the AMDGPU Raphael video driver installed as someone has pointed out a thread where it is said to be available and working now
Click to expand...
Just to let you know, Raphael graphics now work fine without the hacks described at the beginning of the thread. Make sure you read all the way to the end of the thread.
 
astyle said:
Just to let you know, Raphael graphics now work fine without the hacks described at the beginning of the thread. Make sure you read all the way to the end of the thread.
Click to expand...

Thanks for letting me know. 👍

This last comment is the one I think:
astyle

Post in thread 'AMD Ryzen 9 7940HS (Radeon 780M) - Graphics now working!'

Well, 6 months later, it looks like the FreeBSD driver did get fixed. Right now, I grabbed a fresh copy of the ports - and it worked without needing to resort to the hack/workaround described in this thread.

I'm still glad this info was available back then, and still grateful for this thread's existence!

But now, if someone has a Ryzen 7000 series with Raphael iGPU, they can rest easy knowing that merely compiling graphics/drm-kmod (using a fresh copy of the ports tree) will produce a workable amdgpu driver.
  • Thanks

You said a fresh update of the ports is necessary to start with?
 
froggit9000 said:
Thanks for letting me know. 👍

This last comment is the one I think:
astyle

Post in thread 'AMD Ryzen 9 7940HS (Radeon 780M) - Graphics now working!'

Well, 6 months later, it looks like the FreeBSD driver did get fixed. Right now, I grabbed a fresh copy of the ports - and it worked without needing to resort to the hack/workaround described in this thread.

I'm still glad this info was available back then, and still grateful for this thread's existence!

But now, if someone has a Ryzen 7000 series with Raphael iGPU, they can rest easy knowing that merely compiling graphics/drm-kmod (using a fresh copy of the ports tree) will produce a workable amdgpu driver.
  • Thanks

You said a fresh update of the ports is necessary to start with?
Click to expand...
Well, 'fresh' as in 'since the date of this post'. If your ports tarball is from before Jun 20, 2025, then yeah, follow the hacks. Anything newer than that works out of the box.

There are pre-compiled packages available via pkg, and they should work - if they match the kernel version. Making sure of THAT is a lot of work, though, so I prefer to compile the stuff from
/usr/ports...
 
astyle said:
Well, 'fresh' as in 'since the date of this post'. If your ports tarball is from before Jun 20, 2025, then yeah, follow the hacks. Anything newer than that works out of the box.

There are pre-compiled packages available via pkg, and they should work - if they match the kernel version. Making sure of THAT is a lot of work, though, so I prefer to compile the stuff from
/usr/ports...
Click to expand...

I think I will also try the ports way.
Just reading the handbook [4.5.4 Upgrading Ports] section.
 
astyle said:
Well, 'fresh' as in 'since the date of this post'. If your ports tarball is from before Jun 20, 2025, then yeah, follow the hacks. Anything newer than that works out of the box.

There are pre-compiled packages available via pkg, and they should work - if they match the kernel version. Making sure of THAT is a lot of work, though, so I prefer to compile the stuff from
/usr/ports...
Click to expand...

To be honest I'm a bit lost on how to update the ports (Ports Collection?).
Do I choose the 'Git method'?
Or something else?
 
To simply make your ports / src tree up to date, maybe net/gitup would help.

But to make mixing up official pkg and ports "safest", matching the top commit (by checking out specific commit hash) with the newest pkg you've installed / upgraded.

For this purpose, devel/git would better fit, with the cost of complexities.

And note that, if you want to build kernel module (kmod) ports, you need the source tree (/usr/src) which 100% matches your running (or to be rebooted to run) kernel.

In your case (14.3-p1, right?), it would be commit 2ea99b8ed14208286ec3c8d6ccc997537c13d195.

If you've already updated to 14.3-p2, it would be commit 5982521fe3dd3f1627bbe29ee8c3b190a24e3963.
 
Also when I tried doing a 'make install clean' within a port directory I got an error message complaining about Perl version 5.40 being incompatible - can't remember exact message but then it terminated without compiling the port.

When I did a 'portmaster -L' to list ports I found a reference to a Perl version:

Code: 
# portmaster -L
...
===>>> perl5-5.40.3_2

    ===>>> No /usr/ports/lang/perl5.40 exists, and no information
    ===>>> about lang/perl5.40 can be found in /usr/ports/MOVED

If I type:

Code: 
# perl -version

This is perl 5, version 40, subversion 3 (v5.40.3) built for amd64-freebsd-thread-multi
(with 13 registered patches, see perl -V for more detail)

So I don't understand the perl incompatibility message displayed in the previous post.
 
T-Aoki said:
To simply make your ports / src tree up to date, maybe net/gitup would help.

But to make mixing up official pkg and ports "safest", matching the top commit (by checking out specific commit hash) with the newest pkg you've installed / upgraded.

For this purpose, devel/git would better fit, with the cost of complexities.

And note that, if you want to build kernel module (kmod) ports, you need the source tree (/usr/src) which 100% matches your running (or to be rebooted to run) kernel.

In your case (14.3-p1, right?), it would be commit 2ea99b8ed14208286ec3c8d6ccc997537c13d195.

If you've already updated to 14.3-p2, it would be commit 5982521fe3dd3f1627bbe29ee8c3b190a24e3963.
Click to expand...

When I try to install the devel/git I see this:

Code: 
root@freebsd:/usr/ports/devel/git # make install clean
===>  git-2.45.1 Invalid perl5 version 5.40.
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/git
 
You must log in or register to reply here.
Back
Top