I recently looked over my custom kernel configuration file prior to updating kernel and world on Dec 5th 2024. I compared the kernconf I revised to GENERIC to see whether anything was new or changed. I noticed a bunch of extra space that I had included which I forget why, except that it was to match an older GENERIC or an prior kernconf. There were a few things missing which were present in GENERIC and I added those, using the same nomenclature as I had before.
I noticed that I was including a pile of compatibility shims for older versions of FreeBSD. I decided to revise this to exclude all but the last version, just in case. I had a comment in the file at the end which mentions an issue with building certain ports. Since the newer 14-stable was what I was building, I pared them down to just the 13, and I still hope to use 32bit wine, so I made sure to keep the i386 compatibility. My method (nomenclature) is to copy the GENERIC kernconf as a custom kernconf, keep used options in my custom kernconf but commented, and unused options prefixed with no. I described creating a customized kernel in another blog post.
#options COMPAT_FREEBSD32 # Compatible with i386 binaries nooptions COMPAT_FREEBSD4 # Compatible with FreeBSD4 nooptions COMPAT_FREEBSD5 # Compatible with FreeBSD5 nooptions COMPAT_FREEBSD6 # Compatible with FreeBSD6 nooptions COMPAT_FREEBSD7 # Compatible with FreeBSD7 nooptions COMPAT_FREEBSD9 # Compatible with FreeBSD9 nooptions COMPAT_FREEBSD10 # Compatible with FreeBSD10 nooptions COMPAT_FREEBSD11 # Compatible with FreeBSD11 nooptions COMPAT_FREEBSD12 # Compatible with FreeBSD12 #options COMPAT_FREEBSD13 # Compatible with FreeBSD13
Building world and kernel went fine. No issues, the etcupdate was silent, and I rebooted into the updated kernel and world without issue. I started up FVWM and noticed it felt faster already. I cannot say exactly why it felt faster, I believe it was mostly my imagination. Once I had my GUI of choice up, next is to return to my usual programs, firefox in particular. I used my configured gui option to startup firefox but in never appeared after multiple attempts. At this moment I believe firefox was present but would not start for an unknown reason. Without keeping any notes on the output I am sure I saw when I tried to start firefox from an xterm, I chose to reinstall firefox. It wasn't present in my local poudriere repository, so I guess it failed to build the last time, was removed due to some other update and the firefox rebuild failed as well. When I got set to rebuild firefox outside of poudriere, just in the ports tree, I discovered my mistake.
root@ichigo:/usr/home/tigersharke # cd /usr/ports/www/firefox
root@ichigo:/usr/ports/www/firefox # make reinstall
===> Deinstalling for firefox
===> firefox not installed, skipping
===> firefox-133.0_2,2 depends on package: nspr>=4.32 - found
===> firefox-133.0_2,2 depends on package: nss>=3.106 - found
===> firefox-133.0_2,2 depends on package: icu>=73.1 - found
===> firefox-133.0_2,2 depends on package: libevent>=2.1.8 - found
===> firefox-133.0_2,2 depends on package: harfbuzz>=10.0.1 - found
===> firefox-133.0_2,2 depends on package: graphite2>=1.3.14 - found
===> firefox-133.0_2,2 depends on package: png>=1.6.44 - found
===> firefox-133.0_2,2 depends on package: dav1d>=1.0.0 - found
===> firefox-133.0_2,2 depends on package: libvpx>=1.14.1 - found
===> firefox-133.0_2,2 depends on package: py311-sqlite3>0 - found
===> firefox-133.0_2,2 depends on package: v4l_compat>0 - found
===> firefox-133.0_2,2 depends on executable: autoconf2.13 - found
===> firefox-133.0_2,2 depends on executable: nasm - found
===> firefox-133.0_2,2 depends on executable: yasm - found
===> firefox-133.0_2,2 depends on executable: zip - found
===> firefox-133.0_2,2 depends on file: /usr/local/share/wasi-sysroot/lib/wasm32-wasi/libc++abi.a - found
===> firefox-133.0_2,2 depends on file: /usr/local/share/wasi-sysroot/lib/wasm32-wasi/libc.a - found
===> firefox-133.0_2,2 depends on package: wasi-compiler-rt17>0 - found
===> firefox-133.0_2,2 depends on package: rust-cbindgen>=0.26.0 - found
===> firefox-133.0_2,2 depends on package: rust>=1.83.0 - not found
===> Deinstalling for rust
===> rust not installed, skipping
===> rust-1.83.0 depends on file: /usr/local/bin/cmake - found
===> rust-1.83.0 depends on executable: ninja - found
===> rust-1.83.0 depends on package: pkgconf>=1.3.0_1 - found
===> rust-1.83.0 depends on file: /usr/local/bin/python3.11 - found
===> rust-1.83.0 depends on file: /usr/local/lib/libcrypto.so.12 - found
===> rust-1.83.0 depends on file: /usr/local/bin/ccache - found
===> rust-1.83.0 depends on shared library: libcurl.so - found (/usr/local/lib/libcurl.so)
===> Configuring for rust-1.83.0
Bad system call
=> Sanity check failed: kernel is missing COMPAT_FREEBSD11
=> Aborting build
*** Error code 1
Stop.
make[5]: stopped in /usr/ports/lang/rust
*** Error code 1
Stop.
make[4]: stopped in /usr/ports/lang/rust
*** Error code 1
Stop.
make[3]: stopped in /usr/ports/lang/rust
*** Error code 1
Stop.
make[2]: stopped in /usr/ports/www/firefox
*** Error code 1
Stop.
make[1]: stopped in /usr/ports/www/firefox
*** Error code 1
Stop.
make: stopped in /usr/ports/www/firefox
root@ichigo:/usr/ports/www/firefox #
Glorious, right? My kernel is missing something I should not have removed. The nooptions COMPAT_FREEBSD11 # Compatible with FreeBSD11 line needs to be restored by switching nooptions to #options which would then not override the GENERIC kernel configuration file. Since I have not updated /usr/src after building (the faulty) kernel and world, I can simply fix the kernconf file and remake the kernel and reboot. Another thing I have avoided due to discovering the firefox issue is that normally right after I rebuild my kernel I also rebuild my poudriere to match. I did not get to that step so I don't double my repair work and waste three times as much time. Along with fixing my error, I decided that since I have made the transition from FreeBSD 13-stable to 14-stable, I actually no longer need the compatibility to FreeBSD 13. It is a good idea to keep compatibility with the prior major release initially with your first rebuild after the transition, it may take some time to get all ports rebuilt.
It is somewhat amazing that FreeBSD 14.x still needs to be compatible with FreeBSD 11. What is preventing the applicable changes to eliminate this issue? Maybe there needs to be work done on cargo/rust so that we can build them without needing to rely upon a bootstrap from the days of FreeBSD 11. Luckily this is a hidden pitfall which most vanilla users would never encounter, because the GENERIC kernel providers and the port maintainers both keep firefox and rust easy to install without needing to think about any issues at all. Even though many users would not be hit by this issue with compatibility with an old FreeBSD version, it remains a less than ideal solution. How far into the future will we need to keep the compatibility for this solitary purpose? This is now an additional firefox caveat and a rust caveat that I have added to the distilled notes.