Discussion: FreeBSD 14.2-RELEASE Available

There won't be any. It's only kernel modules installed from packages that could potentially cause an issue. Everything else is never affected with a minor version upgrade (due to ABI stability).
X doesn't start when running a 14.2 kernel and 14.1 userland. So, there are complications. I didn't research anything yet. It might be i915/drm related as mentioned here. This needs an explicit warning. You will be hours without a graphical screen, during recompiling. The percentage of i915/Intel HD on-board graphics chipset users is too significant to ignore.
 
Also, we can discuss: Thread freebsd-14-2-whats-new-and-how-did-we-get-here.95965.

Shell and MTA defaults​

Default Shell: The root user’s default shell is now sh(1), which includes many new features for interactive use. This change simplifies the environment and improves security by using a shell with fewer historical vulnerabilities than other shells like csh or bash.
Default MTA: The default Mail Transport Agent (MTA) is now the Dragonfly Mail Agent (dma(8)), replacing sendmail(8). This change simplifies mail configuration and management. Configuration is handled through mailer.conf(5), and sendmail(8) is still available for those who need it. Additionally, the mta_start_script configuration variable has been retired from rc.conf(5) along with the othermta startup script.

Userland enhancements​

Base64 utility: A new utility, base64(1), has been introduced. This utility allows users to encode and decode data in base64 format, which is commonly used for encoding binary data in text files such as email attachments and XML data

Utilities and enhancements
Improved Documentation: Enhancements in kernel documentation, making it easier for users and developers to understand and utilize new features.

More
Sound System (snd_clone): The snd_clone framework, including related sysctls, was removed from the sound subsystem, simplifying the system. The per-channel nodes (/dev/dspX.Y) are no longer created; only the primary device (/dev/dspX) is.
Updated Wifi and other Ethernet drivers.
 
But on the antediluvian netbook ASUS Eee PC 701 everything went perfectly. I don't use X/Wayland. A good hardware platform for testing a network based on 14.2-RELEASE.
 
X doesn't start when running a 14.2 kernel and 14.1 userland. So, there are complications. I didn't research anything yet. It might be i915/drm related as mentioned here. This needs an explicit warning. You will be hours without a graphical screen, during recompiling. The percentage of i915/Intel HD on-board graphics chipset users is too significant to ignore.
I think this what The Register’s mini-review found:

 
I'm not sure that rebuilding the i915kms bits will take "hours".
And honestly, people used VT100 terminals just fine for years.

I'm not saying this is a "non problem" but rather, don't overdramatize it.
 
I git pulled src (releng14.2) and ports (main), make install clean on drm-61-kmod (compiled but failed on 515 conflict), uninstalled drm-515-kmod pkg, re-ran make install clean, rebooted, and have GUI! It seemed pretty easy :p

Is that all that's needed? I installed drm-515-kmod and gpu-firmware-intel-kmod-kabylake originally (not drm-kmod itself nor extra gpu-firmware), so it seems I'd only need to keep the drm-61-kmod part up-to-date from ports, while the gpu-firmware can remain a pkg and be unaffected by ABI changes?
 
How about always building the drm-kmod related pkg binaries(pkg.freebsd.org) using the latest release?
A few years ago, when these compiled the kernel, or put into /boot/loader.conf they would always crash. Not much has been expected to have changed from this. By now, with older drivers now stabilized, those could be made to work from the kernel or into loader.conf.

The way it is now, from package or ports, it works. Different versions from packages ports are for different drivers. The older and traditional graphics drivers, use the older version on all FreeBSD releases. Only the newer graphics cards need Stable, or Current, which each one supports a limited subset of newer card, which CURRENT runs the newest ones available for FreeBSD. Most cards by now fall under the one for regular release. And Current is for the most recent cards available for FreeBSD. So, only the advanced models will need Stable. And current is for testing those more newer cards. The version is in the name.
 
A few years ago, when these compiled the kernel, or put into /boot/loader.conf they would always crash. Not much has been expected to have changed from this. By now, with older drivers now stabilized, those could be made to work from the kernel or into loader.conf.

The way it is now, from package or ports, it works. Different versions from packages ports are for different drivers. The older and traditional graphics drivers, use the older version on all FreeBSD releases. Only the newer graphics cards need Stable, or Current, which each one supports a limited subset of newer card, which CURRENT runs the newest ones available for FreeBSD. Most cards by now fall under the one for regular release. And Current is for the most recent cards available for FreeBSD. So, only the advanced models will need Stable. And current is for testing those more newer cards. The version is in the name.
Possibly this is because staging area of loader (where loader loads kernel and specified kernel modules BEFORE STARTING KERNEL) was bumped to larger size.

But when the kernel or mandatory-for-boot modules (ZFS kernel modules for Root-on-ZFS, not-in-GENERIC drivers for disk interfaces, for NIC required by network boot, and so on) becomes larger, the problem could resurrect.

So loading non-mandatory-for-boot kernel modules like GPU drivers are strongly advided to load via kld_list variable in /etc/rc.conf[.local], not via /boot/loader.conf.
 
Not sure if it was mentioned elsewhere, but why does drm-515-kmod happen to work if 61 needs recompiled for 14.2-R?
It is always a good practice to recompile kernel bound modules after such upgrades. By compile I mean do it yourself (ports) or let someone else to do it for you (packages). Personally, I have always preferred to compile all by myself. Understand that some people may have a different preference.

What comes to drm-61-kmod, out of curiosity, I did actually try to run it without recompiling. This experiment resulted with black console screen. However, the Xorg was able to start and after that my WM ran normally.
 
I usually disable sddm and drm kernel module loading before rebooting after a release upgrade. After the reboot I pull the new kernel sources, refresh my ports repository, rebuild the kernel module, load it manually and if it works I re-enable sddm and automatic module loading at boot and reboot.
 
I usually disable sddm and drm kernel module loading before rebooting after a release upgrade. After the reboot I pull the new kernel sources, refresh my ports repository, rebuild the kernel module, load it manually and if it works I re-enable sddm and automatic module loading at boot and reboot.
This is a good process, it's also why a lot of us still boot to command line and then run startx. Again, just my preference.
 
In my case I have a full disk encription in place, so I have to type my passphrase at boot and, by using sddm, I can autologin to X. Without a DM I'll have to type my password/passphrase twice.
 
  • Like
Reactions: mer
I usually disable sddm and drm kernel module loading before rebooting after a release upgrade.
For an even more trouble free upgrade you could disable everything you don't strictly need to boot the machine. All (extra) kernel modules and services (besides sshd(8) if you work remotely). For the bigger database servers for example I typically disable MySQL. I'm probably going to reboot a couple of times and I don't want the database starting/stopping interfering (or worse, breaking!). I'll enable everything again once I'm done with the OS upgrade.
 
For an even more trouble free upgrade you could disable everything you don't strictly need to boot the machine. All (extra) kernel modules and services (besides sshd(8) if you work remotely). For the bigger database servers for example I typically disable MySQL. I'm probably going to reboot a couple of times and I don't want the database starting/stopping interfering (or worse, breaking!). I'll enable everything again once I'm done with the OS upgrade.
Yes, I agree but please note that we're talking about a laptop with a very simple configuration for desktop usage, with only two kernel modules that come from ports (i915kms and vboxdrv - this one simply refuses to load and doesn't do any harm).
 
Back
Top