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
Opened by Das (DasFox) - Monday, 19 December 2011, 07:29 GMT
Last edited by Tom Gundersen (tomegun) - Thursday, 22 December 2011, 08:27 GMT
|
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
Thursday, 22 December 2011, 08:27 GMT
Reason for closing: Upstream
Also errors shouldn't be silent, they should be fixed instead.
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
if your hardware doesn't use it, then we should get no warnings and no need to blacklist, etc...
Deal with it.
Thanks
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
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.