Solved FreeBSD 14.3-BETA1: amdgpu no longer works

[zsolt]

Hi,

I follow this to upgrade from FreeBSD-14.2. At the end I also reinstalled all my packages but amdgpu is refusing to load. Messages returns this:

May 4 12:24:19 ThinkBook15-G2 kernel: link_elf_obj: symbol linux_kfree_async undefined
May 4 12:24:19 ThinkBook15-G2 kernel: linker_load_file: /boot/modules/dmabuf.ko - unsupported file type
May 4 12:24:19 ThinkBook15-G2 kernel: KLD drm.ko: depends on dmabuf - not available or version mismatch
May 4 12:24:19 ThinkBook15-G2 kernel: iic0: detached
May 4 12:24:19 ThinkBook15-G2 kernel: iicbus0: <unknown card> at addr 0
May 4 12:24:19 ThinkBook15-G2 kernel: iic1: detached
May 4 12:24:19 ThinkBook15-G2 kernel: iicbus1: <unknown card> at addr 0
May 4 12:24:19 ThinkBook15-G2 kernel: linker_load_file: /boot/modules/drm.ko - unsupported file type
May 4 12:24:19 ThinkBook15-G2 kernel: KLD amdgpu.ko: depends on drmn - not available or version mismatch
May 4 12:24:19 ThinkBook15-G2 kernel: linker_load_file: /boot/modules/amdgpu.ko - unsupported file type

Any solutions are highly appreciated.

 

[SirDice]

Build graphics/drm-kmod from ports. The packages in the repository are built for 14.2.

 

[zsolt]

I can confirm that after installing the ports collection and the source files for releng/14.3 all work again.
Thanks.

 

[bob2112]

Is there a way of knowing when the minor version of FreeBSD, that these packages are built against, changes? Preferably something that can be scripted.

 

[astyle]

Is there a way of knowing when the minor version of FreeBSD, that these packages are built against, changes? Preferably something that can be scripted.

Well, you can keep your eyes peeled and monitor this page: https://www.freebsd.org/releases/ .

But frankly, that's just an incorrect framing of the problem. If you try to do freebsd-update(8), you'll need to upgrade the packages, as well. Except that if you have to use drm-kmod, it's a problem if the packages are not built yet.

Basically, there's a bit of a gap between releases of base OS and availability of corresponding package repos. If you're impatient, and upgrade the base OS too quickly, there's a good chance the repos are not ready yet. Core dev team are not the same people who maintain the ports repos. First, the base OS is released, then the Ports team builds the package repos. If you don't wanna wait for the dust to settle, just use a recent snapshot of ports, that's what the devs do themselves... oh, and I do exactly that, even though I'm not a dev...

 

[bob2112]

Well, you can keep your eyes peeled and monitor this page: https://www.freebsd.org/releases/ .

But frankly, that's just an incorrect framing of the problem. If you try to do freebsd-update(8), you'll need to upgrade the packages, as well. Except that if you have to use drm-kmod, it's a problem if the packages are not built yet.

Basically, there's a bit of a gap between releases of base OS and availability of corresponding package repos. If you're impatient, and upgrade the base OS too quickly, there's a good chance the repos are not ready yet. Core dev team are not the same people who maintain the ports repos. First, the base OS is released, then the Ports team builds the package repos. If you don't wanna wait for the dust to settle, just use a recent snapshot of ports, that's what the devs do themselves... oh, and I do exactly that, even though I'm not a dev...

It's the other way around, when a new set of quarterly packages is available, I want to know whether they will work with my existing base system before I install them.

Actually, I see the individual driver packages, like gpu-firmware-amd-kmod-renoir-20230625.1402000_2, have the base system version in the package name.

 

[astyle]

It's the other way around, when a new set of quarterly packages is available, I want to know whether they will work with my existing base system before I install them.

That's easy, the repos are tagged appropriately. From /etc/pkg/FreeBSD.conf, the repos will be tagged with the ABI version: url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly, and they are released on a schedule.

And yep, the $ABI value is the base version to pay attention to.

But don't get confused about the order of things, or else you'll be the one stuck with a train wreck that requires a clean reinstall. Base OS gets released first, then packages get built for it. If you wanna upgrade packages, match them to tbe base OS, which is the $ABI value I just talked about. If you upgrade the OS, you have to pay attention to the $ABI of the package repo, or else face that same train wreck of dependency hell.

Well, I avoid all that headache of pkg by using ports and being patient for about 3 days.

 

[bob2112]

That's easy, the repos are tagged appropriately. From /etc/pkg/FreeBSD.conf, the repos will be tagged with the ABI version: url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly, and they are released on a schedule.

And yep, the $ABI value is the base version to pay attention to.

But don't get confused about the order of things, or else you'll be the one stuck with a train wreck that requires a clean reinstall. Base OS gets released first, then packages get built for it. If you wanna upgrade packages, match them to tbe base OS, which is the $ABI value I just talked about. If you upgrade the OS, you have to pay attention to the $ABI of the package repo, or else face that same train wreck of dependency hell.

Well, I avoid all that headache of pkg by using ports and being patient for about 3 days.

It doesn't work like that.

The ABI is per major release, not minor release. At any one time, packages are built against one specific security branch for each major version. The problem I was referring to arises when the build servers switch to building against a later release branch on the same stable branch. This commonly results in a black screen on the next boot if those packages are installed without checking. I only regard this as an annoyance, and with boot environments, a very minor one. I image it could be daunting to a new user; in some cases it may involve working in single user mode.

The only reason for doing a clean reinstall to fix a port problem, is if the base system has been corrupted - I've never heard of that happening. There is no scope for a "train wreck of dependency hell" in any of this.

IMO the best reason for using ports is if you want to learn how to fix problems. I've been using FreeBSD for about 20 years. Most of that time I used ports, but I've been using packages for at least 5 years, and in that time this is the only problem (aside from upstream bugs) that I've seen - and I consider it very minor. The chief problem with packages is that they aren't considered cool.

 

[astyle]

The chief problem with packages is that they aren't considered cool.

Well, duh, it's not cool to have a missing feature when upstream project's documentation says that the feature is supposed to be there. Especially when I see the feature as important in my daily use.

The only reason for doing a clean reinstall to fix a port problem,

Yeah, the graphics/drm-kmod one or the www/firefox one. Every train wreck that I see, one or the other is involved in the dependency hell. graphics/drm-kmod is particularly problematic, because it has to match even the minor release version. But if you compile it from sources (even with the .bin blobs), you'll be fine, no need to check for package availability in the FreeBSD repos.

As for base - I've seen config mistakes, which are usually easily fixed by editing /etc/rc.conf or /boot/loader.conf or something similar.

 

[bob2112]

Well, duh, it's not cool to have a missing feature when upstream project's documentation says that the feature is supposed to be there. Especially when I see the feature as important in my daily use.


Yeah, the graphics/drm-kmod one or the www/firefox one. Every train wreck that I see, one or the other is involved in the dependency hell. graphics/drm-kmod is particularly problematic, because it has to match even the minor release version. But if you compile it from sources (even with the .bin blobs), you'll be fine, no need to check for package availability in the FreeBSD repos.

As for base - I've seen config mistakes, which are usually easily fixed by editing /etc/rc.conf or /boot/loader.conf or something similar.

All I have to do is update the base system to the version used for package building and everything just works.

My only problem was that it is wasn't clear when new quarterly releases were compatible - now that I know that the base version is in the package file names, this is a solved problem as far as I'm concerned. I don't expect to see any more such problems again.

You seems to be using your own private definition of "dependency hell" and (hopefully) "clean install" which makes it hard to follow your meaning. I wouldn't call any of this a train wreck. Unless you build ports the way poudriere does, you are cutting corners and it's important to know which you can safely cut and which you can't.

 

[astyle]

You seems to be using your own private definition of "dependency hell" and (hopefully) "clean install" which makes it hard to follow your meaning. I wouldn't call any of this a train wreck. Unless you build ports the way poudriere does, you are cutting corners and it's important to know which you can safely cut and which you can't.

I use the term 'dependency hell' as defined in Wikipedia... The worst part is that it's recursive - you resolve incompatibilities with package A, and suddenly you have imcompatibilities with the dependencies of that package, which also need to be resolved. Kind of like a broccoli bunch. Eventually, it gets to be too time-consuming, and affects so many packages, that it's easier to do a clean reinstall anyway. That's what a 'train wreck' is.

I build my ports as specified by the User Handbook. I do need to turn on features that official package/repo builders turn off for whatever reason. And Poudriere - that was a neat toy, but a lot of work to get going. I still might come back to that project, I have my ideas for it.

 

[bob2112]

I use the term 'dependency hell' as defined in Wikipedia... The worst part is that it's recursive - you resolve incompatibilities with package A, and suddenly you have imcompatibilities with the dependencies of that package, which also need to be resolved. Kind of like a broccoli bunch. Eventually, it gets to be too time-consuming, and affects so many packages, that it's easier to do a clean reinstall anyway. That's what a 'train wreck' is.

I build my ports as specified by the User Handbook. I do need to turn on features that official package/repo builders turn off for whatever reason. And Poudriere - that was a neat toy, but a lot of work to get going. I still might come back to that project, I have my ideas for it.

That dependency hell is a consequence of the way you tried to fix the problem.

Given these "train wrecks" and the "dependency hell" you are experiencing, I hope you are not going to continue to claim that your way is better, and that using pkg is reckless in some way - it's serious disinformation.

I suggest you check that you genuinely need the modified port options at build time - I haven't seen any such problems. I have seen a port where the defaults options caused the application to dump core, but it's easy to handle a few packages through the quarterly ports tree and let pkg do most of the work.

 

[astyle]

That dependency hell is a consequence of the way you tried to fix the problem.

Have you tried telling that to everyone who tried to upgrade the FreeBSD base or Firefox? The basic problem in dependency hell is that software/component versions have to match. LIke drm-kmod version is usually for a very specific version of the -RELEASE-tagged FreeBSD...

I don't experience train wrecks, you do. I'm the smart one here...

I did check - yes I do need the modified port options. WIthout them, FreeBSD would be just another stop on the never-ending distro-hopping journey. If I wanted to let pkg do most of the work, I'd just install Slackware, complete with systemd.

Using pkg is pretty reckless - especially if you have blind trust and no skill in error resolution. And no, that's not disinformation, buddy.

 

[bob2112]

Have you tried telling that to everyone who tried to upgrade the FreeBSD base or Firefox? The basic problem in dependency hell is that software/component versions have to match. LIke drm-kmod version is usually for a very specific version of the -RELEASE-tagged FreeBSD...

I don't experience train wrecks, you do. I'm the smart one here...

I did check - yes I do need the modified port options. WIthout them, FreeBSD would be just another stop on the never-ending distro-hopping journey. If I wanted to let pkg do most of the work, I'd just install Slackware, complete with systemd.

Using pkg is pretty reckless - especially if you have blind trust and no skill in error resolution. And no, that's not disinformation, buddy.

When you build from ports, you can avoid most dependency problems, other than explicit conflicts. For obvious reasons I didn't have any problems with Firefox, but it sounds like you had to force a rebuild of Firefox following a base system update and a forced rebuild of drm-kmod. In that situation it's practically impossible to run into dependency problems - provided the packages are properly up to date wrt to the ports tree.

 

[astyle]

it sounds like you had to force a rebuild of Firefox following a base system update and a forced rebuild of drm-kmod.

I personally don't do freebsd-update(8) - I install fresh from scratch, complete with disk formatting. And I don't force a rebuild, I compile from a fresh Ports snapshot that is a few minutes old at best, just because I prefer to do that. That way, I get a fresh copy of Firefox and drm-kmod, it's just a benefit I enjoy.

 

[recluce]

Of course... the one time that I build a new system with binary packages instead with ports... to save time...

I get it that drm-61-kmod packages may not be built against 14.3 yet, but can't they simply include a warning on install that says that? There are warnings for all kinds of minor stuff, but not that.

 

[T-Daemon]

I get it that drm-61-kmod packages may not be built against 14.3 yet, but can't they simply include a warning on install that says that? There are warnings for all kinds of minor stuff, but not that.

There have been improvements in this regard. From >=14.3 on, special kernel modules repositories for point releases have been introduced:

FreeBSD 14.3-RELEASE Release Notes

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

www.freebsd.org

Ports Collection and Package Infrastructure

A new FreeBSD-kmods repository is included in the default /etc/pkg/FreeBSD.conf pkg(8) configuration file. This repository contains kernel modules compiled specifically for 14.3-RELEASE rather than for the 14-STABLE branch. Installing kernel modules from this repository allows drivers with unstable kernel interfaces, in particular graphics drivers, to work even when the main 14-STABLE repository has packages build on a previous release. (a47542f71511).

>=14.3 /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
}

A "kmods_latest" is available as well.

Usage: pkg install -r FreeBSD-kmods drm-61-kmod

Package messages have been also updated:

% pkg  info -D  drm-61-kmod
...
Please note that this package was built for FreeBSD 14.3.
If this is not your current running version, please rebuild
it from ports to prevent panics when loading the module.

and package version number shows FreeBSD version:

% pkg info -E drm-61-kmod
drm-61-kmod-6.1.128.1403000_4

Here a list of available kmods:

Spoiler

% pkg search -r FreeBSD-kmods -g '*'
acerhdf-kmod-0.1.4.1403000_1   Acer Aspire One fan control
acpi_call-1.0.1.1403000_2      Kernel module for calling ACPI methods from userspace
aquantia-atlantic-kmod-0.0.5.1403000_3 Aquantia AQtion (Atlantic) Network Driver (Development Preview)
biosfont-1.3.1.1403000         Kernel module to retrieve bitmap fonts from BIOS memory
devctl-jail-kmod-g20190521.1403000 Module to expose jail lifecycle events
drm-515-kmod-5.15.160.1403000_4 DRM drivers modules
drm-61-kmod-6.1.128.1403000_4  DRM drivers modules
gpu-firmware-amd-kmod-aldebaran-20230625.1403000_2 Firmware modules for aldebaran AMD GPUs
gpu-firmware-intel-kmod-skylake-20230625.1403000 Firmware modules for skylake Intel GPUs
gpu-firmware-radeon-kmod-aruba-20220511.1403000 Firmware modules for aruba Radeon GPUs
hammer2-1.2.9.1403000          HAMMER2 file system for FreeBSD (experimental write support)
intel-em-kmod-7.7.8.1403000    Gigabit FreeBSD Base Drivers for Intel(R) Ethernet
intel-ice-kmod-1.38.16.1403000_2 Intel® Network Adapter Driver for E810 Series Devices
intel-igb-kmod-2.5.28.1403000  NIC Driver for Intel(R) 82575/6 and 82580-Based cards
intel-ix-kmod-3.3.35.1403000_2 10 gigabit FreeBSD Base Driver for Intel(R) Network Connections
intel-ixl-kmod-1.13.4.1403000_2 40 gigabit FreeBSD Base Driver for Intel(R) Network Connections
intel-ixv-kmod-1.5.34.1403000_2 10G FreeBSD Base Driver Virtual Function for Intel(R) NIC
isboot-kmod-0.2.15.1403000     Kernel module enabling iSCSI/IBFT boot
linux_dvbwrapper-kmod-1.0.1403000_2 Linux compatibility layer - DVB ioctl handler
mac_nonet-kmod-g20150821.1403000 MAC policy to disable access to networking for certain group
mac_rtprio-kmod-g20170417.1403000 MAC policy to manage access for setting realtime priorities by GID
mbgtools-f.1.0.0.1403000_1     Drivers and tools for Meinberg PTP/GPS cards
ndproxy-3.2.1403000_1          Implementation of IPv6 Neighbor Discovery proxy
ng_mikrotik_eoip-1.0.1403000   Netgraph node for Mikrotik EoIP tunneling
open-vm-kmod-12.5.0.1403000,2  Open VMware kernel modules for FreeBSD VMware guests
opencbm-kmod-0.4.99.104.1403000_2 OpenCBM driver module for parallel-port X[MA]-1541 cables
openzfs-kmod-2.3.2.1403000,1   OpenZFS kernel module for FreeBSD
parallels-tools-0.1.2.1403000_1 Parallels Desktop Tools for FreeBSD
pefs-kmod-g20230913.1403000_1,1 PEFS kernel level stacked cryptographic filesystem
plasma-kmod-0.1.1403000_4      Plasma-effect screensaver kernel module
ptx-kmod-0.0.20111212.1403000_2 Device driver for PT1/PT2 ISDB-S/T tuner cards
pwcbsd-1.4.1.1403000_15        The Linux pwc webcam driver ported to FreeBSD
quantis-kmod-v18.03.08.1403000 Kernel driver for Quantis PCI/PCIe random number generator
realtek-re-kmod-1100.00.1403000_1 Kernel driver for Realtek PCIe Ethernet Controllers
realtek-re-kmod198-198.00.1403000 Kernel driver for Realtek PCIe Ethernet Controllers
sysctlbyname-improved-kmod-20221211.1403000 Internal sysctl object to implement an improved sysctlbyname(3)
sysctlinfo-kmod-20221211.1403000_1 Kernel sysctl MIB-Tree interface
twa-kmod-20230821.1403000      3ware 9000/9500/9550/9650 series SATA RAID controllers driver
uarduno-1.02.1403000_1         FreeBSD Kernel Driver for the Arduino Uno USB interface
utouch-kmod-0.0.5.1403000      Kernel driver for absolute USB HID mice
vether-kmod-g20211214.1403000_1 Virtual Ethernet Interface
virtualbox-ose-kmod-6.1.50.1403000_1 VirtualBox kernel module for FreeBSD
virtualbox-ose-kmod-70-7.0.26.1403000 VirtualBox kernel module for FreeBSD
virtualbox-ose-kmod-71-7.1.8.1403000 VirtualBox kernel module for FreeBSD
virtualbox-ose-kmod-legacy-5.2.44.1403000_7 VirtualBox kernel module for FreeBSD
wifi-firmware-ath10k-kmod-20240513.1403000_2 Firmware modules for the ath10k (ath10k) WiFi NIC driver
wifi-firmware-ath11k-kmod-20240513.1403000_2 Firmware modules for the ath11k (ath11k) WiFi NIC driver
wifi-firmware-ath12k-kmod-20240513.1403000_2 Firmware modules for the ath12k (ath12k) WiFi NIC driver
wifi-firmware-iwlwifi-kmod-20241017.1403000_2 Firmware modules for the iwlwifi (iwlwifi) WiFi NIC driver
wifi-firmware-mt76-kmod-20240513.1403000_2 Firmware modules for the mt76 (mt76) WiFi NIC driver
wifi-firmware-mt7601u-kmod-20241017.1403000_2 Firmware modules for the mt7601u (mt7601u) WiFi NIC driver
wifi-firmware-rtw88-kmod-20241017.1403000_2 Firmware modules for the rtw88 (rtw88) WiFi NIC driver
wifi-firmware-rtw89-kmod-20241017.1403000_2 Firmware modules for the rtw89 (rtw89) WiFi NIC driver