modprobe failed: digest_null

I am seeing many messages like

kernel: request_module: failed /sbin/modprobe -- digest_null. error = 256

in my logs. What's the nature of these?

Thanks,

martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
"it's time for the human race to enter the solar system." 
                                                      - george w. bush

On Tue, 13 Jan 2004 22:53:55 +0100 martin f krafft <[email protected]> wrote:

| I am seeing many messages like
| 
|   kernel: request_module: failed /sbin/modprobe -- digest_null. error = 256
| 
| in my logs. What's the nature of these?

Any other possibly related messages in the logs?

What kernel version? like 2.4.2x ?? other patches applied? [not 2.6.x since modprobe is being used]

--
~Randy
MOTD: Always include version info.

also sprach Randy.Dunlap <[email protected]> [2004.01.13.2330 +0100]:

it's IPsec related since it always appears together with racoon entries

2.6.1 in fact.

why is modprobe not being using in 2.6.x anymore?

martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
"if you can dream it, you can do it"
                                                        -- walt disney

On Tue, 13 Jan 2004 23:37:39 +0100 martin f krafft <[email protected]> wrote:

| also sprach Randy.Dunlap <[email protected]> [2004.01.13.2330 +0100]:
| > Any other possibly related messages in the logs?
| 
| it's IPsec related since it always appears together with racoon
| entries

It seems to be related to an alias that has no module definition.

| > What kernel version?  like 2.4.2x ??  other patches applied?
| > [not 2.6.x since modprobe is being used]
| 
| 2.6.1 in fact.
| 
| why is modprobe not being using in 2.6.x anymore?

Sorry, I screwed that up. modprobe is stil around, it's just a different modprobe.
But that messages appears in modutils and not in module-init-tools AFAICT.

I would guess that you have a high-priority $PATH to old modprobe than to the new modprobe...

--
~Randy
MOTD: Always include version info.

also sprach Randy.Dunlap <[email protected]> [2004.01.13.2341 +0100]:

That would surprise me, Debian handles this quite well:

diamond:~# which modprobe
/sbin/modprobe
diamond:~# modprobe -V
module-init-tools version 3.0-pre5
diamond:~# modprobe.modutils -V
modprobe version 2.4.26
modprobe: QM_MODULES: Function not implemented
diamond:~# uname -r
2.6.1

PS: I would appreciate not being CC'd on list mail.

martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
the only real advantage to punk music is
that nobody can whistle it.

On Tue, 13 Jan 2004 23:50:47 +0100 martin f krafft <[email protected]> wrote:

| also sprach Randy.Dunlap <[email protected]> [2004.01.13.2341 +0100]:
| > I would guess that you have a high-priority $PATH to old modprobe
| > than to the new modprobe...
| 
| That would surprise me, Debian handles this quite well:
| 
| diamond:~# which modprobe
| /sbin/modprobe
| diamond:~# modprobe -V
| module-init-tools version 3.0-pre5
| diamond:~# modprobe.modutils -V
| modprobe version 2.4.26
| modprobe: QM_MODULES: Function not implemented
| diamond:~# uname -r
| 2.6.1

OK, maybe someone else has an answer then.

The message:
kernel: request_module: failed /sbin/modprobe -- digest_null. error = 256 is from modutils and not from module-init-tools according to my source files.

--
~Randy
MOTD: Always include version info.

I'm getting similar messages from dmesg after upgrading to 2.6.1, too:

request_module: failed /sbin/modprobe -- n. error = 256

[drees@summit drees]$ /sbin/modprobe -V
module-init-tools version 3.0-pre5
[drees@summit drees]$

Running on Fedora Core 1 compiled with gcc 3.3.2. Didn't see these with 2.6.0.

-Dave

On Tue, 13 Jan 2004 15:38:45 -0800 (PST) "David Rees" <[email protected]> wrote:

| On Tue, January 13, 2004 at 3:03 pm, Randy.Dunlap wrote:
| >
| > OK, maybe someone else has an answer then.
| >
| > The message:
| > kernel: request_module: failed /sbin/modprobe -- digest_null. error = 256
| > is from modutils and not from module-init-tools according to my
| > source files.
| 
| I'm getting similar messages from dmesg after upgrading to 2.6.1, too:
| 
| request_module: failed /sbin/modprobe -- n. error = 256
| 
| [drees@summit drees]$ /sbin/modprobe -V
| module-init-tools version 3.0-pre5
| [drees@summit drees]$
| 
| Running on Fedora Core 1 compiled with gcc 3.3.2.  Didn't see these with
| 2.6.0.

Yes, I see a couple of similar messages:

request_module: failed /sbin/modprobe -- parport_lowlevel. error = -16
request_module: failed /sbin/modprobe -- fb0. error = 256

...?

--
~Randy
MOTD: Always include version info.

On Tue, 13 Jan 2004 16:01:31 -0800 "Randy.Dunlap" <[email protected]> wrote:

| On Tue, 13 Jan 2004 15:38:45 -0800 (PST) "David Rees" <[email protected]> wrote:
| 
| | On Tue, January 13, 2004 at 3:03 pm, Randy.Dunlap wrote:
| | >
| | > OK, maybe someone else has an answer then.
| | >
| | > The message:
| | > kernel: request_module: failed /sbin/modprobe -- digest_null. error = 256
| | > is from modutils and not from module-init-tools according to my
| | > source files.
| | 
| | I'm getting similar messages from dmesg after upgrading to 2.6.1, too:
| | 
| | request_module: failed /sbin/modprobe -- n. error = 256
| | 
| | [drees@summit drees]$ /sbin/modprobe -V
| | module-init-tools version 3.0-pre5
| | [drees@summit drees]$
| | 
| | Running on Fedora Core 1 compiled with gcc 3.3.2.  Didn't see these with
| | 2.6.0.
| 
| Yes, I see a couple of similar messages:
| 
| request_module: failed /sbin/modprobe -- parport_lowlevel. error = -16
| request_module: failed /sbin/modprobe -- fb0. error = 256
| 
| ...?

I don't think that it's related to IPsec since I'm not using that.

I'm looking at the changes in kernel/kmod.c for 2.6.1 to see if they could cause it.

--
~Randy
MOTD: Always include version info.

also sprach David Rees <[email protected]> [2004.01.14.0038 +0100]:

Neither did I. Are you running IPsec?

martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
this message represents the official view of the voices in my head.

No IPsec, though I do have the crypto stuff compiled as modules.

-Dave

Chris Wright tells me that this is a null digest crypto plugin for testing. It might show up in your /etc/modprobe.conf file (or it might not).

| request_module: failed /sbin/modprobe -- n. error = 256

This is looking for a module named "n". Don't know where that comes from.

In both cases, error = 256 is 0x100, which is the value returned from kernel/kmod.c::call_usermodehelper(), which execs /sbin/modprobe in this case. /sbin/modprobe does exit(1) for modules that are not found, and that 1 becomes 0x100 in call_usermodehelper().

| Running on Fedora Core 1 compiled with gcc 3.3.2. Didn't see these with | 2.6.0.

and I wrote yesterday:
| request_module: failed /sbin/modprobe -- parport_lowlevel. error = -16

This one comes from drivers/char/lp.c::lp_init() calling parport_register_driver(), which calls get_lowlevel_driver(), which calls request_module("parport_lowlevel").
Since I have lp.o and parport code built into the kernel image, these calls happen during early init, before <system_running> is set to 1, so call_usermodehelper() returns -EBUSY (-16 on x86).

| request_module: failed /sbin/modprobe -- fb0. error = 256

Same as first case above, but for a framebuffer device.

I don't know what needs to be done about these, if anything.

Comments, suggestions?

--
~Randy

tor, 15.01.2004 kl. 00.48 skrev Randy.Dunlap:

As Steve Youngs wrote a couple of days ago:

install <modulename> /bin/true

in your modprobe.conf will get rid of the messages, if you find them annoying.

Best regards,
Stian

also sprach Randy.Dunlap <[email protected]> [2004.01.15.0048 +0100]:

i don't see such a module in the kernel config. there is the null encryption, but it's not a null digest.

martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
this space intentionally left blank.

Your correct about where this message _doesn't_ come from, but not about where it _does_ come from...

,----[ ./kernel/kmod.c -- lines 113 - 115 ]

| printk(KERN_DEBUG
|        "request_module: failed %s -- %s. error = %d\n",
|        modprobe_path, module_name, ret);

`----

|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|              Ashes to ashes, dust to dust.               |
|      The proof of the pudding, is under the crust.       |
|------------------------------<[email protected]>---|

On Wed, 14 Jan 2004 11:26:00 +1000 Steve Youngs <[email protected]> wrote:

| * Randy Dunlap <Randy.Dunlap> writes:
| 
|   > The message:
|   > kernel: request_module: failed /sbin/modprobe -- digest_null. error = 256
|   > is from modutils and not from module-init-tools according to my
|   > source files.
| 
| Your correct about where this message _doesn't_ come from, but not
| about where it _does_ come from...
| 
| ,----[ ./kernel/kmod.c -- lines 113 - 115 ]
| | printk(KERN_DEBUG
| |        "request_module: failed %s -- %s. error = %d\n",
| |        modprobe_path, module_name, ret);
| `----

Yes, I found that and am digging into it, but I'm close to end-of-day, so someone else can pick it up soon...

--
~Randy
MOTD: Always include version info.

also sprach Randy.Dunlap <[email protected]> [2004.01.14.0231 +0100]:

I appreciate your time, Randy!

martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
"if they can get you asking the wrong questions,
 they don't have to worry about answers."
                                                     -- thomas pynchon

Its from the kernel afaik. It calls modprobe, fails, and then prints its own custom message. He basically just have something that tries to load a module with alias 'digest_null', but there is no such module, so fails.

I have the same thing when I open gnome-mixer:

--
request_module: failed /sbin/modprobe -- sound-slot-1. error = 256 --

as I only have one sound card ...

Cheers,

Martin Schlemmer

Upgrade module-init-tools to 0.9.14 or one of the 3.0 -pres.

Old "modprobe -q" fails when presented with a module it has never heard of.

Cheers,
Rusty.

   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

also sprach Rusty Russell <[email protected]> [2004.01.15.0022 +0100]:

diamond:~# modprobe -V
module-init-tools version 3.0-pre5

martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
i've not lost my mind. it's backed up on tape somewhere.

On Thu, 15 Jan 2004 09:08:15 +0100 martin f krafft <[email protected]> wrote:

| also sprach Rusty Russell <[email protected]> [2004.01.15.0022 +0100]:
| > Upgrade module-init-tools to 0.9.14 or one of the 3.0 -pres.
| 
| diamond:~# modprobe -V
| module-init-tools version 3.0-pre5

Yes, and I'm using 0.9.14 and seeing similar messages.

--
~Randy

i am quite sure this message comes from freeswan 2.04.

programs/pluto/kernel_netlink.c: { SADB_X_AALG_NULL, "digest_null" },

Think it could be fixed by replacing digest_null with crypto_null (or modprobing crypto_null manually before starting freeswan) but then the next problem with

kernel: request_module: failed /sbin/modprobe -- ripemd160. error = 256

from same freeswan source file...

Andreas

PS: sorry, Randy for dublette...

In message <[email protected]> you write:

e:

Yes, as several people have pointed out. I *did* briefly make the change so -q always returned "success", but had to revert it because it caused infinite loops in some legitimate configurations (thanks to Jamie Lokier for reporting this).

With the change to default to idemptent behavior (modprobe foo when foo is already installed silently "succeeds" unless --first-time is specified), the definition of -q can be safely changed to mean "ignore this if you've never heard of it").

This is done in 3.0-pre6, now available.

BTW, if you had fairly complex modules.conf, you should regenerate modprobe.conf for the 3.0 releases: some cases have changed.

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.