On 4/14/24 12:46, Fernando Apesteguía wrote:
The branch main has been updated by fernape:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=bc0c6c9cf3a9f9a54dbdd92dd8f1f65ff8092d17

commit bc0c6c9cf3a9f9a54dbdd92dd8f1f65ff8092d17
Author:     Fernando Apesteguía <[email protected]>
AuthorDate: 2023-04-19 16:08:47 +0000
Commit:     Fernando Apesteguía <[email protected]>
CommitDate: 2024-04-14 17:46:23 +0000

     freebsd-update: Add check for kernel modules
People get confused when some software (VirtualBox, etc) does not work as
     expected (or at all) after a major upgrade.
We have a nice way to deal with this when using sources, namely including
     PORTS_MODULES in /etc/make.conf, but we lack something similar for binary
     updates.
This patch retrieves a list of kernel modules installed from packages and
     advises the user to recompile from ports to avoid problems.
Approved by: zlei@
     Differential Revision:  https://reviews.freebsd.org/D39695
---
  usr.sbin/freebsd-update/freebsd-update.sh | 58 +++++++++++++++++++++++++++++++
  1 file changed, 58 insertions(+)

diff --git a/usr.sbin/freebsd-update/freebsd-update.sh 
b/usr.sbin/freebsd-update/freebsd-update.sh
index 4a6a8d78330b..d1cd46963a6c 100644
--- a/usr.sbin/freebsd-update/freebsd-update.sh
+++ b/usr.sbin/freebsd-update/freebsd-update.sh
@@ -655,6 +655,63 @@ fetch_setup_verboselevel () {
        esac
  }
+# Check if there are any kernel modules installed from ports.
+# In that case warn the user that a rebuild from ports (i.e. not from
+# packages) might need necessary for the modules to work in the new release.
+upgrade_check_kmod_ports() {
+       local mod_name
+       local modules
+       local pattern
+       local pkg_name
+       local port_name
+       local report
+       local w
+
+       if ! command -v pkg >/dev/null; then
+               echo "Skipping kernel modules check. pkg(8) not present."
+               return
+       fi
+
+       # Most modules are in /boot/modules but we should actually look
+       # in every path configured in module_path
+       search_files="/boot/defaults/loader.conf /boot/loader.conf"

Woof... this is inherently quite fragile, and it completely ignores how loader.conf are actually processed. The final module_path will always get passed to the kernel via kenv(1) and exposed as kern.module_path, please strongly consider just grabbing it from one of them instea .

Thanks,

Kyle Evans

Reply via email to