module autoloading doesn't work: modprobe PATH problem (yes, another one)

[Yann E. MORIN]

Ignacio,

On Thursday 17 May 2007 08:44, Ignacio García Pérez wrote:
> I'm debugging some problems that have arised when I upgraded the busybox 
> and kernel versions of my system. Yesterday I struggled with a PATH 
> problem in udev, and today I stumbled upon another PATH problem, this 
> time with modprobe, which completely clobbers the module autoloading 
> feature of the kernel.

It rings a bell here. There has been discussion about this issue earlier.
Search the archives, I can't remember right now.

> When the kernel wants to load a module, it executes 
> /proc/sys/kernel/modprobe, which by default points to /sbin/modprobe. 
> The "real" modprobe does everything by itself (resolve dependencies and 
> load modules), but busybox's modprobe makes external calls to insmod, 
> relying on the PATH to find the insmod executable.
> 
> The problem is obvious: the kernel does not set up a PATH variable when 
> calling /sbin/modprobe, and thus modprobe fails miserably.

Yes, it does. From linux-2.6.21.1/kernel/kmod.c at 64:

int request_module(const char *fmt, ...)
{
    va_list args;
    char module_name[MODULE_NAME_LEN];
    unsigned int max_modprobes;
    int ret;
    char *argv[] = { modprobe_path, "-q", "--", module_name, NULL };
    static char *envp[] = { "HOME=/",
                "TERM=linux",
                "PATH=/sbin:/usr/sbin:/bin:/usr/bin",
                NULL };
[--SNIP--]

So, the kernel *does* set PATH before calling modprobe. Add this litle snippet
of code to modprobe just to check:
  printf( "%s\n", getenv( "PATH" ) );

> I've done a quick fix by setting the absolute path of insmod and rmmod 
> inside modprobe.c, but I'm not sure if this is the best solution.
> On one hand, setting the absolute path breaks the freedom of the use to 
> choose where to put his binaries.
> On the other hand, we are trying to replicate the functionality of the 
> "real" modprobe, and it does its work without using external binaries, 
> thus with the "real" modprobe the user has no freedom to choose which 
> insmod executable to use anyway.

Nah. In fact, modprobe in BusyBox can still work with linux-2.4, which has
a substantially more complex way of loading a module. So our modprobe can't
replicate the way insmod works for linux-2.4, and thus we must call it.
Even in the linux-2.6 case.

> Any suggestions?

Search the archives first. I can't remember when that was (quite some time ago,
if my memory is not that faulty...) but I'm pretty sure we already discussed
this issue...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< °_° >==-- °------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
°------------------------------°-------°------------------°--------------------°