GPU fwget wrinkle

I just read an email from BSD Weekly that seems to have shed some light on a recent issue I've seen a number of times.  Recall that I've mentioned something about amdgpu_picasso_gpu_info_bin.ko, the issue being mention of firmware that was missing.  The error message was too involved to copy down but I did catch the info filename that was repeated in the message.  I didn't know there was anything I could do about it.

Introducing FreeBSD’s fwget(8) for Firmware Management: The article discusses the fwget(8) tool in FreeBSD, introduced to manage firmware for hardware components like WiFi and GPU.  The author encountered WiFi issues after upgrading to FreeBSD 14.3-RELEASE, discovering that the Intel Wi-Fi 6 AX201 required firmware not included by default.  Running fwget(8) automatically detected and installed the missing iwlwifi-QuZ-a0-hr-b0-77.ucode firmware, restoring WiFi functionality.  The tool scans hardware devices, identifies missing firmware, and installs necessary packages (e.g., wifi-firmware-iwlwifi-kmod-22000).  The author notes the lack of official documentation in the FreeBSD Handbook, though a bug report (#286402) addresses this gap.

Obviously this intrigued me, so I tested to see more about it.

root@ichigo:~ # man fwget
FWGET(8)                FreeBSD System Manager's Manual               FWGET(8)

NAME
     fwget – install firmware packages for the running system

SYNOPSIS
     fwget [-n] [-v] [subsystem]

DESCRIPTION
     The fwget utility can be used to detect and install firmware packages for
     devices present on a running system.

     The options are as follows:

     -n          Dry run, only show needed packages

     -v          Be more verbose

     subsystem   Hardware subsystem(s), default is all supported subsystems.
                 Space separated hardware subsystems, accepts pci and usb

SEE ALSO
     firmware(9)

HISTORY
     The fwget utility first appeared in FreeBSD 14.0.

AUTHORS
     The fwget utility and this manual page were written by Emmanuel Vadot
      for Beckhoff Automation GmbH & Co.  KG.

CAVEATS
     This utility currently only supports the pci(4) and usb(4) subsystems.

FreeBSD 15.0-ALPHA5              July 7, 2025                         FWGET(8)
root@ichigo:~ # fwget -n -v
Trying to match device 0x10c9 in class network and vendor intel with pci_network_intel
Trying to match device 0x10c9 in class network and vendor intel with pci_network_intel
Trying to match device 0x8125 in class network and vendor realtek with pci_network_realtek
Trying to match device 0x15d8 in class video and vendor amd with pci_video_amd
Needed firmware packages: 'gpu-firmware-amd-kmod-picasso'
root@ichigo:~ #

It seems that all I need to do now, is actually use fwget (not a dry run) and test with a reboot.  I wonder what will be different, everything seems to be working fine without this but maybe I'm not using picasso at all?

root@ichigo:~ # fwget -v
Trying to match device 0x10c9 in class network and vendor intel with pci_network_intel
Trying to match device 0x10c9 in class network and vendor intel with pci_network_intel
Trying to match device 0x8125 in class network and vendor realtek with pci_network_realtek
Trying to match device 0x15d8 in class video and vendor amd with pci_video_amd
Needed firmware packages: 'gpu-firmware-amd-kmod-picasso'
root@ichigo:~ # ls /boot/firmware/
iwm3160fw  iwm3168fw  iwm7260fw  iwm7265Dfw iwm7265fw  iwm8000C   iwm8265fw  iwm9000fw  iwm9260fw
root@ichigo:~ # fwget -v pci
Trying to match device 0x10c9 in class network and vendor intel with pci_network_intel
Trying to match device 0x10c9 in class network and vendor intel with pci_network_intel
Trying to match device 0x8125 in class network and vendor realtek with pci_network_realtek
Trying to match device 0x15d8 in class video and vendor amd with pci_video_amd
Needed firmware packages: 'gpu-firmware-amd-kmod-picasso'
The most recent versions of packages are already installed
root@ichigo:~ # ls -l /boot/firmware/
total 7970
-rw-r--r--  1 root wheel  918268 Sep 10 21:38 iwm3160fw
-rw-r--r--  1 root wheel 1028032 Sep 10 21:38 iwm3168fw
-rw-r--r--  1 root wheel 1049340 Sep 10 21:38 iwm7260fw
-rw-r--r--  1 root wheel 1028316 Sep 10 21:38 iwm7265Dfw
-rw-r--r--  1 root wheel 1180412 Sep 10 21:38 iwm7265fw
-rw-r--r--  1 root wheel 2120860 Sep 10 21:38 iwm8000C
-rw-r--r--  1 root wheel 1811984 Sep 10 21:38 iwm8265fw
-rw-r--r--  1 root wheel 2678284 Sep 10 21:38 iwm9000fw
-rw-r--r--  1 root wheel 2678092 Sep 10 21:38 iwm9260fw
root@ichigo:~ #

I seem to be rather horrible at this, I should have checked what was at /boot/firmware before I ran the command.  I knew this directory existed but didn't know there was a way to populate it.  I'm not going to erase the directory and use fwget to repopulate it, but I probably could.  Erasing it and using fwget would just restore it to what I have now, so I still wouldn't know which file was added for the picasso.  What is interesting though is that all but one file ends with fw, which makes me wonder why one ends with C instead.

I guess the next thing to do is reboot and see what happens.  Will my amdgpu work, work better, or will I have more work myself to fix things yet again?

How rarely things are easy.  When I rebooted somehow graphics was broken again.  This likely was a hidden change that was discovered only due to things in memory being unloaded.  I don't know for certain what caused it.  Among various things I did while graphics was failing for me, was to erase the contents of /boot/firmware and just to be sure everything else was in place, I went to /usr/src to make buildworld and make installworld.  What I discovered was that that was what populated /boot/firmware, so that puzzle is solved.

However, after a lot of round and round effort, I now know that sometimes the firmware I hope to install is ignored.  If I use graphics/gpu-firmware-kmod, I believe it installs everything under the sun, all the flavors it turns out to be.  If I use graphics/gpu-firmware-amd-kmod by itself, it will install the very first firmware flavor only, aldebaran.  With a few trials and errors, I figured out that if I make FLAVOR=picasso install FLAVOR=picasso clean, then it does everything I need for it to do.

What becomes interesting in a very head-scratching way, is if fwget tells me in Dry run "Needed firmware packages: 'gpu-firmware-amd-kmod-picasso'" then why does it not actually install gpu-firmware-amd-kmod-picasso or what was I missing that caused another panic at boot?

I can verify that it does install it (just as Vermaden had in his post), in an odd location, and I note the date difference as well, which means it was most recent.

# ls -l /usr/local/share/licenses | grep firmware
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-arcturus-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-banks-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-beige-goby-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-bonaire-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-carrizo-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-amd-kmod-cyan-skillfish2-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-dcn-3-1-4-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-dcn-3-1-5-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-dcn-3-1-6-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-dcn-3-2-0-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-dcn-3-2-1-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-amd-kmod-dimgrey-cavefish-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-fiji-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-gc-10-3-6-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-gc-10-3-7-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-gc-11-0-0-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-gc-11-0-1-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-gc-11-0-2-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-gc-11-0-3-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-gc-11-0-4-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-amd-kmod-green-sardine-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-hainan-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-hawaii-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-kabini-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-kaveri-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-mullins-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-navi10-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-navi12-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-navi14-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-amd-kmod-navy-flounder-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-oland-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 22 16:44 gpu-firmware-amd-kmod-picasso-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-pitcairn-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-polaris10-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-polaris11-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-polaris12-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-psp-13-0-0-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-psp-13-0-10-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-psp-13-0-11-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-psp-13-0-4-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-psp-13-0-5-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-psp-13-0-7-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-psp-13-0-8-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-raven-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-raven2-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-renoir-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-sdma-5-2-6-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-sdma-5-2-7-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-sdma-6-0-0-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-sdma-6-0-1-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-sdma-6-0-2-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-sdma-6-0-3-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-si58-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-amd-kmod-sienna-cichlid-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-smu-13-0-0-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-smu-13-0-10-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-smu-13-0-7-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-stoney-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-tahiti-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:58 gpu-firmware-amd-kmod-tonga-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-topaz-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-amd-kmod-vangogh-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-vcn-3-1-2-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-vcn-4-0-0-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-vcn-4-0-2-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 23:00 gpu-firmware-amd-kmod-vcn-4-0-4-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-vega10-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-vega12-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-vega20-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-vegam-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-verde-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:59 gpu-firmware-amd-kmod-yellow-carp-20230625.1500066_2
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-alderlake-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-broxton-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-cannonlake-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-dg1-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-dg2-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-elkhartlake-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-geminilake-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-icelake-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-kabylake-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-rocketlake-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-skylake-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:57 gpu-firmware-intel-kmod-tigerlake-20230625.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-aruba-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-barts-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-bonaire-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-btc-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-caicos-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-cayman-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-cedar-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-cypress-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-hainan-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-hawaii-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-juniper-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-kabini-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-kaveri-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-mullins-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-oland-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-palm-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-pitcairn-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-r100-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:55 gpu-firmware-radeon-kmod-r200-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-r300-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-r420-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-r520-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-r600-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-r700-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-redwood-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rs600-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rs690-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rs780-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rv610-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rv620-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rv630-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rv635-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rv670-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rv710-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rv730-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rv740-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-rv770-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-sumo-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-sumo2-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-tahiti-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-turks-20220511.1500066
drwxr-xr-x  2 root wheel  5 Oct 21 22:56 gpu-firmware-radeon-kmod-verde-20220511.1500066
#

What seems likely is that the gpu-firmware-amdgpu-kmod files for picasso were somehow missing.  Each time I am forced to spend time solving these software riddles, it usually ends up teaching me something that I hopefully remember for next time.  If all else fails, I do have these blog posts as reference in the future.  As an overview though, for my graphics to function, I need the gpu-firmware-amdgpu-kmod picasso files, drm-kmod, and in /etc/rc.conf.local set kld_list="amdgpu" and all should be fine.  Something that is interesting, is that when I was solving problems in singleuser, I couldn't use fwget even though I was root, it claimed insufficient priviledges.

One thing fwget does is identify and install the right firmware for my amdgpu.  If I use graphics/drm-kmod to install that, it also installs all flavors of gpu-firmware-kmod, amdgpu, radeon, and intel.  In order to remove the excesses and only keep the picasso stuff, I can go to each of graphics/gpu-firmware-amdgpu-kmod, graphics/gpu-firmware-intel-kmod, and graphics/gpu-firmware-radeon-kmod and issue make FLAVOR=* deinstall and then go back to graphics/gpu-firmware-amdgpu-kmod to install FLAVOR=picasso, or more simply, just use fwget.  It may be easier to periodically comment out the RUN_DEPENDS line in graphics/drm-kmod which may have the side-effect of future updates not pulling all of the extras back again.  If something doesn't work by using fwget for whatever reason, it still indicates the correct driver so that it can be installed another way.

xlibre in place update

Since I recently noted an update to the xlibre-ports in their git repo, I decided that I would try to see how updating in place might work.  The commit that I see as most useful for this is Moved everything to the latest upstream version. because "Both the servers and the drivers are moved to their latest version." was the purpose of changes in the commit.

My first step is to change to the xlibre-ports directory and issue git pull to update my local copy.  I know that right now my system may be a hodge podge of various ports or packages, and any minor changes I made in the xlibre-ports directory are undone.  My changes might not be needed, but I will still monitor the build process to "fast forward" any dependencies by installing via pkg.  As you can see, there have been quite a few changes and a lot of additions.

root@ichigo:/home/tigersharke/xlibre-ports # git pull
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (32/32), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 100 (delta 24), reused 26 (delta 24), pack-reused 68 (from 1)
Receiving objects: 100% (100/100), 23.30 KiB | 23.30 MiB/s, done.
Resolving deltas: 100% (33/33), completed with 24 local objects.
From https://github.com/b-aaz/xlibre-ports
   b920d89..bf5c560  master     -> origin/master
Updating b920d89..bf5c560
Fast-forward
 .ci/run.sh                                                                        | 410 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 .ci/srch.c                                                                        |  46 +++++++++++++
 .ci/usleep.c                                                                      |  16 +++++
 .ci/vm.sh                                                                         | 161 ++++++++++++++++++++++++++++++++++++++++++++
 .cirrus.yml                                                                       | 247 +++++++++++++++++++++++++++++++++++++-------------------------------
 README.md                                                                         |  38 ++++++-----
 x11-drivers/xlibre-drivers/Makefile                                               |  14 +++-
 x11-drivers/xlibre-xf86-input-elographics/Makefile                                |   3 +-
 x11-drivers/xlibre-xf86-input-elographics/distinfo                                |   6 +-
 x11-drivers/xlibre-xf86-input-evdev/Makefile                                      |   7 +-
 x11-drivers/xlibre-xf86-input-evdev/distinfo                                      |   6 +-
 x11-drivers/xlibre-xf86-input-joystick/Makefile                                   |   5 +-
 x11-drivers/xlibre-xf86-input-joystick/distinfo                                   |   6 +-
 x11-drivers/xlibre-xf86-input-joystick/dragonfly/patch-configure.ac               |  26 ++++++++
 x11-drivers/xlibre-xf86-input-joystick/dragonfly/patch-src_backend__bsd.c         |  30 +++++++++
 x11-drivers/xlibre-xf86-input-keyboard/Makefile                                   |   3 +-
 x11-drivers/xlibre-xf86-input-keyboard/distinfo                                   |   6 +-
 x11-drivers/xlibre-xf86-input-libinput/Makefile                                   |   4 +-
 x11-drivers/xlibre-xf86-input-libinput/distinfo                                   |   6 +-
 x11-drivers/xlibre-xf86-input-mouse/Makefile                                      |   3 +-
 x11-drivers/xlibre-xf86-input-mouse/distinfo                                      |   6 +-
 x11-drivers/xlibre-xf86-input-mouse/files/patch-src-bsd_mouse.c                   |  10 ++-
 x11-drivers/xlibre-xf86-input-synaptics/Makefile                                  |   3 +-
 x11-drivers/xlibre-xf86-input-synaptics/distinfo                                  |   6 +-
 x11-drivers/xlibre-xf86-input-vmmouse/Makefile                                    |  21 +++++-
 x11-drivers/xlibre-xf86-input-vmmouse/distinfo                                    |   6 +-
 x11-drivers/xlibre-xf86-input-vmmouse/dragonfly/patch-configure.ac                |  29 ++++++++
 x11-drivers/xlibre-xf86-input-void/Makefile                                       |   3 +-
 x11-drivers/xlibre-xf86-input-void/distinfo                                       |   6 +-
 x11-drivers/xlibre-xf86-input-wacom/Makefile                                      |   8 ++-
 x11-drivers/xlibre-xf86-input-wacom/distinfo                                      |   6 +-
 x11-drivers/xlibre-xf86-video-amdgpu/Makefile                                     |   4 +-
 x11-drivers/xlibre-xf86-video-amdgpu/distinfo                                     |   6 +-
 x11-drivers/xlibre-xf86-video-amdgpu/dragonfly/patch-configure.ac                 |  19 ++++++
 x11-drivers/xlibre-xf86-video-amdgpu/dragonfly/patch-src_amdgpu__bo__helper.c     |  20 ++++++
 x11-drivers/xlibre-xf86-video-amdgpu/dragonfly/patch-src_amdgpu__kms.c            |  16 +++++
 x11-drivers/xlibre-xf86-video-ast/Makefile                                        |   7 +-
 x11-drivers/xlibre-xf86-video-ast/distinfo                                        |   6 +-
 x11-drivers/xlibre-xf86-video-ati/Makefile                                        |   4 +-
 x11-drivers/xlibre-xf86-video-ati/distinfo                                        |   6 +-
 x11-drivers/xlibre-xf86-video-ati/dragonfly/dragonfly/patch-src_radeon__kms.c     |  30 +++++++++
 x11-drivers/xlibre-xf86-video-ati/dragonfly/dragonfly/patch-src_radeon__probe.c   |  25 +++++++
 x11-drivers/xlibre-xf86-video-ati/dragonfly/patch-src_radeon__kms.c               |  38 +++++++++++
 x11-drivers/xlibre-xf86-video-ati/dragonfly/patch-src_radeon__probe.c             |  20 ++++++
 x11-drivers/xlibre-xf86-video-dummy/Makefile                                      |   3 +-
 x11-drivers/xlibre-xf86-video-dummy/distinfo                                      |   6 +-
 x11-drivers/xlibre-xf86-video-intel/Makefile                                      |  15 ++++-
 x11-drivers/xlibre-xf86-video-intel/distinfo                                      |   6 +-
 x11-drivers/xlibre-xf86-video-intel/dragonfly/patch-src_intel__device.c           |  23 +++++++
 x11-drivers/xlibre-xf86-video-intel/dragonfly/patch-src_sna_kgem.c                |  21 ++++++
 x11-drivers/xlibre-xf86-video-intel/dragonfly/patch-src_sna_sna__video.c          |  12 ++++
 x11-drivers/xlibre-xf86-video-mga/Makefile                                        |   5 +-
 x11-drivers/xlibre-xf86-video-mga/distinfo                                        |   6 +-
 x11-drivers/xlibre-xf86-video-nv/Makefile                                         |   9 ++-
 x11-drivers/xlibre-xf86-video-nv/distinfo                                         |   6 +-
 x11-drivers/xlibre-xf86-video-qxl/Makefile                                        |   3 +-
 x11-drivers/xlibre-xf86-video-qxl/distinfo                                        |   6 +-
 x11-drivers/xlibre-xf86-video-vesa/Makefile                                       |   5 +-
 x11-drivers/xlibre-xf86-video-vesa/distinfo                                       |   6 +-
 x11-drivers/xlibre-xf86-video-vesa/files/patch-src_vesa.c                         |  15 -----
 x11-drivers/xlibre-xf86-video-vmware/Makefile                                     |   3 +-
 x11-drivers/xlibre-xf86-video-vmware/distinfo                                     |   6 +-
 x11-servers/xlibre-server/Makefile.common                                         |   7 +-
 x11-servers/xlibre-server/Makefile.version                                        |   2 +-
 x11-servers/xlibre-server/distinfo                                                |   6 +-
 x11-servers/xlibre-server/dragonfly/patch-config_udev.c                           |  47 +++++++++++++
 x11-servers/xlibre-server/dragonfly/patch-hw_xfree86_common_xf86AutoConfig.c      |  12 ++++
 x11-servers/xlibre-server/dragonfly/patch-hw_xfree86_drivers_modesetting_driver.c |  11 ++++
 x11-servers/xlibre-server/dragonfly/patch-hw_xfree86_os-support_meson.build       |  20 ++++++
 x11-servers/xlibre-server/dragonfly/patch-hw_xfree86_xorg-wrapper.c               |  20 ++++++
 x11-servers/xlibre-server/files/patch-hw_xfree86_compat_ones.c                    |  15 +++++
 x11-servers/xlibre-server/files/patch-meson.build                                 |  11 ++++
 72 files changed, 1401 insertions(+), 254 deletions(-)
 create mode 100755 .ci/run.sh
 create mode 100644 .ci/srch.c
 create mode 100644 .ci/usleep.c
 create mode 100755 .ci/vm.sh
 create mode 100644 x11-drivers/xlibre-xf86-input-joystick/dragonfly/patch-configure.ac
 create mode 100644 x11-drivers/xlibre-xf86-input-joystick/dragonfly/patch-src_backend__bsd.c
 create mode 100644 x11-drivers/xlibre-xf86-input-vmmouse/dragonfly/patch-configure.ac
 create mode 100644 x11-drivers/xlibre-xf86-video-amdgpu/dragonfly/patch-configure.ac
 create mode 100644 x11-drivers/xlibre-xf86-video-amdgpu/dragonfly/patch-src_amdgpu__bo__helper.c
 create mode 100644 x11-drivers/xlibre-xf86-video-amdgpu/dragonfly/patch-src_amdgpu__kms.c
 create mode 100644 x11-drivers/xlibre-xf86-video-ati/dragonfly/dragonfly/patch-src_radeon__kms.c
 create mode 100644 x11-drivers/xlibre-xf86-video-ati/dragonfly/dragonfly/patch-src_radeon__probe.c
 create mode 100644 x11-drivers/xlibre-xf86-video-ati/dragonfly/patch-src_radeon__kms.c
 create mode 100644 x11-drivers/xlibre-xf86-video-ati/dragonfly/patch-src_radeon__probe.c
 create mode 100644 x11-drivers/xlibre-xf86-video-intel/dragonfly/patch-src_intel__device.c
 create mode 100644 x11-drivers/xlibre-xf86-video-intel/dragonfly/patch-src_sna_kgem.c
 create mode 100644 x11-drivers/xlibre-xf86-video-intel/dragonfly/patch-src_sna_sna__video.c
 delete mode 100644 x11-drivers/xlibre-xf86-video-vesa/files/patch-src_vesa.c
 create mode 100644 x11-servers/xlibre-server/dragonfly/patch-config_udev.c
 create mode 100644 x11-servers/xlibre-server/dragonfly/patch-hw_xfree86_common_xf86AutoConfig.c
 create mode 100644 x11-servers/xlibre-server/dragonfly/patch-hw_xfree86_drivers_modesetting_driver.c
 create mode 100644 x11-servers/xlibre-server/dragonfly/patch-hw_xfree86_os-support_meson.build
 create mode 100644 x11-servers/xlibre-server/dragonfly/patch-hw_xfree86_xorg-wrapper.c
 create mode 100644 x11-servers/xlibre-server/files/patch-hw_xfree86_compat_ones.c
 create mode 100644 x11-servers/xlibre-server/files/patch-meson.build
root@ichigo:/home/tigersharke/xlibre-ports #

As before, the instruction tells me:

git clone https://github.com/b-aaz/xlibre-ports.git
cd xlibre-ports/
echo "OVERLAYS=$(pwd)/" >> /etc/make.conf
make clean
make install

Since I just updated by git pull in my previously cloned directory, that step is satisfied.  This being done after my previous install, the overlays step is done as well.  The main change is that since things were already installed, I need to make reinstall instead.  Right after I initiated the command, I realized that I probably should have updated the ports tree as well.  I am not sure how this would affect the result.

It turns out that everything built and installed, no problems at all.  Unfortunately I should update the ports tree and reinstall xlibre-ports again.  This may change the result, and I have not yet proved everything works by exiting FVWM3 without or with a reboot first.  I usually use net/gitup to handle ports tree updates but it wasn't reinstalled from the last time it was removed with everything else, so I did a pkg install gitup for it.  Once the ports tree is updated I repeat the make reinstall for xlibre-ports and see what happens next.

What I was expecting I guess was that anything from ports might get drawn in but either I try to go to each and every tangential dependency to update it by building from ports, or I try to update everything on the system via pkg and see what happens next.  I should reinstall xlibre-ports after this of course, which would be my third reinstall this session while writing a blog post about it.  The pkg upgrade is rather large.

root@ichigo:/home/tigersharke/xlibre-ports # pkg upgrade
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking for upgrades (405 candidates): 100%
Processing candidates (405 candidates): 100%
The following 185 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        libwacom: 2.12.1 [FreeBSD-ports]
        py311-libevdev: 0.11_2 [FreeBSD-ports]
        spirv-llvm-translator-llvm19: 19.1.12 [FreeBSD-ports]
        xbacklight: 1.2.3_1 [FreeBSD-ports]

Installed packages to be UPGRADED:
        Imath: 3.2.1 -> 3.2.2 [FreeBSD-ports]
        bash: 5.3.3_1 -> 5.3.3_2 [FreeBSD-ports]
        drm-66-kmod: 6.6.25.1500066_5 -> 6.6.25.1500067_5 [FreeBSD-ports]
        firefox: 143.0.3,2 -> 144.0_2,2 [FreeBSD-ports]
        freetype2: 2.13.3 -> 2.14.1 [FreeBSD-ports]
        git: 2.51.0 -> 2.51.1 [FreeBSD-ports]
        go124: 1.24.7 -> 1.24.9 [FreeBSD-ports]
        gperf: 3.2.1_1 -> 3.3 [FreeBSD-ports]
        gpu-firmware-amd-kmod-aldebaran: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-arcturus: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-banks: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-beige-goby: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-bonaire: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-carrizo: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-cyan-skillfish2: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-dcn-3-1-4: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-dcn-3-1-5: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-dcn-3-1-6: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-dcn-3-2-0: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-dcn-3-2-1: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-dimgrey-cavefish: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-fiji: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-gc-10-3-6: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-gc-10-3-7: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-gc-11-0-0: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-gc-11-0-1: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-gc-11-0-2: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-gc-11-0-3: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-gc-11-0-4: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-green-sardine: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-hainan: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-hawaii: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-kabini: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-kaveri: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-mullins: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-navi10: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-navi12: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-navi14: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-navy-flounder: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-oland: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-picasso: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-pitcairn: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-polaris10: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-polaris11: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-polaris12: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-psp-13-0-0: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-psp-13-0-10: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-psp-13-0-11: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-psp-13-0-4: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-psp-13-0-5: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-psp-13-0-7: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-psp-13-0-8: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-raven: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-raven2: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-renoir: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-sdma-5-2-6: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-sdma-5-2-7: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-sdma-6-0-0: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-sdma-6-0-1: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-sdma-6-0-2: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-sdma-6-0-3: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-si58: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-sienna-cichlid: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-smu-13-0-0: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-smu-13-0-10: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-smu-13-0-7: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-stoney: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-tahiti: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-tonga: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-topaz: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-vangogh: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-vcn-3-1-2: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-vcn-4-0-0: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-vcn-4-0-2: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-vcn-4-0-4: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-vega10: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-vega12: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-vega20: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-vegam: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-verde: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-amd-kmod-yellow-carp: 20230625.1500066_2 -> 20230625.1500067_2 [FreeBSD-ports]
        gpu-firmware-intel-kmod-alderlake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-broxton: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-cannonlake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-dg1: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-dg2: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-elkhartlake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-geminilake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-icelake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-kabylake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-rocketlake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-skylake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-intel-kmod-tigerlake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-aruba: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-barts: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-bonaire: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-btc: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-caicos: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-cayman: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-cedar: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-cypress: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-hainan: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-hawaii: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-juniper: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-kabini: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-kaveri: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-mullins: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-oland: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-palm: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-pitcairn: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-r100: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-r200: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-r300: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-r420: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-r520: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-r600: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-r700: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-redwood: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rs600: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rs690: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rs780: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rv610: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rv620: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rv630: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rv635: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rv670: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rv710: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rv730: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rv740: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-rv770: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-sumo: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-sumo2: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-tahiti: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-turks: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gpu-firmware-radeon-kmod-verde: 20220511.1500066 -> 20220511.1500067 [FreeBSD-ports]
        gtk-doc: 1.33.2_3 -> 1.35.1 [FreeBSD-ports]
        gtk3: 3.24.50 -> 3.24.51 [FreeBSD-ports]
        libgpg-error: 1.55 -> 1.56 [FreeBSD-ports]
        libheif: 1.19.8_2 -> 1.19.8_3 [FreeBSD-ports]
        libnghttp2: 1.67.0 -> 1.67.1 [FreeBSD-ports]
        librsvg2-rust: 2.60.0_5 -> 2.60.0_6 [FreeBSD-ports]
        libunistring: 1.4 -> 1.4.1 [FreeBSD-ports]
        mpg123: 1.33.2 -> 1.33.3 [FreeBSD-ports]
        nss: 3.116 -> 3.117 [FreeBSD-ports]
        openexr: 3.4.0 -> 3.4.1_1 [FreeBSD-ports]
        openjpeg: 2.5.3 -> 2.5.4 [FreeBSD-ports]
        openjph: 0.22.0 -> 0.24.1 [FreeBSD-ports]
        p5-URI: 5.32_1 -> 5.34 [FreeBSD-ports]
        py311-cython3: 3.1.3 -> 3.1.4 [FreeBSD-ports]
        py311-markupsafe: 3.0.2 -> 3.0.3 [FreeBSD-ports]
        py311-pyparsing: 3.2.3 -> 3.2.5 [FreeBSD-ports]
        py311-trove-classifiers: 2025.8.26.11 -> 2025.9.11.17 [FreeBSD-ports]
        python311: 3.11.13_1 -> 3.11.14 [FreeBSD-ports]
        rust: 1.89.0 -> 1.90.0_1 [FreeBSD-ports]
        tiff: 4.7.0 -> 4.7.1 [FreeBSD-ports]

Installed packages to be REINSTALLED:
        autoconf-2.72 [FreeBSD-ports] (options changed)
        automake-1.17 [FreeBSD-ports] (options changed)
        ccache-3.7.12_8 [FreeBSD-ports] (options changed)
        cmake-core-3.31.9 [FreeBSD-ports] (options changed)
        cunit-2.1.3_3 [FreeBSD-ports] (options changed)
        gettext-tools-0.23.1_1 [FreeBSD-ports] (options changed)
        gmake-4.4.1 [FreeBSD-ports] (options changed)
        libevent-2.1.12 [FreeBSD-ports] (direct dependency removed: openssl)
        libinput-1.28.1 [FreeBSD-ports] (options changed)
        libmysofa-1.3.3 [FreeBSD-ports] (options changed)
        libspice-server-0.16.0 [FreeBSD-ports] (direct dependency changed: cyrus-sasl)
        libtextstyle-0.23.1 [FreeBSD-ports] (options changed)
        m4-1.4.19_1,1 [FreeBSD-ports] (options changed)
        mesa-dri-24.1.7_9 [FreeBSD-ports] (options changed)
        mesa-libs-24.1.7_1 [FreeBSD-ports] (options changed)
        ninja-1.13.1,4 [FreeBSD-ports] (options changed)
        openal-soft-1.24.3 [FreeBSD-ports] (options changed)
        openssl-3.0.18,1 [FreeBSD-ports] (options changed)
        pkgconf-2.4.3,1 [FreeBSD-ports] (options changed)
        rhash-1.4.4_1 [FreeBSD-ports] (options changed)
        ruby-3.3.9,1 [FreeBSD-ports] (direct dependency changed: libunwind)
        ruby33-gems-3.7.2 [FreeBSD-ports] (options changed)
        sdl2-2.32.8 [FreeBSD-ports] (options changed)
        sdl2_ttf-2.24.0 [FreeBSD-ports] (options changed)
        webcamd-5.17.1.2_2 [FreeBSD-ports] (options changed)
        xorg-apps-7.7_4 [FreeBSD-ports] (options changed)

Number of packages to be installed: 4
Number of packages to be upgraded: 155
Number of packages to be reinstalled: 26

The process will require 58 MiB more space.
455 MiB to be downloaded.

Interesting, when I try to make reinstall it seems something changed and now I get this error.  My guess is that any number of 'options changed' as indicated above with the pkg upgrade might be affecting this.

checking whether to build static libraries...  no
checking pkg-config is at least version 0.25...  yes
Package bzip2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `bzip2.pc'
to the PKG_CONFIG_PATH environment variable
Package 'bzip2', required by 'freetype2', not found
checking if RANDR is defined...  no
Package bzip2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `bzip2.pc'
to the PKG_CONFIG_PATH environment variable
Package 'bzip2', required by 'freetype2', not found
checking if XINPUT is defined...  no
checking for xorg-server >= 1.18.0 xproto ...  no
configure: error: Package requirements (xorg-server >= 1.18.0 xproto ) were not met:

Package 'bzip2', required by 'freetype2', not found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables XORG_CFLAGS
and XORG_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
===>  Script "configure" failed unexpectedly.
Please report the problem to b-aazbsd@proton.me [maintainer] and attach the
"/home/tigersharke/xlibre-ports/x11-drivers/xlibre-xf86-input-elographics/work/xf86-input-elographics-xlibre-xf86-input-elographics-1.4.4.2/config.log"
including the output of the failure of your make command.  Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g.  a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make[3]: stopped making "deinstall install" in /home/tigersharke/xlibre-ports/x11-drivers/xlibre-xf86-input-elographics
*** Error code 1

Stop.
make[2]: stopped making "reinstall" in /home/tigersharke/xlibre-ports/x11-drivers/xlibre-xf86-input-elographics
*** Error code 1

Stop.
make[1]: stopped making "reinstall" in /home/tigersharke/xlibre-ports/x11-drivers
*** Error code 1

Stop.
make: stopped making "reinstall" in /home/tigersharke/xlibre-ports

A pkg install bzip2 should have cured this, but considering that I forgot to clean the prior xlibre-ports build attempt, I went to print/freetype2 to rebuild it from ports also.  I solved this issue one way or another, but it seems quite odd, because I had previously installed freetype2 by pkg (note the pkg upgrade above), so if bzip2 was a dependency but missing, pkg ought to have added that as well.  To test what I should have done, I wanted to remove bzip2 but now that is tied to everything, and so I did not.

root@ichigo:/home/tigersharke/xlibre-ports # pkg remove bzip2
Updating database digests format: 100%
Checking integrity...  done (0 conflicting)
Deinstallation has been requested for the following 102 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        bluefish: 2.2.17_1
        bzip2: 1.0.8_1
        cairo: 1.18.2,3
        croscorefonts: 1.31.0_2
        dclock: 2.2.2_2
        dejavu: 2.37_3
        droid-fonts-ttf: 20131024_5
        feh: 3.11.2
        ffmpeg: 6.1.2_16,1
        firefox: 144.0_2,2
        font-adobe-100dpi: 1.0.3_4
        font-adobe-75dpi: 1.0.3_4
        font-adobe-utopia-100dpi: 1.0.4_4
        font-adobe-utopia-75dpi: 1.0.4_4
        font-adobe-utopia-type1: 1.0.4_4
        font-arabic-misc: 1.0.3_4
        font-bh-100dpi: 1.0.3_4
        font-bh-75dpi: 1.0.3_4
        font-bh-lucidatypewriter-100dpi: 1.0.3_4
        font-bh-lucidatypewriter-75dpi: 1.0.3_4
        font-bh-ttf: 1.0.3_5
        font-bh-type1: 1.0.3_4
        font-bitstream-100dpi: 1.0.3_4
        font-bitstream-75dpi: 1.0.3_4
        font-bitstream-type1: 1.0.3_4
        font-cronyx-cyrillic: 1.0.3_4
        font-cursor-misc: 1.0.3_4
        font-daewoo-misc: 1.0.3_4
        font-dec-misc: 1.0.3_4
        font-ibm-type1: 1.0.3_4
        font-isas-misc: 1.0.3_4
        font-jis-misc: 1.0.3_4
        font-micro-misc: 1.0.3_4
        font-misc-cyrillic: 1.0.3_4
        font-misc-ethiopic: 1.0.4
        font-misc-meltho: 1.0.3_5
        font-misc-misc: 1.1.2_4
        font-mutt-misc: 1.0.3_4
        font-schumacher-misc: 1.1.2_4
        font-screen-cyrillic: 1.0.4_4
        font-sony-misc: 1.0.3_4
        font-sun-misc: 1.0.3_4
        font-winitzki-cyrillic: 1.0.3_4
        font-xfree86-type1: 1.0.4_4
        fontconfig: 2.15.0_3,1
        freetype2: 2.14.1
        fvwm3-dev: g20250224
        gstreamer1-plugins: 1.26.6
        gtk3: 3.24.51
        gucharmap: 17.0.0
        harfbuzz: 10.3.0
        imlib2: 1.12.5_1,2
        libXfont2: 2.0.6
        libXft: 2.3.8
        libass: 0.17.4
        libheif: 1.19.8_3
        librsvg2-rust: 2.60.0_6
        libspice-server: 0.16.0
        luanti-dev: g20251021
        mkfontscale: 1.2.3
        pango: 1.56.4
        sdl2_ttf: 2.24.0
        spleen-font: 2.1.0
        x11perf: 1.6.1_1
        xcalc: 1.1.2_1
        xclock: 1.0.9_1
        xlibre: 0.1
        xlibre-drivers: 0.1
        xlibre-ephyr: 25.0.0.12
        xlibre-nest: 25.0.0.12
        xlibre-server: 25.0.0.12
        xlibre-vfb: 25.0.0.12
        xlibre-xf86-input-elographics: 1.4.4.2
        xlibre-xf86-input-evdev: 2.11.0.2
        xlibre-xf86-input-joystick: 1.6.4.1_1
        xlibre-xf86-input-keyboard: 2.1.0.2
        xlibre-xf86-input-libinput: 1.5.1.0
        xlibre-xf86-input-mouse: 1.9.5.2
        xlibre-xf86-input-synaptics: 1.10.0.2
        xlibre-xf86-input-vmmouse: 13.2.0.2_1
        xlibre-xf86-input-void: 1.4.2.2
        xlibre-xf86-input-wacom: 1.2.3.2
        xlibre-xf86-video-amdgpu: 23.0.0.5
        xlibre-xf86-video-ast: 1.2.0.1
        xlibre-xf86-video-ati: 22.0.0.3
        xlibre-xf86-video-dummy: 0.4.1.2
        xlibre-xf86-video-intel: 3.0.0.4
        xlibre-xf86-video-mga: 2.1.0.1_1
        xlibre-xf86-video-nv: 2.1.23.1_1
        xlibre-xf86-video-qxl: 0.1.6.2
        xlibre-xf86-video-vesa: 2.6.0.3_1
        xlibre-xf86-video-vmware: 13.4.0.3
        xorg-apps: 7.7_4
        xorg-fonts: 7.7_1
        xorg-fonts-100dpi: 7.7
        xorg-fonts-75dpi: 7.7
        xorg-fonts-cyrillic: 7.7
        xorg-fonts-miscbitmaps: 7.7
        xorg-fonts-truetype: 7.7_1
        xorg-fonts-type1: 7.7
        xorg-libraries: 7.7_6
        xterm: 402

Number of packages to be removed: 102

The operation will free 631 MiB.

Proceed with deinstalling packages? [y/N]: n

After a substantial build process, I am finally at the last test to prove this update was completely 100% successful.  First I will test simply leaving FVWM3 and doing a startx again, after that, I will try a reboot and see if it still works.  An exit from FVWM3 and return worked fine but surely anything that might be broken or missing is still functioning from memory, so thats why the reboot is ultimate proof, and possible prelude to attempting to fix whatever didn't work correctly.

It turned out that things mostly worked again except that once more, without reinstalling graphics/drm-kmod, the graphics were using the vesa driver.  My attempt to correct this should have been simple but I managed to fall off the map and into trouble.  I couldn't manage to get graphics to work properly, and even succeeded to break them more.  I ran into the same issue as I did long ago, with amdgpu_picasso_gpu_info_bin.ko somehow in conflict or not found.  I know that this was due to me trying graphics/drm-latest-kmod.  I eventually removed everything in /boot/modules but then couldn't figure out how to repopulate it with all of the assorted files including amdgpu_picasso_gpu_info_bin.ko.  Removing graphics/drm-latest-kmod and installing graphics/drm-kmod didn't fix the missing files, and neither did graphics/gpu-firmware-kmod, although I believe that really should have been the proper fix.

I knew how to cure my situation, again.  Remove it all and start over.  The same way I did before with pkg delete -a -f and piece by piece reinstall all the parts so that when I rebooted, I was finally greeted with my configured rather tiny text right before the login prompt instead of a fatal error panic reboot.  My problems with the update of xlibre-ports was not the fault of xlibre-ports, but it was I am fairly certain, simply my missteps afterwards, when trying to get the missing drm-kmod installed so that my amdgpu would be used.

Weird buildworld failure

Recently I ran into an unexpected issue when attempting to rebuild and reinstall world and kernel.  I was doing this to try to figure out why another install of xlibre was dropping me into VESA.  I'll spoil that cliffhanger to say that for whatever reason graphics/drm-kmod is not installed in that process and so my AMDGPU driver doesn't get used.  It is for the user to add graphics/drm-kmod even with xorg, not sure how this couldn't be automated in any way.  I cannot say why missing drm-kmod wasn't an issue before except if there was an update at xlibre-server upstream which is entirely possible, or very mysteriously it remained installed.  The output of the error-aborted buildworld is below.

root@ichigo:/usr/src # make -j `sysctl -n hw.ncpu` buildworld && make -j `sysctl -n hw.ncpu` kernel KERNCONF=ICHIGO KERNCONFDIR /root/kernconf/ && echo "go to singleuser"
--- buildworld ---
make[1]: /usr/src/Makefile.inc1:362: SYSTEM_COMPILER: Determined that CC=/usr/local/bin/ccache cc matches the source tree.   Not bootstrapping a cross-compiler.
make[1]: /usr/src/Makefile.inc1:367: SYSTEM_LINKER: Determined that LD=ld matches the source tree.   Not bootstrapping a cross-linker.
--- buildworld_prologue ---
--------------------------------------------------------------
>>> World build started on Sat Oct  4 21:19:21 CDT 2025
--------------------------------------------------------------
--- _cleanworldtmp ---
>>> Deleting stale files in build tree...
ld-elf.so.1: Shared object "libutil.so.9" not found, required by "env"
        0.00 real         0.00 user         0.00 sys
*** [_cleanworldtmp] Error code 1

make[1]: stopped making "buildworld" in /usr/src
make[1]: 1 error

make[1]: stopped making "buildworld" in /usr/src

make: stopped making "buildworld" in /usr/src

I had searched online for the issue but once more nothing pertinent appeared, or things that may have been vaguely pertinent were horribly outdated.  When I returned once more, after a few further updates via git to /usr/src, just to be sure that wasn't somehow the issue.  On a whim I checked to see if Grok might point me in any direction that could help me solve it.  I gave it a query: "How can I update world and kernel on FreeBSD 15-stable if it fails because libutil is missing?" and part of the answer is below, it seems to have searched 40 urls, 10 of them from reddit, part from freebsd forums and handbooks.

Step-by-Step Fix

Follow these steps to clean up and rebuild. This resolves most libutil-related failures by ensuring a consistent build tree.

1. Update Source Tree
Fetch the latest 15-STABLE sources to ensure you're building against current code:  

cd /usr/src
git pull  # If using Git (recommended; init with `git clone https://git.FreeBSD.org/src.git` if needed)
# Or, if using SVN (legacy): svn update

2. Clean Build Artifacts
Remove stale object directories and temporary files that could reference old libutil versions:  

rm -rf /usr/obj/*
cd /usr/src
make clean  # Cleans world build remnants

3. Check and Clean Installed Headers/Libraries (If Mismatched)
If /usr/include has mixed dates (e.g., old headers conflicting with new kernel), back it up and reinstall base headers:  

mv /usr/include /usr/include.old  # Backup
make -C /usr/src/etc/ maketmpenv  # Recreates /usr/include from source

4. Verify libutil header: ls /usr/include/libutil.h (should exist post-this step).
If /lib/libutil.so.9 is missing or broken:  

ls -l /lib/libutil.so*  # Should show libutil.so.9 -> libutil.so.9.x

The first step I had already done.  The second step I immediately followed with the next ones.  I was able to rename the /usr/include directory but maketmpenv doesn't seem to exist any longer which points to how AI (like Grok) is not always 100% accurate and its results should always be checked or verified.  After I tried having it build within /usr/src/etc and it failed after a little built, I tried buildworld again which also didn't work yet, and so did a cleanworld.  Of course I had to put things back as they were originally, so renamed /usr/include.old since the step after that couldn't create the fresh /usr/include.  With it all back as it should be, I tried buildworld again and it iterated through all the needed things to build, building as it went.

rm -rf /usr/obj/*
root@ichigo:/usr/src # make clean
mv /usr/include /usr/include.old
make -C /usr/src/etc/ maketmpenv
cd /usr/src/etc
make
cd /usr/src
make -j `sysctl -n hw.ncpu` buildworld && make -j `sysctl -n hw.ncpu` kernel KERNCONF=ICHIGO KERNCONFDIR /root/kernconf/ && echo "go to singleuser"
mv /usr/include.old /usr/include
make cleanworld
make -j `sysctl -n hw.ncpu` buildworld && make -j `sysctl -n hw.ncpu` kernel KERNCONF=ICHIGO KERNCONFDIR /root/kernconf/ && echo "go to singleuser"

Now that it seems everything is working, I should have tried buildworld after the rm -rf /usr/obj/* because that seems to have been likely what cured the weird state my build environment had.  Perhaps something in the newer build routine for 15-stable allowed things to remain in a condition that would not allow me to immediately buildworld as I had been doing so many times in the past.  I recall some old instructions, I believe from back when I was using or playing with PC-BSD, that included cleaning up /usr/obj/ before a fresh buildworld and buildkernel.  I always end with delete-old and delete-old-libs but do I then also remove /usr/obj?  I suspect that this is a step directly before building so that is where it will go.  It looks like I will have to add that step into my normal routine just to be sure, so that future attempts will not leave me with an error like Shared object "libutil.so.9" not found again in the future.

Had I not known, recalled that cleaning of /usr/obj/ as a step of the build process, I would not have recognized it was the cure.  Something like Grok could help spur an idea for a solution, it may give avenues to investigate and research, but be wary that it is pattern matching software and truly doesn't know like a human might.  An AI may very well give old advice, as we note it mentioned the legacy SVN.  I'll be adding more things to distilled and adjusting the buildworld + kernel updating info and probably blog posts as well.

There was also a situation where etcupdate needed to have an mtree change reconciled, but since I do not modify that myself and I am not a dev with any reason for it to be anything but vanilla, I just told it to accept 'their version' of the file.  The odd part was that etcupdate first gave me options that were not helpful because I did not understand what I was seeing, nor how that mtree file should look, so my choice of diff had to be cancelled.  Right after, I noticed there were other commands not immediately listed, one of them was reconcile and gave its options.  When I tried to resolve instead, it wouldn't take the command with 'theirs' as the option, so I had to exit etcupdate entirely, and when I retried etcupdate resolve with tf it worked properly.  I am not sure what this affected, of course it cured the conflict, aside from any future etcupdate attempt functioning properly and completely, not prevented by a needed though not initiated resolve.  Somehow I thought it said 'reconcile' somewhere in that tool's interaction but I cannot find proof of that now.  According to the man 8 etcupdate

   Resolve Mode
     The resolve mode is used to resolve any conflicts encountered during a
     merge.  In this mode, etcupdate iterates over any existing conflicts
     prompting the user for actions to take on each conflicted file.  For each
     file, the following actions are available:

     (p) postpone      Ignore this conflict for now.
     (df) diff-full    Show all changes made to the merged file as a unified
                       diff.
     (e) edit          Change the merged file in an editor.
     (r) resolved      Install the merged version of the file into the
                       destination directory.
     (mf) mine-full    Use the version of the file in the destination
                       directory and ignore any changes made to the file in
                       the “current” tree.
     (tf) theirs-full  Use the version of the file from the “current” tree and
                       discard any local changes made to the file.
     (h) help          Display the list of commands.

This is not the first time that etcupdate had to correct something before other steps would succeed.  I am not sure how I could have missed that that previous installworld had a conflict and I passed that step seeming to succeed with a whole install.  I also have no idea what the change to that mtree file was or how it could affect anything itself.  How do I make certain that such a step is not missed?  Maybe I was tired or distracted and that caused me not to see it, so I need to do a buildworld and new kernel install when I am not sleepy and when I can focus.  The /usr/obj/ clean issue is an easy fix, just add it to steps taken when preparing to rebuild world.

I wish I could say that each of these missteps makes me less likely to repeat them, that I will learn and remember what I learned and correct things for all successive efforts.  I do my best to keep track of what I do and since writing this blog I have some notes in that form I can reference.  Surely even if I repeat a mistake, those who read of my trials will have the smallest chance to make my mistakes and will instead avoid them.

xlibre done right

A reply to my post on X about xlibre lead me to decide to test it once more.  Since I went through the process of starting from nothing to get xorg working, maybe this is what I needed to do to get xlibre working.  Could it possibly be that unknown remnants of xorg conflicted in unforseen ways with the xlibre parts I installed?  Might the mish mosh of software have caused my difficulties?

The only way I would find out is to go through a familiar process, but this time, instead of restoring xorg as my GUI, I would be installing xlibre.  The first step like previously, is to remove everything and I chose to remove pkg itself too.  After I did pkg delete -a -f I realized that I forgot to first update the xlibre repo if it was needed, but git was removed with everything else and shortly after firefox died as well.  I shifted out of the likely unstable potentially suddenly exiting fvwm3 instance to work on the commandline.

Luckily I still had access to the xlibre-ports git repo via my little sony music player android device.  I looked at the instructions and since I already had a possibly non-updated repo, I could still use it to prove if my suspicions or postulated theory were true.  I changed into the xlibre-ports directory and issued make clean, and then make install.  This time I just let everything install to see what it would actually do.

The long process of building from source was interrupted by a conflict between lang/py311-cython3-3.1.3 and an already installed older version of the same thing.  I cured this by simply doing pkg remove py311-cython and the older version was no longer a conflict.  I resumed the long build process until xlibre-xf86-video-qxl failed to build.  Since I have no idea what qxl is used for and I know I have never used it, I chose to try hiding the directory in xlibre-ports/x11-drivers in a new directory there named .hid and then resumed the building.  The script or process attempted to return to the qxl driver build but gave a message about it being "nonexistent" and then went to the next driver, and eventually finished.

I couldn't startx because x11/xinit was not installed, and I knew that of course that wouldn't help much if I didn't have a number of other things installed.  I added fvwm3 and xterm, and chose to try to startx.  As a precaution, before I even began the rebuild, I made sure to swap my scfb optimized .fvwm/local.config.scfb file in the last lines of the .fvwm/config by commenting out the .fvwm/local.config line and also editing the .Xresources file to modify for Xft.dpi: 64 just in case it helped a possibly bad (low) resolution desktop.  When I did start X, I was pleasantly surprised, aside from those adjustments for the possible vesa desktop making some things extra small.  I had an xlibre GUI with fvwm3 running and it was working.  My next steps were to pkg install the missing items: feh, dclock, umix, bluefish, firefox.

Starting firefox gave a weird error about not finding fonts, which was something I had never seen as a problem before.  Surely I normally had plenty of fonts installed.  Bluefish also started up in an odd fashion, but after I rebuilt my local repo of luanti, whatever bluefish needed was satisfied and maybe firefox would have been also were I not trying to build it from source to solve that font issue.  I doubt that a from source build of firefox would have cured it but it was the solution I immediately jumped toward.  It turned out that firefox could not finish building due to a strange error, so I reinstalled it via pkg and as I thought earlier, it now worked fine.

It seems that the moral to a story in three parts (the whole experience I wrote on this blog, prior posts and this one) is to start fresh when trying or switching to xlibre.  This could be done by removing everything using pkg the way I did, maybe best first to set a snapshot in zfs which I did not do, or to use a clean jail and figure out how to access or run xlibre from it.  Beware unknowingly mixing xorg and xlibre software because it seems that you may get rather unexpected unknowable results instead of what one may believe should be a smooth transition from one to the next.

Since everything seems to be working fine, I do not plan to go through the long process of switching back to using xorg.  I will remain a user of xlibre until I have a strong and compelling reason to clean the slate and start over again, whether that is xlibre refreshed or xorg with all of its unmaintained "glory" once more.  I think I like the idea of xlibre, just as I like the idea of neovim, both are substantial cleanups (or will be) and properly supported instead of languishing and buggy.

Broke GUI recovery

Recently I tested xlibre on my system without a safety net which tends to be my usual method.  As mentioned in the previous blog post, I was stuck again using scfb because of unknown reasons.  After many attempts to reinstall rebuilt ports or reinstall pkgs that I knew would be necessary to help me back to a usable GUI on a 4k screen, I gave up.  I wasn't making any progress, and even desktop-installer was no help this time, so I chose to start from nothing instead.  I issued pkg delete -a -f and then tried pkg info to prove that nothing lingered.  This was when pkg reminded me that it was removed also and needed to be bootstrapped back into the system.  This was easy, just had to answer 'y' to the prompt.

Many of my troubles are self-inflicted but some are due to various other things I may encounter though I do not know whether its unique to my situation.  I have in the past encountered issues with various things except that because of how I may be non-standard or do not always use the accepted official way to do things, I cannot report them.  All of this means that when I get myself into trouble, when I break my system softwarewise, I will need to find my own way out of the forest, rarely are any easy breadcrumbs scattered on the ground.

Since I have been through this a few times, although on my newer box which means many files I created with lists of things and other stuff are not present.  Those are possibly still on my former at present 'software + filesystem' broken system.  I know even from recent posts which things I need to reinstall.  What I didn't know about these things is all the stuff that each one installs as dependencies, so starting from nothing will look different than the reinstalls I did not long ago.

First was graphics/mesa-dri which gave me graphics/mesa-libs and graphics/libdrm which had been seperate steps in the past, now I know that was redundant.  Along with those I got graphics/libglvnd and graphics/glslang as well as a long list of things.

devel/autoconf
devel/autoconf-switch
devel/automake
devel/binutils
devel/bison
devel/bsddialog
security/ca_root_nss
devel/ccache
devel/cmake-core
sysutils/coreutils
textproc/expat2
devel/gettext-runtime
devel/gettext-tools
graphics/glslang
devel/gmake
math/gmp
misc/help2man
sysutils/htop
misc/hwdata
print/indexinfo
devel/jsoncpp
x11/libX11
x11/libXau
x11/libXdamage
x11/libXdmcp
x11/libXext
x11/libXfixes
x11/libXrandr
x11/libXrender
x11/libXv
x11/libXxf86vm
graphics/libdrm
devel/libedit
devel/libffi
graphics/libglvnd
converters/libiconv
dns/libidn2
archivers/liblz4
devel/libpciaccess
devel/libtextstyle
devel/libtool
devel/libunistring
devel/libuv
x11/libxcb
textproc/libxml2
x11/libxshmfence
textproc/libyaml
devel/llvm19
lang/lua53
lang/lua54
devel/m4
graphics/mesa-dri
graphics/mesa-libs
devel/meson
math/mpdecimal
math/mpfr
devel/ninja
security/openssl
devel/p5-Locale-gettext
devel/p5-Locale-libintl
converters/p5-Text-Unidecode
textproc/p5-Unicode-EastAsianWidth
devel/pcre2
lang/perl5.42
ports-mgmt/pkg
devel/pkgconf
ports-mgmt/portconfig
devel/py-babel
textproc/py-CommonMark
devel/py-Jinja2
textproc/py-alabaster
www/py-beaker
devel/py-build
devel/py-calver
security/py-certifi
textproc/py-charset-normalizer
lang/cython
textproc/py-docutils
devel/py-flit-core
devel/py-future
devel/py-hatchling
dns/py-idna
graphics/py-imagesize
devel/py-installer
textproc/py-mako
textproc/py-markdown
textproc/py-markdown-it-py
textproc/py-markupsafe
textproc/py-mdit-py-plugins
textproc/py-mdurl
textproc/py-myst-parser
devel/py-packaging
devel/py-pathspec
misc/py-pexpect
devel/py-pluggy
devel/py-ply
sysutils/py-ptyprocess
textproc/py-pygments
devel/py-pyproject-hooks
net/py-pysocks
textproc/py-pystemmer
devel/py-pyyaml
textproc/py-recommonmark
www/py-requests
devel/py-setuptools
devel/py-setuptools-scm
textproc/py-snowballstemmer
textproc/py-sphinx
textproc/py-sphinx-markdown-tables
textproc/py-sphinxcontrib-applehelp
textproc/py-sphinxcontrib-devhelp
textproc/py-sphinxcontrib-htmlhelp
textproc/py-sphinxcontrib-jsmath
textproc/py-sphinxcontrib-qthelp
textproc/py-sphinxcontrib-serializinghtml
devel/py-trove-classifiers
devel/py-typing-extensions
net/py-urllib3
devel/py-wheel
devel/py-wheel044
lang/python311
devel/readline
security/rhash
graphics/spirv-tools
devel/swig
print/texinfo
x11/xcb-proto
devel/xorg-macros
x11/xorgproto
x11/xtrans
archivers/zstd

After all of that was built and installed and cleaned, I went to the next essential item, graphics/drm-kmod which gave me all of the amd, intel, and radeon kmod files but pkg origin which was how I got these lists after the fact did not show the specifics of the numerous chipset names.  No sense listing those multiple duplicates here though they were actually different at install.

graphics/drm-66-kmod
graphics/drm-kmod
graphics/gpu-firmware-amd-kmod
graphics/gpu-firmware-intel-kmod
graphics/gpu-firmware-kmod
graphics/gpu-firmware-radeon-kmod

Next I should have been smarter about it but since graphics was my main issue previously, I was too focused on that aspect not to also focus solely on installing the amdgpu graphics driver.  Later I installed the x11-drivers/xorg-drivers after configuring it for what I specifically needed, a pkg install would include scfb and vesa and maybe intel drivers, all of which I do not want, do not use, and generally do not need.  So as I have mentioned before, I build xorg-drivers from source each time.  The one interesting thing about starting from very little already installed, is that xorg-drivers/xf86-video-amdgpu also installs xorg-server.  I hadn't noticed my error about not installing all the other drivers until after I got fvwm3 reinstalled, but the list from the xorg-drivers install is below, not quite in the pkg origin order it would have given.

archivers/brotli
devel/evdev-proto
print/freetype2
x11-fonts/libXfont2
x11/libXi
graphics/libepoxy
x11-fonts/libfontenc
security/libgcrypt
security/libgpg-error
devel/libudev-devd
devel/libunwind
x11/libxcvt
x11/libxkbfile
textproc/libxslt
x11/pixman
graphics/png
x11-drivers/xf86-video-amdgpu
x11/xkbcomp
x11/xkeyboard-config
x11-servers/xorg-server
x11/libXxf86vm
x11-drivers/xf86-input-keyboard
x11-drivers/xf86-input-libinput
x11-drivers/xf86-input-mouse

One note about the x11-drivers/xf86-input-libinput driver option, it leads to libinput whose config is to avoid the checked by default wacom option which also may lead to webcamd, I do not need either of those.  Except for that, I mostly chose to accept all defaults.  After I installed the amdgpu driver I chose to install x11/xinit which is where I get startx for later use.  The last thing I needed to get a usable desktop was x11-wm/fvwm3 and I generally use the much more recent fvwm3-dev which I keep updated on my own.  What I forgot again was that I did not have x11/xterm installed and this is not added by fvwm3, so at the time I had to reset my pc to exit the gui because I only had the graphics driver installed (though I present it not in this order above).  When I noticed xterm was needed after I added the input drivers, I still had to exit fvwm3 but could use the menu option.

Once I had xterm installed and was back in fvwm3, I could add the other missing items, feh, gkrellm2, umix, bluefish, and firefox.  A few things had an issue with cython installing as a dependency, so to save time, I installed them by pkg even though I keep my own feh-dev updated somewhat regularly.  Many things were still configured for the much smaller screen scfb would permit me to use, so I may want to adjust some of that, but aside from other things I may realize are not present I am done with recovery from my non-recommended xlibre test method.

Now a recap for the recovery from nothing, because these notes are more likely to remain than any hand-written paper.  Below includes a few configurations and a proper ordering of steps.  Note that any desktop environment such as KDE or similar is very extensive and may have a lot of the below as dependencies itself.

 1. pkg delete -a or pkg delete -a -f which will also remove pkg itself.
 2. make install clean for each of the following port origins, or pkg install if you like all defaults.
 3. graphics/mesa-dri provides mesa-libs, libdrm, libglvnd, glslang
 4. graphics/drm-kmod provides gpu-firmware-amd-kmod, gpu-firmware-kmod
 5. Configure x11-drivers/xorg-drivers for amdgpu (your preferred graphics driver), keyboard, libinput, mouse
 6. Configure x11/libinput to untick libwacom
 7. x11-drivers/xorg-drivers provides configured drivers and x11-servers/xorg-server
 8. x11/xinit provides startx
 9. x11/xterm
10. x11-wm/fvwm3 (your preferred mininmalist window manager)
11. startx

xlibre for a moment

It took some effort for me to get xlibre functional for myself, and with a few caveats.  My first attempt failed because I forgot to deinstall or pkg remove the former xorg-server and xf86-drivers.  Once I had all the old things removed, I was able to mostly install xlibre.  The trouble with how things in the github readme describe the process is that by following it, you will have everything installed.  There is also the small flaw with the git clone command provided, it should be "git clone https://github.com/b-aaz/xlibre-ports.git" instead.  I cloned the xlibre-ports repo and did a merge request to correct it.  As far as the remaining instructions, I mean that regardless of how you may choose to configure each sub-group for what it might install, the meta install will not honor it.  I could have suffered through this long process of installing everything, installing things I would never need, except that a dependency for one of the esoteric video drivers failed to install.

My solution was to ignore the meta installer, to go through those sub groups instead one by one, individual by individual as needed, in order for me to get the whole set of essential ports built and installed.  After I finally was sure that I had installed everything, I quit my session of FVWM3 and started it back up.  It seemed like everything was working but to be sure, I rebooted, got back to a shell prompt and tried to startx.  I shouldn't have been too surprised when it failed, but instead of the issues I had when I first switched to 15-stable, it turned out to be that the amdgpu driver was unable to load or with it X was unable to find a screen.

Back to the old standby I suffered recently, scfb? Actually no, because it has not been adjusted in whatever arcane ways to make it function with xlibre.  I am now, until I choose to revert to xorg-server and not use xlibre, stuck with the even worse vesa driver.  I am at present editing this post with bluefish after doing as much as I could to get many things adapted to the dpi vesa permits.  Even after that effort, bluefish seems to have a minimum window size or I didn't discover how to squeeze it into the screen I am allowed.

When I investigated the amdgpu driver situation, I found that when I was using xorg-server, the driver was 22.0.2 but the xlibre amdgpu driver is 22.0.1 and I expect that the slightly updated version would solve my issue.  Since it seems like the xlibre driver must be obtained from the xlibre-drivers repo, I cannot simply swap from one to the other with a small edit, as far as I know.  For now it looks like I will be revisiting xlibre at a later date when I might have noticed the amdgpu driver modified for it is updated.  The vesa driver is also much too slow to use for the one game I play most frequently, so that is another reason to go back to xorg-server for the time being.

Since that editing session, my blog post was saved in bluefish, I reverted to xorg-server, and tried many times to get the amdgpu driver to be used.  I am baffled at the moment about what is wrong but surely I will eventually solve the issue.  Regardless, I am now back to xorg and using the scfb driver.  My various adjustments to attempt to make the desktop fit everything while using the vesa driver now permit things to fit quite nicely with scfb.  I look forward to hearing more about xlibre and its future commits, future updates, and will be watching the xlibre-ports repo somewhat closely.

---

I've realized after publishing the above, that if this blog post were taken by itself, you may not know that I use the -stable branch shortly after it is cut from -current, and this means I am using 15-stable right now.  On my present box I have mostly tried to use just pkgs but when the one-size-fits-most defaults conflict with my desires, I build my own from ports, especially xorg-drivers.  My post about scfb shows that I generally avoid it, since oddly it will deny the amdgpu driver from being used.  I try to keep very current on a number of things in my github repos, particularly luanti and fvwm, but also feh and flameshot.  My system has an AMD Ryzen 3 3200G with Radeon Vega Graphics (3800.08-MHz K8-class CPU) and 128GiB RAM.

Stuck with scfb

What an unusual change, that once I did my best to keep the scfb driver uninstalled and now I have to use it.  I recently upgraded my system from 14-stable to the newly available 15-stable.  The usual process of updating src via git had a small hiccup due to a missing update to the blog post I perused.  The minor detail I missed was that git switched to using https and that was what stopped the /usr/src update.  All my blog posts now mention that git change where I had described the old method.  The update was quick and building kernel and world went smoothly as expected.

When I was booted into the 15-stable kernel with world, I knew I had a lot of adjusting to do with regard to installed software or any other changes.  I had saw an easy way to handle the task somewhere online.  What I did was pkg upgrade -f right after I used gitup ports to update the ports tree.  What I didn't know was that pkg was missing or not in a working state, so I had to do pkg bootstrap -f and after I did the pkg upgrade -f, I expected most things to just work.

You can make an educated guess that of course things did not work as expected or hoped.  When I tried to start the X server so I could get back to using my pc as normal, it failed, some errors that seemed to be related to a mismatch with the kernel.  I figured I could get past this issue by being certain to build locally with my updated ports tree.  I rebuilt graphics/mesa-dri which pulled in graphics/libdrm (and I believe graphics/mesa-libs which makes sense), next I rebuilt graphics/drm-kmod which also provided gpu-firmware-kmod, after that was x11-drivers/xf86-video-amdgpu, next was x11-servers/xorg-server, and finally x11/xinit.  I believed I had everything remade compatible with 15-stable and so I tried to start X again.

I must have assumed that I needed to reboot to have everything load properly, but this simply made me reboot a second time into single user so I could remove all the graphics stuff.  Only after the graphics drivers were not trying to load could I boot into text only.

With all that I rebuilt, it gave an error that seemed to be a conflict between drivers?  In the /var/log/Xorg.0.log file it seemed to load a raven driver and then picasso, but it couldn't find the amdgpu_picasso_gpu_info_bin file.  No matter how many times I repeated the rebuild process to be sure I hadn't made any mistakes, I got the same result.  The only way I could succeed to boot was to make sure the graphics was uninstalled, and usually I had to do that via single user.

With too many attempts already made, I remembered that there was the vesa driver which could work, and also the scfb driver I could try.  I installed vesa first and tested it to see an unusable former 4k desktop squeezed into 640 x 480, everything huge on my 4k monitor.  I didn't have mouse, so I couldn't exit fvwm or use an xterm to do anything, but I believe an alternate virtual tty was accessible, and I killed it from there.  Next was the scfb driver which had always wanted to get in the way of the amdgpu driver in the past.  When I got into X again, it was still quite large but much more usable.  I also cured the mouse issue by building the mouse driver which was mysteriously missing.

I have during and since been searching for any recent reports or information about this issue.  Most of the results are rather old, like 2019, or (of course) very Linux specific which does me no good, since their solutions are purely for that distro and its install methods.  I did see mention somewhere about a change to driver naming or something, I am very unclear on that.  That was in Linuxland, so if there was a change in that realm, we need to wait for it to be propagated into FreeBSD before maybe I will see a fix and get back to my amdgpu driver with 4k.  I don't believe there is anything more I can do besides wait, but I will likely keep trying to get away from scfb.

UPDATE:

That was pleasantly fast.  I suffered with graphics being broken and forced into second class scfb for my driver for only two or three days.  Moments after posting the above, I went to /usr/local/etc/pkg/repos to edit the FreeBSD.conf file to disable FreeBSD-ports-kmods, and then upgraded pkg and updated, and after all the drivers were reinstalled, I have my 4k back.  While I watched the update listing, it showed those graphics drivers did indeed all get updated to a more recent version.  I cannot say whether there was a problem in the drivers or if any file was missing, or if strangely those kmod files were not pulled from FreeBSD-ports-kmods repo if that happened before.  All that I can say right now is that my experience with the situation and my suffering scfb for a short time was documented above.  How ever things got corrected, I am grateful for the work by those involved.

Remote poudriere build

What I had forgot to include in a previous blog post was how I managed to successfully setup poudriere on atlas for use with remote package serving to ichigo.  I initially followed a Vermaden blog post Simple FreeBSD poudriere harvester guide which helped me get the majority of the setup configured, adjusted.  I attempted to leave a comment on the blog post but for whatever reason it failed, so I am going to provide that here as well.  The process is not difficult but there is at least one detail left out which could be discernable to some but it took a little for me to discover.

Vermaden does a very good job for the community to provide insights and guides and is part why I chose to write my own blog as well, beginning years ago.  It became obvious to me that writing about my experiences on FreeBSD would help me to remember and help others to find their way more easily.  I would recommend to any FreeBSD user to do the same for at least the same or similar reasons, it may seem a no-brainer.

The essentials of Vermaden's blog which I needed were as follows:

Adjust the rc.conf (or rc.conf.local) file to include:

  sshd_enable=YES
  nginx_enable=YES

Those lines will permit a web browser such as firefox to view the progress and results of the current poudriere bulk build, and permit ssh including access to X windows applications via ssh -X and sftp for any LAN file transfer needs.

Add needed packages:

  poudriere
  nginx
  git-lite

Although when I read the blog post I believe I already had those installed and some other things he mentions.

The most important step that I needed was for the pkg signing which is a series of steps, each command as root:

# mkdir -p   /usr/local/etc/ssl/keys /usr/local/etc/ssl/certs /usr/ports/distfiles
# chmod 0600 /usr/local/etc/ssl/keys
# openssl genrsa -out /usr/local/etc/ssl/keys/poudriere.key 4096
# openssl rsa -in /usr/local/etc/ssl/keys/poudriere.key -pubout -out /usr/local/etc/ssl/certs/poudriere.cert

I wasn't sure that mkdir would create multiple paths in one command, and I already had /usr/ports/distfiles, so I did them individually but testing a moment ago I now know I could have just copied that line entirely.  Those steps above are perfect for the poudriere build machine but a detail that is essential here which can be done now or anytime before trying to use the signed pkgs, is to copy the /usr/local/etc/ssl/certs/poudriere.cert to the client box(es).  This is one thing that is missing and tripped me up, surely it is assumed and obvious but not to me right then.

Since I already had poudriere running previously for use on the same machine, a poudriere.conf already existed.  I edited the file to be sure to add and revise as needed the lines he provided:

  ZPOOL=zroot
  BASEFS=/usr/local/poudriere
  ZROOTFS=/dev/null
 #FREEBSD_HOST=ftp://ftp.freebsd.org
  POUDRIERE_DATA=/usr/local/poudriere/data
  CHECK_CHANGED_OPTIONS=verbose
  CHECK_CHANGED_DEPS=yes
  PKG_REPO_SIGNING_KEY=/usr/local/etc/ssl/keys/poudriere.key
  URL_BASE=http://172.16.0.12
  USE_TMPFS=all
  TMPFS_LIMIT=5
  MAX_MEMORY=4
  MAX_FILES=2048
  DISTFILES_CACHE=/usr/ports/distfiles
  KEEP_OLD_PACKAGES=yes
  KEEP_OLD_PACKAGES_COUNT=2
  CHECK_CHANGED_OPTIONS=verbose
  CHECK_CHANGED_DEPS=yes
  CCACHE_DIR=/var/cache/ccache
  RESTRICT_NETWORKING=yes
  

Since I use the same ports tree for the poudriere machine and also for poudriere, I did not create a seperate ports tree for it.  I also have the /etc/makeconf symbolic linked to /usr/local/etc/poudriere.d/make.conf because I want local things built to match what poudriere builds.  This way hopefully there is no difference but automation.

I setup nginx as described in Vermaden's blog post, possibly from a previous nginx poudriere progress view attempt, only needed to check it was accurate.  I have also had ccache setup for ages as well, so did not need to look at that much either.

One of the last steps in this whole process is to define the repos.  I had already setup poudriere.conf in /usr/local/etc/pkg/repos for the build machine to use the pkgs it makes, but I revised it to use the signature, the two lines were added.

poudriere: {
        url      : file:///usr/local/poudriere/data/packages/14amd64-default,
        signature_type: "pubkey",
        pubkey: "/usr/local/etc/ssl/certs/poudriere.cert",
        enabled  : yes,
        priority : 10
}

On the client machine, I needed a new pkg repo configuration file.

atlas: {
  url: "http://172.16.0.12/packages/14amd64-default",
  signature_type: "pubkey",
  pubkey: "/usr/local/etc/ssl/certs/poudriere.cert",
  enabled: yes,
  priority: 100
}

Since when I originally followed the instructions I missed placing a cert file on my client machine, this setup failed inexplicably.  I used pkg -v -v update -f to try to figure it out.  The results did not clearly say that I had no cert or that that was the issue, because something else was interfering.  I had pf setup on the poudriere build machine, and this halted the client from requesting anything, it literally silently failed, no explanation.  I probably had it in the back of my mind that pf could be the reason, so I eventually tried service pf stop and tried again, this time it was able to update the meta file and others.  Now was when it took a bit to figure out that I needed to copy the cert file to the client.  Once everything was in place, all I needed to remember was to periodically disable pf as needed.  I knew I could permanently cut a hole in pf for the pkg update or install requests but that was something for another time.