NetBSD Problem Report #58820

From martin@aprisoft.de  Sun Nov 10 11:51:29 2024
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D80A51A9238
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 10 Nov 2024 11:51:29 +0000 (UTC)
Message-Id: <20241110115119.BDA835CC79B@emmas.aprisoft.de>
Date: Sun, 10 Nov 2024 12:51:19 +0100 (CET)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: modload does not properly search the module path
X-Send-Pr-Version: 3.95

>Number:         58820
>Category:       bin
>Synopsis:       modload does not properly search the module path
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 10 11:55:00 +0000 2024
>Last-Modified:  Sun Nov 10 13:35:01 +0000 2024
>Originator:     Martin Husemann
>Release:        NetBSD 10.99.12
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD big-apple.aprisoft.de 10.99.12 NetBSD 10.99.12 (POWERMAC_G5.MP) #121: Wed Sep 25 13:34:14 CEST 2024 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/macppc/compile/POWERMAC_G5.MP macppc
Architecture: powerpc
Machine: macppc
>Description:

The modload(8) man page says:

     Modules are loaded from the default system module areas unless the module
     parameter contains a path separator character (`/').


I take this as meaning I can just use the basename of the module, like:

[/tmp] master-of-confusion # modload usbverbose
modload: usbverbose: No such file or directory

But also the full filename does not work:

[/tmp] master-of-confusion # modload usbverbose.kmod
modload: usbverbose.kmod: No such file or directory

nor the relative path to sysctl kern.module.path:

[/tmp] master-of-confusion # modload usbverbose/usbverbose.kmod
modload: usbverbose/usbverbose.kmod: No such file or directory


Using the full path works:

[/tmp] master-of-confusion # modload /stand/amd64/10.99.12/modules/usbverbose/usbverbose.kmod
[/tmp] master-of-confusion # modstat |fgrep verbose
hdaudioverbose             driver   builtin  -        0       - -
pciverbose                 driver   builtin  -        0       - pci
scsiverbose                misc     builtin  -        0       - -
usbverbose                 driver   filesys  -        0     402 -

>How-To-Repeat:
s/a

>Fix:
n/a

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/58820: modload does not properly search the module path
Date: Sun, 10 Nov 2024 13:29:16 -0000 (UTC)

 martin@NetBSD.org writes:

 >[/tmp] master-of-confusion # modload usbverbose
 >modload: usbverbose: No such file or directory

 >But also the full filename does not work:
 >[/tmp] master-of-confusion # modload usbverbose.kmod
 >modload: usbverbose.kmod: No such file or directory

 It's either a file path (if it includes a '/'), absolute or relative to
 the current directory, and then it needs the same suffix as the file.

 Or it is a module name and then the path $base/$name/$name.kmod is used.
 That e.g. seems to work fine when you use /etc/rc.d/modules.

 In the latter case, a chroot is NOT honored. The kernel always accesses
 module files on the true root.

 The code looks broken though. In many places the name (with or without a '/')
 is treated just like a module name, e.g. to check for already loaded modules.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/58820: modload does not properly search the module path
Date: Sun, 10 Nov 2024 14:33:50 +0100

 On Sun, Nov 10, 2024 at 01:30:02PM +0000, Michael van Elst via gnats wrote:
 >  In the latter case, a chroot is NOT honored. The kernel always accesses
 >  module files on the true root.

 Indeed, that is the case that hit me (memory disk / w/o any modules in it).
 Loading form the "new" root via full path then works, which was confusing
 me.

 Martin

Home	PR Database Search