Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#27623 - [linux] (Boot Message) - modprobe WARNING: Error inserting padlock_sha - (Should Be Silent)

Attached to Project: Arch Linux
Opened by Das (DasFox) - Monday, 19 December 2011, 07:29 GMT
Last edited by Tom Gundersen (tomegun) - Thursday, 22 December 2011, 08:27 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
modprobe WARNING: Error inserting padlock_sha
(/lib/modules/3.1.5-ARCH/kernel/drivers/crypto/padlock-sha.ko.gz no such device

Additional info:
* package version(s)
Arch x86, Kernel 3.1.5

* config and/or log files etc.
/etc/rc.conf
MODULES=(fuse aes twofish dm_crypt)

/etc/fstab
/dev/mapper/swap swap swap defaults 0 0

/etc/crypttab
swap /dev/sda3 SWAP -c twofish-xts-essiv:sha256 -s 512

/var/log/messages;
padlock_sha: VIA PadLock Hash Engine not detected.


Steps to reproduce:
When I boot Arch it would give me a warning in /var/log/boot;

modprobe WARNING: Error inserting padlock_sha
(/lib/modules/3.1.5-ARCH/kernel/drivers/crypto/padlock-sha.ko.gz no such device

I'm not sure if this is a bug but it would seem that if it doesn't need something
then it shouldn't be trying to load it or give a warning and tell the end-user during bootup, it should simply be silent.

So hopefully we can get this fixed for no warning messages appearing...

In the meantime I added to /etc/modeprobe.d/ (This works, but it seems like a bandaid approach)
blacklist.conf
blacklist padlock-aes
blacklist padlock-sha


THANKS


This task depends upon

Closed by  Tom Gundersen (tomegun)
Thursday, 22 December 2011, 08:27 GMT
Reason for closing:  Upstream
Comment by Jelle van der Waa (jelly) - Monday, 19 December 2011, 09:18 GMT
Read https://bbs.archlinux.org/viewtopic.php?id=43705
Also errors shouldn't be silent, they should be fixed instead.
Comment by Das (DasFox) - Monday, 19 December 2011, 12:17 GMT
Silence it, fix it, whatever you want to call it, the point I'm trying to make is it shouldn't be giving the end-user a warning especially when you don't even use the module...

It gives me a warning it can't load/find it, well I don't even use this, so it should not be happening...

I said I did this already; (This works, but this is a bandaid/duck tape approach, we shouldn't be needing to blacklist it, if you hardware doesn't use it, then no warnings, no need to blacklist, etc...

/etc/modeprobe.d/
blacklist.conf
blacklist padlock-aes
blacklist padlock-sha
Comment by Das (DasFox) - Monday, 19 December 2011, 12:18 GMT
TYPO before;

if your hardware doesn't use it, then we should get no warnings and no need to blacklist, etc...
Comment by Thomas Bächler (brain0) - Monday, 19 December 2011, 13:37 GMT
As long as 'sha256-all' and 'sha1-all' are aliases of padlock-sha and 'aes' is an alias of padlock-aes, there is no possibility to silence the message or fix this, other than blacklisting the modules. The same goes for aesni-intel, which has 'aes' as an alias.

Deal with it.
Comment by Das (DasFox) - Wednesday, 21 December 2011, 20:00 GMT
  • Field changed: Percent Complete (100% → 0%)
Please allow me to make one last comment to make a suggestion on how something like this might be worked in Arch...

Thanks
Comment by Tom Gundersen (tomegun) - Wednesday, 21 December 2011, 20:09 GMT
@Das: I guess this needs to be fixed in the kernel, and as far as I know module loading based on cpu is being worked on, and might possibly help this issue (I'm not sure about that though). In the meantime, I don't see what we can do. We want to see any and all warnings, if for no other reason than to prompt them being fixed properly (in this case in the kernel).
Comment by Das (DasFox) - Wednesday, 21 December 2011, 23:30 GMT
Hi,

I know we want warnings and messages when they apply, but I don't believe in a case like this, it should apply.

Why should the kernel be warning someone about a module their hardware doesn't even use?

The system should be made that it probes and when it doesn't find what it wants, if you hardware doesn't need it, then it should be silent, or if the developers feel like for all situations you can never fix everything and the end-user will have to take some sort of action from time to time, like blacklist something, then it might be nicer in those situations, maybe the Arch team could create a specific log for such a purpose, like /var/log/alert. Then instead of seeing all sorts of errors spewing across the screen we would just see a message at bootup like, 'See: Alert Log', or anything else to this affect...

This might be a nice idea for the Arch team to consider doing something like this anyways, so any and all messages where there is something not correct, improper hardware support, something not configured correctly, etc., etc., any and all things would simply go in this /var/log/alert. I don't know about you, but this would really make it nice to track down stuff, rather then having to read through all of the other logs hunting for a problem...


THANKS
Comment by Tom Gundersen (tomegun) - Thursday, 22 December 2011, 08:27 GMT
@Das: What you describe could be possible through some hacks in initscripts, but we don't really do that kind of thing (hacks).

I agree that the warning should not be shown for hardware you don't have, but the solution is not to somehow hide it away. Rather, we should not attempt to load the module in the first place. The proper solution for this would be to fix the modaliasing in the kernel. This should be solved upstream in the kernel and not by us, as it is not at all a trivial problem. So I suggest we either wait for the kernel people to deal with it, or you could try taking this problem to lkml.

Loading...