When I set out to update my system to use FreeBSD 14-stable in lieu of 13-stable, I knew there was a chance things could go awry. Usually a switch between major versions will involve substantial changes to how things are done and thus indirectly invalidate a large swath of (or everything) that is installed. I was ready for this task but first I had to get a running system to begin my other (userland) updates.
As usual, essentially the same way I've done many times, I updated my /usr/src to the most current 14-stable, and began the usual buildworld and kernel processes as described in another blog post,Kernel and world rebuild. Since this was going to be a new ball of wax instead of some minor tweaks of 13-stable, I wisely chose to install a GENERIC kernel.
What I was not so aware of, was how issues with etcupdate could thwart a complete update. After a couple attempts to rebuild and reinstall, I looked closer at etcupdate and what might possibly be the wrench in the works. This discussion of my kernel and world challenge is being written from memory as I didn't remember to take any notes to be more precise. What I recall is that I eventually clarified six or eight files so that they would match what was expected in the new system, etcupdate could then be satisfied (no more conflicts) and my usual process could be completed.
Aside from the etcupdate hiccup, the transformation from 13-stable to the new shiny 14-stable went rather smoothly and easily. Since I now had a fresh install, I could work on getting my userland (ports) updated and back to a functioning desktop. I now have a list of ports I need to re-install when I update my kernel and this along with a helpful script to iterate through each of them, would update anything needing the kernel and all the rest.
misc/pciids graphics/libdrm graphics/linux-c7-libdrm graphics/libglvnd graphics/libGLU graphics/gpu-firmware-amd-kmod x11/xorg graphics/mesa-libs graphics/mesa-dri graphics/drm-kmod devel/libudev-devd x11-drivers/xf86-input-mouse x11-drivers/xf86-input-keyboard
I had those ports rebuilt and reinstalled, and made sure that x11-wm/fvwm was installed as well. When I tried to startx it told me there were no screens detected, which is an obscure way to say that there is no graphics driver, or that is just one cause of the message. I tried to reinstall the few items I knew would affect this, and made sure to install graphics/gpu-firmware-amd-kmod because that is the hardware I have. I was still unable to issue startx and get my fvwm desktop back up. I figured that since I had trouble in the past and desktop-installer cured things before, I could use it now and get back a gui.
I recall there being a moment (but I am very uncertain where in the order of events) when I was unable to connect to the freebsd pkg repo, and I hadn't changed anything myself (directly, intentionally) so I looked online for some documentation about it. At that time I may have noticed that ports were no longer updating. Strangely, what had always worked was no longer functioning, I had to change my freebsd.conf to get that back.
This is my /usr/local/etc/pkg/repos/FreeBSD.conf with the former text all commented out with # characters, the working portion below.
# $FreeBSD$
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
# mkdir -p /usr/local/etc/pkg/repos
# echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#
#
#FreeBSD: {
# url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
# mirror_type: "srv",
# signature_type: "fingerprints",
# fingerprints: "/usr/share/keys/pkg",
# enabled: yes
# priority: 0
#}
FreeBSD: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
}
Since desktop-installer succeeded to set me up with SDDM and fluxbox, I had a GUI to work on the rest of my updates. I needed to figure out or disable SDDM and get fvwm going. At some point I noticed that graphics/drm-kmod had a way to auto choose the right port to install based upon the version of FreeBSD. The Makefile did not permit the newer version for 14-stable to be drm-515-kmod as it at that moment could only install drm-505-kmod.
I tried to get things updated using the file list mentioned earlier but kept running into problems until I happened to use graphics/gpu-firmware-kmod to install things instead of the more direct amdgpu in the list. Once I did this, both drm-505-kmod or drm-515-kmod worked fine. When I reinstalled that list, I kept thinking that maybe one thing in the list affected others, and maybe they do but repeated installs did not solve it.
So finally again I had a gui and everything seemed to be going the right direction. All it would take to bring things back to a broken state yet again is to update those ports. I liked the idea of sysutils/auto-admin and it mostly worked fine, aside from how it would insist to reinstall (from pkg) versions with one-size-fits-all default port configs. The more ridicules was ftp/curl which by removal caused auto-admin scripts themselves to fail.
Eventually I realized that if auto-admin wanted to deinstall ftp/curl and use bad defaults for it (I must have static for some other port) I could build it the way I need then lock it. This became the solution for a number of issues. Pango also needed the libthai option because firefox insisted upon it, so that was built and locked. Some time later, vlc was also affected by changed options, MAD being the only mp3 decoder available, so this too rebuilt and locked. I know ffmpeg and firefox were both eventually locked as well.
It seems that within the week or so that I rebuilt and reinstalled FreeBSD from 13-stable to now 14-stable, more things mysteriously broke and had to be fixed than usual. I do not know what to point to as the precise cause. Most if not all of these difficulties are within the realm of FreeBSD ports and not kernel or world related at all.
Somehow after updating fvwm3 to its most recent commit, what will be the next release version, I exited out to start the new version and couldn't get back. I was getting a very odd message related to some sort of X windows thing which at this moment I cannot recall. It was something like how it wasn't sure which amdgpu driver or definition or something to use. This was odd as when I looked at what I thought was pertinent, there was only one related to this. I think it was related to drivers again, or I assumed it was, so back to that list and reinstalling. I eventually added new things to the list after finally getting fvwm up again, mostly.
The trouble was, even though I had fvwm up, my mouse cursor was stuck at the center of the screen and things felt stalled, I think they *were* stalled. I tried reinstalling the mouse driver and then went back to desktop-installer for the essentials and hopefully a fix. Once more, desktop-installer cured the issue. I looked at what drivers were now installed and added more to the list.
x11/libXxf86dga x11/libXxf86vm x11-drivers/xf86-input-libinput x11/xf86dga x11/xmodmap
I believe now after desktop-installer saved me yet one more time, everything should be working and I would have no troubles. Except that I was wrong of course. Now I am unsure how but something with my keyboard configuration now lacked anything for arrow keys. After a lot of digging around I finally found how to fix them. What I didn't discover until in the process of writing this is that my delete key does not function (fixed in below list). I had to edit /usr/local/etc/Xmodmap to add some lines. Later with xmodmap -pke > ~/.Xmodmap I told xmodmap to copy the file to my home directory. Vermaden's blog post on FreeBSD desktop (part 9) was also useful to help me remember xev and its function, and some other things.
keycode 111 = 0xFF52 keycode 116 = 0xFF99 keycode 114 = 0xFF98 keycode 113 = 0xFF96 keycode 119 = BackSpace
I keep adding to my 'kernel rebuilt redo GUI' file list, at present this is the correct listing, missteps left out but vulkan stuff added just in case as it is an AMD card.
misc/pciids graphics/libdrm graphics/linux-c7-libdrm graphics/libglvnd graphics/libGLU graphics/gstreamer1-plugins-vulkan graphics/realesrgan-ncnn-vulkan graphics/realsr-ncnn-vulkan graphics/vapoursynth-waifu2x-ncnn-vulkan graphics/vulkan-caps-viewer graphics/vulkan-extension-layer graphics/vulkan-headers graphics/vulkan-loader graphics/vulkan-tools graphics/vulkan-validation-layers graphics/gpu-firmware-kmod x11/xorg graphics/mesa-libs graphics/mesa-dri graphics/drm-515-kmod devel/libudev-devd x11-drivers/xf86-input-mouse x11-drivers/xf86-input-keyboard x11/libXxf86dga x11/libXxf86vm x11-drivers/xf86-input-libinput x11-drivers/xf86-video-amdgpu x11/xf86dga x11/xmodmap
They always say what does not kill you makes you stronger, well, in the software/computer world it might be more like perseverence along with a little knowledge will always lead to a victory against those inanimate objects. There is definitely an aspect of the former saying, in that, the greater the struggle, the more extreme the frustration, surpassing both will lead to greater knowlege and understanding, but in a nutshell: just don't give up. Look for answers, look for help, embrace the puzzle.
Writing about our difficulties, successes, and failures, will help others who find the content. You too could start a FreeBSD blog.
