Arch Linux

The rule that trigger this is this ""catch-all"" @ 80-drivers.rules

DRIVER!="?*", ENV{MODALIAS}=="?*", RUN{ignore_error}+="/lib/udev/load-modules.sh $env{MODALIAS}"

The correct title maybe: "udev trigger a event with module alias that are inexistent in modules.alias from kernel"

so this isn't a bug in load-modules.sh, but the boot process is now slow because logger now works, and logger/minilogd takes some times.

maybe a blacklist the module alias that cause this warning?

Hmm I think these are harmless. And the thing is, if any module adds an alias for these in the future, we're covered - for instance, the acpi: aliases looks like they may match the acpi modules (fan, thermal, etc) in the future. This would mean we no longer have to manually load them

I could always shut up load-modules.sh, but I think these warnings are valuable.

Hmmm, are you sure this is what's causing the slowdown? How about commenting out the logger lines in load-modules.sh to see if it speeds things up.

Sorry, I did not explain very well. I have this lines, but not experiment this slowdown.
s/because/maybe in my above comment.
I will ask the forum users who have this problem of slowness, in what happens if comment #logger. ;)

I think the slowdown is just udev being typical - sometimes it gets slower, sometimes it gets faster. It's like playing roulette when you upgrade :)

Back to the point at hand: I think these warnings are useful and skipping over them may do us harm in the future.

Are there any other side effects besides log messages?

hehe, ok.

Correct, I understand what you mean. Anyway, I can help by providing ideas, to do something about it if you are interested.

No, there are no side effects, or almost for me. I am waiting the responses from forum users.

Hello!
I've got the same problem. Here is an extract from my /var/log/messages.log:

Apr 15 15:31:20 forneus load-modules.sh: 'pci:v000010DEd000001EEsv00001043sd000080ACbc05sc00i00' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'pci:v000010DEd000001EBsv00001043sd000080ACbc05sc00i00' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'pci:v000010DEd000001ECsv00001043sd000080ACbc05sc00i00' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'pci:v000010DEd000001EDsv00001043sd000080ACbc05sc00i00' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:LNXSYSTM:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'pci:v000010DEd000001EFsv00001043sd000080ACbc05sc00i00' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'pci:v000010DEd00000060sv00001043sd000080ADbc06sc01i00' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0000:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0C02:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0200:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0C01:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0100:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0303:PNP030B:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0501:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0501:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0800:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0C02:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0C04:' is not a valid module or alias name
Apr 15 15:31:20 forneus load-modules.sh: 'acpi:PNP0C02:' is not a valid module or alias name
Apr 15 15:31:21 forneus load-modules.sh: 'platform:vesafb' is not a valid module or alias name
Apr 15 15:31:21 forneus load-modules.sh: Not loading module alias 'pcspkr' because it is blacklisted
Apr 15 15:31:21 forneus load-modules.sh: 'dmi:bvnPhoenixTechnologies,LTD:bvrASUSA7N8X2.0DeluxeACPIBIOSRev1007:bd10/06/2003:svnASUSTeKComputerINC.:pnA7N8X2.0:pvrREV2.xx:rvnASUSTeKC
omputerINC.:rnA7N8X2.0:rvrREV2.xx:cvnChassisManufactture:ct3:cvrChassisVersion:' is not a valid module or alias name
Apr 15 15:31:21 forneus load-modules.sh: 'pci:v00001002d00004155sv000017AFsd0000200Fbc03sc00i00' is not a valid module or alias name
Apr 15 15:31:21 forneus load-modules.sh: 'pci:v00001002d00004175sv000017AFsd0000200Ebc03sc80i00' is not a valid module or alias name
Apr 15 15:31:21 forneus load-modules.sh: 'platform:parport_pc' is not a valid module or alias name
Apr 15 15:31:21 forneus load-modules.sh: 'platform:parport_pc' is not a valid module or alias name
Apr 15 15:31:21 forneus load-modules.sh: 'platform:parport_pc' is not a valid module or alias name


I'm using udev 141-1 and the lastest stable kernel (2.6.29.1-3)
uname -a
Linux forneus 2.6.29-ARCH #1 SMP PREEMPT Wed Apr 8 12:47:56 UTC 2009 i686 AMD Athlon(tm) XP 3200+ AuthenticAMD GNU/Linux

I don't see any bug here. Anyone mind telling me what the problem is?

Well, I just thought that trying to load inexistent module such as 'dmi:bvnPhoenixTechnologies,LTD:bvrASUSA7N8X2.0DeluxeACPIBIOSRev1007:bd10/06/2003:svnASUSTeKComputerINC.:pnA7N8X2.0:pvrREV2.xx:rvnASUSTeKComputerINC.:rnA7N8X2.0:rvrREV2.xx:cvnChassisManufactture:ct3:cvrChassisVersion:' is some kind of a bug :)

Well, the kernel reports this as a device, and modprobe tries to find a matching module. You can see these by typing:
find /sys/devices -name modalias -exec cat {} \;

We should still discuss whether we might want to silence some of these messages.

Oh, now I see. Thank you for the explanation! May be it would be better then to move this lines from messages.log to errors.log?

@brain0: Yeah, I was thinking we could just remove the logger lines for errors (except blacklist messages, maybe) to "clean this up"

To be clear: this is not a bug. The kernel says "I have device ABC", and modprobe says "I have no idea what module to load for ABC, I'll just fail". If we start blocking these "errors", in the future when modprobe DOES know which module to load (say, you installed a package via pacman which contains the module), all the sudden, it won't be loaded. That's bad news.

Or, we could just change the -p option to logger such that those messages are only in the debug log - this would be a small change in line 49. I'd like the module/alias/dependency is blacklisted messages in the normal log though.

Any decision on this? like previous suggested by Roman/Thomas, just adding -p to sent to debug log. Otherwise I guess that this can be closed.

Final ping for a decision on this, otherwise I will close it on bug day in March 2010 as won't implement, it having been hanging around for a year.

Here is the patch, also fix "facility name".

Currently a message is logged to:
* everything.log, messages.log, user.log, debug.log (if enabled)

with this fix, "info" messages will be logged to:
* everything.log, messages.log

and "debug" messages (invalid alias...) will be logged to:
* everything.log, debug.log