Re: git: bc0c6c9cf3a9 - main - freebsd-update: Add check for kernel modules

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 <fernape@FreeBSD.org>
> AuthorDate: 2023-04-19 16:08:47 +0000
> Commit:     Fernando Apesteguía <fernape@FreeBSD.org>
> 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