Discussion: FreeBSD 14.2-RELEASE Available

S

sidetone

Thread freebsd-14-2-release-available.95937
www.freebsd.org

FreeBSD 14.2-RELEASE Release Notes

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

Some parts, I found notable:
Depreciated and Removed Drivers:
agp(4) has been planned for removal in FreeBSD 15.0, and the man page now states that it is deprecated. 92af7c97e197
Click to expand...
syscons(4) has been planned for removal in future releases, and has been noted as deprecated in the man pages to notify users tomigrate to vt(4). 2bc5b1d60512 (Sponsored by The FreeBSD Foundation)
Click to expand...
Multimedia:
Many improvements to the audio stack including support for hot-swapping in mixer(8), and the addition of mididump(1). cf9d2fb18433 (Sponsored by The FreeBSD Foundation) 7224e9f2d4af (Sponsored by The FreeBSD Foundation)
Click to expand...
Installer:
The FreeBSD installer, bsdinstall(8), now supports downloading and installing firmware packages after the FreeBSD base system installation is complete.03c07bdc8b31 (Sponsored by The FreeBSD Foundation)
Click to expand...
Also, improvements to network drivers.

Discussion: including parts you find notable of the release. Including other discussion relevant to FreeBSD 14.2-RELEASE. Also, Thread attempted-to-upgrade-to-14-2-release-today.95906 isn't directly about this specific topic, but about a user's difficulty with upgrading to 14.2-RELEASE.
 
After upgrading to 14.2-RELEASE, one host failed to load i915kms. The other hosts works great.
Dec 3 12:24:57 localhost kernel: [105.987754] <6>[drm] Got Intel graphics stolen memory base 0xba800000, size 0x2000000
Dec 3 12:24:57 localhost kernel: [105.987969] drmn0: <drmn> on vgapci0
Dec 3 12:24:57 localhost kernel: [105.988054] vgapci0: child drmn0 requested pci_enable_io
Dec 3 12:24:57 localhost kernel: [105.988060] vgapci0: child drmn0 requested pci_enable_io
Dec 3 12:24:57 localhost kernel: [105.992392] kbl_dmc_ver1_04.bin: could not load binary firmware /boot/firmware/kbl_dmc_ver1_04.bin either
Dec 3 12:24:57 localhost kernel: [105.992559] i915/kbl_dmc_ver1_04.bin: could not load binary firmware /boot/firmware/i915/kbl_dmc_ver1_04.bin either
Dec 3 12:24:57 localhost kernel: [105.992704] i915_kbl_dmc_ver1_04.bin: could not load binary firmware /boot/firmware/i915_kbl_dmc_ver1_04.bin either
Dec 3 12:24:57 localhost kernel: [105.992889] drmn0: successfully loaded firmware image 'i915/kbl_dmc_ver1_04.bin'
Dec 3 12:24:57 localhost kernel: [105.993400] drmn0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
Dec 3 12:24:57 localhost kernel: [105.994296] lkpi_iic0: <LinuxKPI I2C> on drmn0
Dec 3 12:24:57 localhost kernel: [105.994318] iicbus0: <Philips I2C bus> on lkpi_iic0
Dec 3 12:24:57 localhost kernel: [105.994375] iic0: <I2C generic I/O> on iicbus0
Dec 3 12:24:57 localhost kernel: [105.994410] lkpi_iic1: <LinuxKPI I2C> on drmn0
Dec 3 12:24:57 localhost kernel: [105.994425] iicbus1: <Philips I2C bus> on lkpi_iic1
Dec 3 12:24:57 localhost kernel: [105.994459] iic1: <I2C generic I/O> on iicbus1
Dec 3 12:24:57 localhost kernel: [105.994481] lkpi_iic2: <LinuxKPI I2C> on drmn0
Dec 3 12:24:57 localhost kernel: [105.994496] iicbus2: <Philips I2C bus> on lkpi_iic2
Dec 3 12:24:57 localhost kernel: [105.994529] iic2: <I2C generic I/O> on iicbus2
Dec 3 12:24:57 localhost kernel: [106.045577] drmn0: [drm] [ENCODER:102:DDI B/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it
Dec 3 12:24:57 localhost kernel: [106.045620] drmn0: [drm] [ENCODER:117:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it
Dec 3 12:24:57 localhost kernel: [106.065570] sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
Dec 3 12:24:57 localhost kernel: [106.065883] lkpi_iic3: <LinuxKPI I2C> on drm1
Dec 3 12:24:57 localhost kernel: [106.065975] iicbus3: <Philips I2C bus> on lkpi_iic3
Dec 3 12:24:57 localhost kernel: [106.066167] iic3: <I2C generic I/O> on iicbus3
Dec 3 12:24:57 localhost kernel: [106.066340] lkpi_iic4: <LinuxKPI I2C> on drm2
Dec 3 12:24:57 localhost kernel: [106.066413] iicbus4: <Philips I2C bus> on lkpi_iic4
Dec 3 12:24:57 localhost kernel: [106.066571] iic4: <I2C generic I/O> on iicbus4
Dec 3 12:24:57 localhost kernel: [106.066754] lkpi_iic5: <LinuxKPI I2C> on drm4
Dec 3 12:24:57 localhost kernel: [106.066828] iicbus5: <Philips I2C bus> on lkpi_iic5
Dec 3 12:24:57 localhost kernel: [106.066995] iic5: <I2C generic I/O> on iicbus5
Dec 3 12:24:57 localhost kernel: [106.067098] <6>[drm] Initialized i915 1.6.0 20201103 for drmn0 on minor 0
Dec 3 12:24:57 localhost kernel: [106.446561] VT: Driver priority 0 too low. Current 101
Click to expand...
 
Official packages for *-Release are built on oldest supported version (for 14.*, 14.1 for now).

This is basically safe, but the exceptions are kernel modules, because they strongly depends on kernel internals, which can be changed on each upgrade (commits to kernel and in-base modules).

Some modules which depends only on GENERIC kernel itself could be OK, because usually FreeBSD project attempts to keep KBI (Kernel Binary Interface) backward compatible throuout the same branch, unless any specific and unavoidable reason exists. This is "best effort" basis, and basically assures KPI (Kernel Programming Interface, which is source code level) stabilities.

But anything outside GENERIC kernel such as linuxkpi.ko, it suddenly becomes "moving goals". KPI are attempted to keep backward compatible (additions only as much as possible), but basically KBI should be considered to be broken on each commit to the module.
graphics/drm-*-kmod and their dependencies like graphics/nvidia-drm-*-kmod are exactly the case.

On the other hand, x11/nvidia-driver* are quite robust for kernel upgrades, as (unless LINUX option is enabled) it doesn't depend on modules outside GENERIC kernel. Modules needed are self-contained in the ports (nvidia-modeset.ko depends on nvidia.ko, but both are built as same x11/nvidia-driver* ports). And even with LINUX option, required kernel modules are far less often updated compared with linuxkpi.ko.
 
yjqg6666 said:
After compiling/make package/pkg install ./work/pkg/*.pkg of graphics/drm-61-kmod and graphics/gpu-firmware-intel-kmod from main branch of ports tree. It works now.
Click to expand...
This. It seems that we need to compile directly from the ports tree until FreeBSD 14.1 reaches EoL.

Reference: https://www.freebsd.org/releases/14.2R/errata/
drm-kmod packages compiled on FreeBSD 14.1 result in the text console being inoperative when the kernel module is loaded. Recompiling the package from the ports tree will restore the lost functionality. This issue will also resolve itself after the FreeBSD 14.1 EoL, when packages for 14-STABLE will start being built on FreeBSD 14.2-RELEASE.
Click to expand...
 
Maybe a hook on installing pkg would be needed to invoke building from ports. (Install-time script included in pkg could be sufficient?)
This case, if ports tree is not there, automated fetch minimum parts (itself, Mk/ and dependencies if any) would be needed, too.
 
T-Aoki said:
Maybe a hook on installing pkg would be needed to invoke building from ports. (Install-time script included in pkg could be sufficient?)
This case, if ports tree is not there, automated fetch minimum parts (itself, Mk/ and dependencies if any) would be needed, too.
Click to expand...

Yeah. You pretty much need what Debian is doing with kernel modules. Problem is, this isn't exactly a robust process.
 
cracauer@ said:
Yeah. You pretty much need what Debian is doing with kernel modules. Problem is, this isn't exactly a robust process.
Click to expand...
Exactly. Unfortunately not always promised to be successful.

It would be nice if specific kmods which are fragile on updates of base are built and provided per-point-releases basis. At least, graphics/drm-*-kmod and graphics/nvidia-drm-*-kmod but possibly more.

(graphics/nvidia-drm-*-kmod depends on graphics/drm-*-kmod and x11/nvidia-driver, but x11/nvidia-driver is mostly robust on upgrades of base.)

Note that firmware kmods are not actually kmod ports, thus would not needed to be provided as such.
 
drm-kmod packages compiled on FreeBSD 14.1 result in the text console being inoperative when the kernel module is loaded. Recompiling the package from the ports tree will restore the lost functionality. This issue will also resolve itself after the FreeBSD 14.1 EoL, when packages for 14-STABLE will start being built on FreeBSD 14.2-RELEASE.
Click to expand...
The above open issue could be mentioned in the installation/#upgrade-binary section of the release note. The users who using i915kms would have kld_list="i915kms" in rc.conf, after upgrading/reboot, the system would hang at boot time. They have to enter single user mode, set zfs to rw mode if zfs is used, remove i915kms from kld_list, restart, compiling i915kms, kldload i915kms to test, add i915kms to kld_list back.
 
After loading a 14.2 kernel from the loader prompt, is there any way to try out a 14.2 world installed to a different directory without overwriting everything with make installworld to / ?
 
My unsuccessful update experience. See the photo. Sorry I couldn't post just the text.
9 photos: rebooted and got a black screen.
 

Attachments

  • 14-2.jpg
    14-2.jpg
    557.2 KB · Views: 131
MG said:
I mean without having to recompile everything. I might try to replace all system directories with tmpfs copies and then use the same /usr/local as before to see any problems wth X.org and other packages.
Click to expand...
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).
 
USerID said:
My unsuccessful update experience. See the photo. Sorry I couldn't post just the text.
Click to expand...
Actually fix the merge issues that come up. You accepted files with a bunch of merge markers in them, you're supposed to resolve those.
 
yjqg6666 said:
The above open issue could be mentioned in the installation/#upgrade-binary section of the release note. The users who using i915kms would have kld_list="i915kms" in rc.conf, after upgrading/reboot, the system would hang at boot time. They have to enter single user mode, set zfs to rw mode if zfs is used, remove i915kms from kld_list, restart, compiling i915kms, kldload i915kms to test, add i915kms to kld_list back.
Click to expand...

I see no problem with this carefully laid out procedure :D
 
You must log in or register to reply here.
Back
Top