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