Does my 14.3 install look correct?

T-Aoki · Sep 1, 2025

By default, *-Release uses quarterly (currently 2025Q3).
And if you've extracted ports from tarball in the installation media,
it may be of quarterly at the moment the release is done.

If you need cutting edge features rather than stabilities (i.e., quarterly doesn't yet have new enough GPU driver you need), you need to switch to latest.
In this case, you need to switch the official pkg repo to latest and forcibly upgrade everything installed via pkg to be sure.

Note that the existing ports tree extracted from release tarball need to be removed or moved to somewhere else to use gitup or git.

T-Aoki · Sep 1, 2025

If you want to switch to latest, you'll need to upgrade perl first, following the instruction in UPDATING.

Or overriding perl version by adding
DEFAULT_VERSIONS+= perl5=5.40
in your /etc/make.conf to delay upgrading of perl.

astyle · Sep 1, 2025

froggit9000 said:
I'm not sure how to check if I'm on the latest/main branch of ports/pkgs.

run this: cat /etc/pkg/FreeBSD.conf

The output will tell you if you're on latest or quarterly - for packages.

For ports, you can just fetch a .zip file from Github (I have the exact command somewhere on my profile comments), and unzip it into /usr/ports, and you'll have the freshest copy of ports then that you can use as per instructions in the Handbook. This is just more reliable than pkg these days.

froggit9000 · Sep 1, 2025

astyle said:
run this: cat /etc/pkg/FreeBSD.conf

The output will tell you if you're on latest or quarterly - for packages.

For ports, you can just fetch a .zip file from Github (I have the exact command somewhere on my profile comments), and unzip it into /usr/ports, and you'll have the freshest copy of ports then that you can use as per instructions in the Handbook. This is just more reliable than pkg these days.

It looks like it is set to quarterly:

Code:

root@freebsd:/usr/ports/graphics/drm-kmod # cat /etc/pkg/FreeBSD.conf
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#

FreeBSD: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_quarterly_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

Do you know where to get the zip file from?

Charlie_ · Sep 1, 2025

froggit9000 said:
It looks like it is set to quarterly:

This is natural, as the file is not meant to be edited.

Code:

root@freebsd:/usr/ports/graphics/drm-kmod # cat /etc/pkg/FreeBSD.conf
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:

froggit9000 · Sep 1, 2025

Charlie_ said:
This is natural, as the file is not meant to be edited.

Code:

root@freebsd:/usr/ports/graphics/drm-kmod # cat /etc/pkg/FreeBSD.conf # # To disable this repository, instead of modifying or removing this file, # create a /usr/local/etc/pkg/repos/FreeBSD.conf file:

Yes exactly, we were just checking whether the ports were from main or quarterly branch.

Charlie_ · Sep 1, 2025

froggit9000 said:
we were just checking whether the ports were from main or quarterly branch.

You should also check /usr/local/etc/pkg/repos/FreeBSD.conf.

froggit9000 · Sep 7, 2025

Charlie_ said:
You should also check /usr/local/etc/pkg/repos/FreeBSD.conf.

Thanks Charlie, I had a look but there is no such file on my system.

By default now, perhaps starting from the 14.3 release it seems that references to both the FreeBSD and FreeBSD-kmods repos are made within /etc/pkg/FreeBSD.conf now:

Code:

root@freebsd:/etc/pkg # cat FreeBSD.conf
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#

FreeBSD: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_quarterly_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
root@freebsd:/etc/pkg #

I think I need both repos as I will need to compile the kmod for the video driver, so this default looks OK to me.

froggit9000 · Sep 7, 2025

I still haven't got this working yet due to my general cluelessness with FreeBSD, so I will recap my understanding here and see if someone can help me out with the next steps required.

Version of installed software - all at 14.3-RELEASE-p2 :

Code:

root@freebsd:/etc/pkg # freebsd-version -kru
14.3-RELEASE-p2
14.3-RELEASE-p2
14.3-RELEASE-p2
root@freebsd:/etc/pkg #

1. As I will need to compile a kernel module for the AMDGPU-Raphael video driver, I need to update the /usr/src directory contents.
How do I achieve this?

2. As I will be building and installing the video driver code from ports I will need to update the /usr/ports directory.
How do I achieve this?

I currently have a problem with building some ports as the system complains about my installed Perl version:

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
root@freebsd:/usr/ports/devel/git #

Code:

root@freebsd:/usr/ports/devel/git/files # 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)

Copyright 1987-2025, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at https://www.perl.org/, the Perl Home Page.

root@freebsd:/usr/ports/devel/git/files #

3. I don't know which version of Perl the ports require, so help is needed here too.

astyle · Sep 7, 2025

froggit9000 said:
Thanks Charlie, I had a look but there is no such file on my system.

By default now, perhaps starting from the 14.3 release it seems that references to both the FreeBSD and FreeBSD-kmods repos are made within /etc/pkg/FreeBSD.conf now:

Code:

root@freebsd:/etc/pkg # cat FreeBSD.conf # # To disable this repository, instead of modifying or removing this file, # create a /usr/local/etc/pkg/repos/FreeBSD.conf file: # # mkdir -p /usr/local/etc/pkg/repos # echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf # FreeBSD: { url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } FreeBSD-kmods: { url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_quarterly_${VERSION_MINOR}", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } root@freebsd:/etc/pkg #

I think I need both repos as I will need to compile the kmod for the video driver, so this default looks OK to me.

The thing is, /etc/pkg/FreeBSD.conf is meant to be a system file, not to be modified. Even that specific file clearly says that if you want to change repos:

Code:

# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#

froggit9000 · Sep 7, 2025

astyle said:
The thing is, /etc/pkg/FreeBSD.conf is meant to be a system file, not to be modified. Even that specific file clearly says that if you want to change repos:

Yes exactly, and as this default contents suits my requirements, there is no need to override it by creating a new file at /usr/local/etc/pkg/repos/FreeBSD.conf. At least that is how I understand it.

astyle · Sep 7, 2025

froggit9000 said:
1. As I will need to compile a kernel module for the AMDGPU-Raphael video driver, I need to update the /usr/src directory contents.
How do I achieve this?

No need to update /usr/src. When you install FreeBSD, there should be an option to install src.txz, as mentioned in the Handbook:

Selecting src is important to remember. This will make compiling amdgpu driver possible.

As for the rest: This is why I compile from scratch, and don't mix ports/packages. Yeah, that will take awhile, but that's what it takes to avoid errors like that.

froggit9000 · Sep 7, 2025

Here is my /usr/src/ directory:

Code:

root@freebsd:/usr/ports/games/doom # ls -l /usr/src
total 598
-rw-r--r--    1 root wheel    148 May 31  2024 .arcconfig
-rw-r--r--    1 root wheel    448 May 31  2024 .arclint
drwxr-xr-x    2 root wheel      3 May 31  2024 .cirrus-ci
-rw-r--r--    1 root wheel   6611 Aug 31 02:24 .cirrus.yml
-rw-r--r--    1 root wheel   4925 Aug 31 02:24 .clang-format
-rw-r--r--    1 root wheel   1143 Aug 31 02:24 .git-blame-ignore-revs
-rw-r--r--    1 root wheel    205 May 31  2024 .gitattributes
drwxr-xr-x    4 root wheel      5 Aug 31 02:24 .github
-rw-r--r--    1 root wheel    297 May 31  2024 .gitignore
-rw-r--r--    1 root wheel   7903 May 31  2024 CONTRIBUTING.md
-rw-r--r--    1 root wheel   6109 May 31  2024 COPYRIGHT
-rw-r--r--    1 root wheel    490 May 31  2024 LOCKS
-rw-r--r--    1 root wheel   7175 May 31  2024 MAINTAINERS
-rw-r--r--    1 root wheel  31813 Aug 31 02:24 Makefile
-rw-r--r--    1 root wheel 131866 Aug 31 02:24 Makefile.inc1
-rw-r--r--    1 root wheel   3621 May 31  2024 Makefile.libcompat
-rw-r--r--    1 root wheel   1939 May 31  2024 Makefile.sys.inc
-rw-r--r--    1 root wheel 961828 Aug 31 02:24 ObsoleteFiles.inc
-rw-r--r--    1 root wheel   2837 May 31  2024 README.md
-rw-r--r--    1 root wheel  16062 Aug 31 02:24 RELNOTES
-rw-r--r--    1 root wheel  89028 Aug 31 02:24 UPDATING
drwxr-xr-x   44 root wheel     46 May 31  2024 bin
drwxr-xr-x   11 root wheel     13 May 31  2024 cddl
drwxr-xr-x   90 root wheel     90 Jul 20 11:40 contrib
drwxr-xr-x    6 root wheel      7 Jul 20 11:38 crypto
drwxr-xr-x    8 root wheel     13 Aug 31 02:25 etc
drwxr-xr-x    5 root wheel      9 May 31  2024 gnu
drwxr-xr-x   10 root wheel    113 Aug 31 02:25 include
drwxr-xr-x    8 root wheel     11 May 31  2024 kerberos5
drwxr-xr-x  147 root wheel    149 Aug 31 02:25 lib
drwxr-xr-x   39 root wheel     41 Aug 31 02:25 libexec
drwxr-xr-x   12 root wheel     26 Aug 31 02:25 release
drwxr-xr-x    4 root wheel      6 May 31  2024 rescue
drwxr-xr-x   86 root wheel     92 Aug 31 02:25 sbin
drwxr-xr-x    8 root wheel     11 Aug 31 02:25 secure
drwxr-xr-x   31 root wheel     33 May 31  2024 share
drwxr-xr-x   26 root wheel     35 Aug 31 02:25 stand
drwxr-xr-x   53 root wheel     55 May 31  2024 sys
drwxr-xr-x    3 root wheel      6 May 31  2024 targets
drwxr-xr-x    8 root wheel     15 May 31  2024 tests
drwxr-xr-x   19 root wheel     23 May 31  2024 tools
drwxr-xr-x  280 root wheel    286 Aug 31 02:26 usr.bin
drwxr-xr-x  227 root wheel    235 May 31  2024 usr.sbin
root@freebsd:/usr/ports/games/doom #

Does this mean I'm lucky in that when I installed FreeBSD I selected to install the 'system source tree'?

On your second point of compiling from scratch, I can see that would avoid conflicts between packages and ports. I may do a reinstall at some point once I get the video driver working and learn a bit more about what I'm doing as I don't have much on the system at the moment.

astyle · Sep 7, 2025

froggit9000 said:
Does this mean I'm lucky in that when I installed FreeBSD I selected to install the 'system source tree'?

I personally would recommend always selecting the system source tree when you install FreeBSD. That way, you wouldn't need to be lucky. But at this point, yeah, just go ahead and compile in
/usr/ports/graphics/drm-kmod/ ...

I personally would recommend make && make install first, and after a successful completion, make clean.

froggit9000 · Sep 7, 2025

astyle said:
I personally would recommend always selecting the system source tree when you install FreeBSD. That way, you wouldn't need to be lucky. But at this point, yeah, just go ahead and compile in
/usr/ports/graphics/drm-kmod/ ...

I personally would recommend make && make install first, and after a successful completion, make clean.

Yes, if I had hindsight I would have known that hehe

Anyway, lucky I had selected src on install this time and so have a /usr/src tree installed.

Before I compile graphics/drm-kmod let me see if it needs updating.
Should I presume if files exist at /usr/ports then I already have the latest or compatible version of everything? (freebsd-version -kru shows 14.3-RELEASE-p2 for all)
I think I selected ports and src checkboxes on installation...but the original installation was of version 14.1-RELEASE before I did the update to 14.3-RELEASE, and now updated to 14.3-RELEASE-p2.

astyle · Sep 7, 2025

froggit9000 said:
Yes, if I had hindsight I would have known that hehe
Anyway, lucky I had selected src on install this time and so have a /usr/src tree installed.

Before I compile graphics/drm-kmod let me see if it needs updating.
Should I presume if files exist at /usr/ports then I already have the latest or compatible version of everything? (freebsd-version -kru shows 14.3-RELEASE-p2 for all)
I think I selected ports and src checkboxes on installation...but the original installation was of version 14.1-RELEASE before I did the update to 14.3-RELEASE, and now updated to 14.3-RELEASE-p2.

To be honest, I dunno what to do in case of an upgrade from one FreeBSD version to next that was performed using freebsd-update... I always installed from scratch, because it's a pain to pay attention to specific details of software that gets affected by that upgrade. And I read horror stories here on the Forums about how some forgotten-about detail derailed the entire effort.

freebsd-update works best when you don't have any ports/packages installed. Once you throw graphics drivers into the mix, that becomes just too messy, because graphics drivers do depend on being matched to the correct kernel version. pkg-upgrade is frankly a mess, as well, for many reasons.

I have 14.2-RELEASE right now, I installed it shortly after it was released, KDE works fine. Upgrading is too much of a mess, so I'm gonna wait for 15-RELEASE, and do a fresh install of everything. A couple days of compiling on a Ryzen 7 5625, and I'll be back into KDE, with everything updated.

froggit9000 · Sep 8, 2025

astyle said:
To be honest, I dunno what to do in case of an upgrade from one FreeBSD version to next that was performed using freebsd-update... I always installed from scratch, because it's a pain to pay attention to specific details of software that gets affected by that upgrade. And I read horror stories here on the Forums about how some forgotten-about detail derailed the entire effort.

freebsd-update works best when you don't have any ports/packages installed. Once you throw graphics drivers into the mix, that becomes just too messy, because graphics drivers do depend on being matched to the correct kernel version. pkg-upgrade is frankly a mess, as well, for many reasons.

I have 14.2-RELEASE right now, I installed it shortly after it was released, KDE works fine. Upgrading is too much of a mess, so I'm gonna wait for 15-RELEASE, and do a fresh install of everything. A couple days of compiling on a Ryzen 7 5625, and I'll be back into KDE, with everything updated.

> To be honest, I dunno what to do in case of an upgrade from one FreeBSD version to next that was performed using freebsd-update...
> I always installed from scratch, because it's a pain to pay attention to specific details of software that gets affected by that upgrade.
> And I read horror stories here on the Forums about how some forgotten-about detail derailed the entire effort.

Oh well, looks like I'll have to give it a try and see what happens. If I create a new ZFS boot environment before doing a 'dangerous'
update then I suppose I can roll back?
But these problems you refer to are caused by the mixing of packages and ports? Or something else?

> freebsd-update works best when you don't have any ports/packages installed. Once you throw graphics drivers into the mix,
> that becomes just too messy, because graphics drivers do depend on being matched to the correct kernel version.
> pkg-upgrade is frankly a mess, as well, for many reasons.

What is the root cause of these problems? Package system doesn't handle well the combination of packages and ports?

> I have 14.2-RELEASE right now, I installed it shortly after it was released, KDE works fine. Upgrading is too much of a mess,
> so I'm gonna wait for 15-RELEASE, and do a fresh install of everything. A couple days of compiling on a Ryzen 7 5625, and I'll
> be back into KDE, with everything updated.

Is there no way to keep your existing system when you do an upgrade?

astyle · Sep 8, 2025

froggit9000 said:
Oh well, looks like I'll have to give it a try and see what happens. If I create a new ZFS boot environment before doing a 'dangerous'
update then I suppose I can roll back?

yeah, if you use snapshots. Boot environments are also great, they are basically a special use case of snapshots. I'd suggest reading the manpages beforehand, and map out how you're gonna do that.

froggit9000 said:
What is the root cause of these problems? Package system doesn't handle well the combination of packages and ports?

Nope. Combining ports and packages is a bad idea if the versions are too far apart. Besides, the package repos operate on a schedule. "Latest" repos may not have everything you need. "Quarterly" only gets built on a schedule, and that's the schedule you will be beholden to. Not only that, you have to do a wholesale upgrade of ALL the packages you have installed, on that schedule. If you try to do a subset, you'll run into dependency hell. Oh, and precompiled package repos/infrastructure have gotten unreliable recently. It's easier to compile from ports. You can still run make package on your local machine, and have a lot of pkg commands work fine, as long as you don't try to query remote repos. There are threads with horror stories on these Forums about that.

froggit9000 said:
Is there no way to keep your existing system when you do an upgrade?

Not that I know of. Have good backups handy.

GPU drivers throw a real wrench into the whole upgrade idea, because they are tied to the kernel version. If you upgrade from 14.1-RELEASE to 14.3-RELEASE, you really gotta pay attention to what drm-kmod pulls in as a dependency. I know that drm-kmod packages did get built for 14.3-RELEASE, and should be available in Quarterly repos, but if you don't pay attention to the schedule, you can get stuck without GPU drivers until the date for next quarter arrives.

And all of that is just the start. NVidia GPU drivers are complicated on FreeBSD. I figured my stuff out on AMD GPUs, though, because that's the metal I own.

froggit9000 · Sep 19, 2025

I didn't manage to get the /usr/src and /usr/ports trees updated - at least the port version looked old from 2022 so I decided to try just installing the drm-kmod package and managed to get a recent one which should do:

Code:

# pkg info drm-kmod
drm-kmod-20250428
Name           : drm-kmod
Version        : 20250428
Installed on   : Thu Sep 18 22:56:38 2025 BST
Origin         : graphics/drm-kmod
Architecture   : FreeBSD:14:*
Prefix         : /usr/local
Categories     : graphics
Licenses       : NA
Maintainer     : x11@FreeBSD.org
WWW            : https://github.com/freebsd/drm-kmod
Comment        : Metaport of DRM modules for the linuxkpi-based KMS components
Annotations    :
    build_timestamp: 2025-08-10T13:42:05+0000
    built_by       : poudriere-git-3.4.3
    port_checkout_unclean: no
    port_git_hash  : d7951ee86
    ports_top_checkout_unclean: no
    ports_top_git_hash: ae4b9c5a1
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 243B
Description    :
amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components on
amd64, i915 and radeonkms DRM modules from the former base DRM component on
other architectures.
Metaport for different versions of Linux DRM based on the FreeBSD version
in use. This port encompasses the recommendations of the FreeBSDDesktop team
of DRM versions for FreeBSD versions based on the last update to the LinuxKPI
in that code base. In general, the most recent supported stable DRM for a give
FreeBSD version will be installed. CURRENT receives the most recent development
DRM.
This port does not however hinder the expert user to make other decisions and
continue to install DRM ports directly.

I then followed the steps in the following post:
https://forums.freebsd.org/threads/...aphael-driver-available-yet.99053/post-715222

Code:

# pkg install drm-kmod
# pkg install xf86-video-amdgpu
# sysrc kld_list+=amdgpu (I edited the /etc/rc.conf file directly instead)

Contents of /etc/rc.conf:

Code:

...
kld_list="amdgpu"
...

Contents of file /usr/local/etc/X11/xorg.conf.d/10-monitor.conf:

Code:

root@freebsd:/usr/local/etc/X11/xorg.conf.d # cat 10-monitor.conf
Section "Screen"
  Identifier "Screen0"
  Device     "Card0"
  SubSection "Display"
    Modes    "2560x1440"
  EndSubSection
EndSection

Contents of file /usr/local/etc/X11/xorg.conf.d/20-drivers.conf:

Code:

root@freebsd:/usr/local/etc/X11/xorg.conf.d # cat 20-drivers.conf
Section "Device"
  Identifier "Card0"
  Driver     "amdgpu"
  BusID      "pci0:18:0:0"
  Option     "TearFree" "true"
  Option     "SWCursor" "true"
EndSection

When I rebooted the machine I saw a black screen with a solid white cursor
at the top left of the screen so it hasn't worked for some reason.

I tried renaming the file to 20-amdgpu.conf but that didn't work.

I don't know if the 'BusID' line is required - I copied it from the previous
file that I used when using the 'scfb' driver. It didn't work without it either.

The /usr/local/etc/X11/xorg.conf.d/10-monitor.conf file was
a remnant from when I used the 'scfb' driver also.

Also I noticed the gpu firmware package might be old - see 'gpu-firmware-kmod-20241114,1':

Code:

# pkg info -a | grep drm-kmod
drm-kmod-20250428              Metaport of DRM modules for the linuxkpi-based KMS components
gpu-firmware-kmod-20241114,1   Firmware modules for the drm-kmod drivers

Finally, I have seen on another thread the following - do I need to do this explicitly to load the amdgpu driver kernel module?

Code:

# kldload amdgpu

Does anyone know what I might be doing wrong?

astyle · Sep 19, 2025

froggit9000 said:
I didn't manage to get the /usr/src and /usr/ports trees updated - at least the port version looked old from 2022 so I decided to try just installing the drm-kmod package and managed to get a recent one which should do:

Code:

# pkg info drm-kmod drm-kmod-20250428 Name : drm-kmod Version : 20250428 Installed on : Thu Sep 18 22:56:38 2025 BST Origin : graphics/drm-kmod Architecture : FreeBSD:14:* Prefix : /usr/local Categories : graphics Licenses : NA Maintainer : x11@FreeBSD.org WWW : https://github.com/freebsd/drm-kmod Comment : Metaport of DRM modules for the linuxkpi-based KMS components Annotations : build_timestamp: 2025-08-10T13:42:05+0000 built_by : poudriere-git-3.4.3 port_checkout_unclean: no port_git_hash : d7951ee86 ports_top_checkout_unclean: no ports_top_git_hash: ae4b9c5a1 repo_type : binary repository : FreeBSD Flat size : 243B Description : amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components on amd64, i915 and radeonkms DRM modules from the former base DRM component on other architectures. Metaport for different versions of Linux DRM based on the FreeBSD version in use. This port encompasses the recommendations of the FreeBSDDesktop team of DRM versions for FreeBSD versions based on the last update to the LinuxKPI in that code base. In general, the most recent supported stable DRM for a give FreeBSD version will be installed. CURRENT receives the most recent development DRM. This port does not however hinder the expert user to make other decisions and continue to install DRM ports directly.

I then followed the steps in the following post:
https://forums.freebsd.org/threads/...aphael-driver-available-yet.99053/post-715222

Code:

# pkg install drm-kmod # pkg install xf86-video-amdgpu # sysrc kld_list+=amdgpu (I edited the /etc/rc.conf file directly instead)

Contents of /etc/rc.conf:

Code:

... kld_list="amdgpu" ...

Contents of file /usr/local/etc/X11/xorg.conf.d/10-monitor.conf:

Code:

root@freebsd:/usr/local/etc/X11/xorg.conf.d # cat 10-monitor.conf Section "Screen" Identifier "Screen0" Device "Card0" SubSection "Display" Modes "2560x1440" EndSubSection EndSection

Contents of file /usr/local/etc/X11/xorg.conf.d/20-drivers.conf:

Code:

root@freebsd:/usr/local/etc/X11/xorg.conf.d # cat 20-drivers.conf Section "Device" Identifier "Card0" Driver "amdgpu" BusID "pci0:18:0:0" Option "TearFree" "true" Option "SWCursor" "true" EndSection

When I rebooted the machine I saw a black screen with a solid white cursor
at the top left of the screen so it hasn't worked for some reason.

I tried renaming the file to 20-amdgpu.conf but that didn't work.

I don't know if the 'BusID' line is required - I copied it from the previous
file that I used when using the 'scfb' driver. It didn't work without it either.

The /usr/local/etc/X11/xorg.conf.d/10-monitor.conf file was
a remnant from when I used the 'scfb' driver also.

Also I noticed the gpu firmware package might be old - see 'gpu-firmware-kmod-20241114,1':

Code:

# pkg info -a | grep drm-kmod drm-kmod-20250428 Metaport of DRM modules for the linuxkpi-based KMS components gpu-firmware-kmod-20241114,1 Firmware modules for the drm-kmod drivers

Does anyone know what I might be doing wrong?

I think a bit more info is needed.

Namely: What's the exact CPU that you have? Please post the output of dmesg | grep CPU: . That bit of info is needed to start the research into what needs to be corrected.

Also, I do suggest a fresh reinstall, and to install the src stuff as I indicated with a screenshot earlier in this thread. Without that, you'll get nowhere with the GPU drivers.

Then grab the latest copy of the ports tarball using this command: fetch https://github.com/freebsd/freebsd-ports/archive/refs/heads/main.zip. The FreeBSD base actually can handle the unzipping of that stuff into /usr/ports via the unzip command.f

Keep in mind, order of steps matters here.

And then compile your ass off.

froggit9000 · Sep 21, 2025

astyle said:
I think a bit more info is needed.

Namely: What's the exact CPU that you have? Please post the output of dmesg | grep CPU:. That bit of info is needed to start the research into what needs to be corrected.

Here is my PC's CPU info: (12 core / 24-thread CPU):

Code:

# dmesg | grep CPU:
CPU: AMD Ryzen 9 7900 12-Core Processor              (3700.08-MHz K8-class CPU)

astyle said:
Also, I do suggest a fresh reinstall, and to install the src stuff as I indicated with a screenshot earlier in this thread. Without that, you'll get nowhere with the GPU drivers.

Ah, I was trying to avoid having to do that!
One idea I have is to buy another SSD, as I would like to setup a mirrored zroot boot pool. So what I could do is leave this installation for now and once I have the new SSD just install again onto that.
However, can you specify a mirror if only one disk is available, and later attach another disk?
If not, then I will need to buy two more SSDs and remove this current boot drive and keep it as a spare.
Any ideas here?

astyle said:
Then grab the latest copy of the ports tarball using this command: fetch https://github.com/freebsd/freebsd-ports/archive/refs/heads/main.zip. The FreeBSD base actually can handle the unzipping of that stuff into /usr/ports via the unzip command.f

Keep in mind, order of steps matters here.

And then compile your ass off.

Noted!

Again, this has highlighted the fact that I don't have the necessary knowledge at the moment to enable me to maintain my FreeBSD system in a way that does not involve doing complete re-installation of everything. From what you seem to have said in previous posts, I must not mix binary packages and ports? Instead, I should compile all ports and sources into packages, is that right? Could you recommend a good resource that explains clearly how to maintain a system using source code compilation only?

Thanks for all your help with this - much appreciated.

Once I understand what I'm doing with FreeBSD, I think I will replace my Debian Linux daily driver with FreeBSD, as I don't like using DKMS to get ZFS working with Linux. I like that FreeBSD treats ZFS as a 'first class citizen' as I value my data.

astyle · Sep 21, 2025

froggit9000 said:
Again, this has highlighted the fact that I don't have the necessary knowledge at the moment to enable me to maintain my FreeBSD system in a way that does not involve doing complete re-installation of everything. From what you seem to have said in previous posts, I must not mix binary packages and ports? Instead, I should compile all ports and sources into packages, is that right? Could you recommend a good resource that explains clearly how to maintain a system using source code compilation only?

In all honesty, I myself just don't see a good way to maintain a FreeBSD system that does not involve a complete re-install. I have tried using freebsd-update according to manuals and official documentation, only to end up with a train wreck that requires a clean re-install anyway. There are some people on the Forums that enjoy sifting through the train wreck of failed dependencies and trying to fix them one by one as they come up. I discovered that this can be an endless rabbit hole that gets me nowhere, and that got me frustrated. I just don't see this 'sifting through a train wreck' as a good approach to problem solving, esp. if I want to be up and running in a reasonable amount of time.

Now that I know what processor you have (Ryzen 9 7900) I can tell you that's a good processor, it can compile ports really quick - even the big stuff like GCC, LLVM, Rust and Guile. Those 4 alone won't take more than a day on a Ryzen 9 like yours. Mine is a Ryzen 5 7600, it takes about a couple days to compile my way from ground up into a KDE 6 desktop. My reason for confirming is that I have seen people get confused and try to use instructions that don't apply to their hardware. Fortunately, that's not an issue in our conversation.

Yeah, don't mix binary packages and ports. There's some debate on the Forums about that, but it's just a lot of work to pay attention to the specific versions of specific software that gets copied to your machine. This extra effort can be avoided if you don't try to mix and match.

froggit9000 said:
Ah, I was trying to avoid having to do that!
One idea I have is to buy another SSD, as I would like to setup a mirrored zroot boot pool. So what I could do is leave this installation for now and once I have the new SSD just install again onto that.
However, can you specify a mirror if only one disk is available, and later attach another disk?
If not, then I will need to buy two more SSDs and remove this current boot drive and keep it as a spare.
Any ideas here?

If you try to compile graphics/drm-kmod from ports (which is the more reliable way of getting a GPU driver to work under FreeBSD), there's no way around installing that src component as I showed you earlier. Well, ther is a way to do that without re-installing - if you pay attention to the specific version of FreeBSD and the patchlevel that you ended up with. It is possible to download src.txz set separately from the installer, and extract it into /usr/src. Once again, it does take paying very close attention to the FreeBSD version you have AND the version of that src.txz - a mismatch will result in a train wreck.

BTW, there's no need to recompile the kernel sources separately. Just compile graphics/drm-kmod, and the port's Makefile will take care of the rest of the details. That port does need some header files that are supposed to live in /usr/src...

So yeah, I'd suggest buying an extra SSD, and doing a fresh install.

froggit9000 · Sep 23, 2025

astyle said:
In all honesty, I myself just don't see a good way to maintain a FreeBSD system that does not involve a complete re-install. I have tried using freebsd-update according to manuals and official documentation, only to end up with a train wreck that requires a clean re-install anyway. There are some people on the Forums that enjoy sifting through the train wreck of failed dependencies and trying to fix them one by one as they come up. I discovered that this can be an endless rabbit hole that gets me nowhere, and that got me frustrated. I just don't see this 'sifting through a train wreck' as a good approach to problem solving, esp. if I want to be up and running in a reasonable amount of time.

I appreciate your experiences but it's also quite sad to hear.
If occasional reinstalls is the way it will be, then I suppose recording all settings/list of installed packages etc becomes important to get back up to speed after each periodic reinstall.

astyle said:
Now that I know what processor you have (Ryzen 9 7900) I can tell you that's a good processor, it can compile ports really quick - even the big stuff like GCC, LLVM, Rust and Guile. Those 4 alone won't take more than a day on a Ryzen 9 like yours. Mine is a Ryzen 5 7600, it takes about a couple days to compile my way from ground up into a KDE 6 desktop. My reason for confirming is that I have seen people get confused and try to use instructions that don't apply to their hardware. Fortunately, that's not an issue in our conversation.

Yes, it's a great low power CPU at only 65W TDP/88W PPT iirc, and yes it is definitely speedy. I hear what you say about the importance of proper identification.

astyle said:
Yeah, don't mix binary packages and ports. There's some debate on the Forums about that, but it's just a lot of work to pay attention to the specific versions of specific software that gets copied to your machine. This extra effort can be avoided if you don't try to mix and match.

OK, that makes sense.
If I was thinking mixing packages and ports then I suppose I would need to maintain a list of installed ports so I knew which ones I had installed in the case of problems or reinstallation?
But from what you've said it seems doing a basic re-installation, then recompiling the /usr/src and then /usr/ports source code trees is what I should do next time I do a reinstallation of FreeBSD?
If so then I'll ask Santy for 2 SSDs for Christmas and install release 15.0 of FreeBSD.

astyle · Sep 23, 2025

froggit9000 said:
But from what you've said it seems doing a basic re-installation, then recompiling the /usr/src and then /usr/ports source code trees is what I should do next time I do a reinstallation of FreeBSD?

Not quite... I've been saying that you do need to select the src set as shown earlier, but that doesn't involve compiling it! There's no need to recompile the whole kernel. Just
cd /usr/ports/graphics/drm-kmod, then do make && make install in that directory, and that's what it takes to prepare to enable amdgpu on your system.

/usr/src is where the header files and kernel sources live. When you select the src set as shown earlier, correct source files will appear in that directory. If you don't select the src set as shown earlier, then /usr/src will be empty, and the drm-kmod compilation will fail.

astyle · Sep 23, 2025

froggit9000 said:
I appreciate your experiences but it's also quite sad to hear.
If occasional reinstalls is the way it will be, then I suppose recording all settings/list of installed packages etc becomes important to get back up to speed after each periodic reinstall.

Linux is like that, as well. Same dependency hell. I switched to FreeBSD because it doesn't change major components at the drop of a hat. FreeBSD still uses ifconfig, while Linux switched to ip. I don't see any technical merit in that. Frankly, though, ZFS was the game changer for me back in 2017.

I currently have a complete KDE 6 desktop, with 1611 packages, as reported by pkg info | wc -l.

BTW, with FreeBSD's ports, I don't have to reinstall as often as with Linux.