Bug 458134 - insmod error from padlock.ko
insmod error from padlock.ko
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: module-init-tools (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jon Masters
: 468913 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-08-06 12:23 EDT by David Lehman
Modified: 2009-01-20 15:54 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 15:54:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0093 normal SHIPPED_LIVE module-init-tools bug fix and enhancement update 2009-01-20 11:04:29 EST

  None (edit)
Description David Lehman 2008-08-06 12:23:49 EDT
Description of problem:
insmod is issuing an error (ENODEV) on i386 when no VIA padlock device is present. This will inevitably scare a great many customers using the newly available block device encryption functionality.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install system with encrypted swap or root
2. boot system
Actual results:
insmod: error inserting '/lib/padlock.ko': -1 No such device

Expected results:
Either no message at all or something less scary.

Additional info:
Fixed for F9 in bug 442190
Comment 4 Denise Dumas 2008-10-29 11:44:38 EDT
Since encrypted block devices are a shiny new feature for 5.3, it would be really nice if using them did not result in a scary ugly message for our customers. But if this does not make 5.3, it minimally needs a release note!
Comment 9 Prarit Bhargava 2008-11-11 08:36:23 EST
*** Bug 468913 has been marked as a duplicate of this bug. ***
Comment 12 Jay Turner 2008-11-12 10:03:42 EST
I'm no longer seeing this load failure with module-init-tools-3.3-0.pre3.1.42.el5.
Comment 13 Tim Burke 2008-11-17 13:29:24 EST
I just installed snap3 and still see this error.  Guess it went into snap4, not snap3.
Comment 14 Jay Turner 2008-11-17 15:10:27 EST
Snapshot 3 includes module-init-tools-3.3-0.pre3.1.42.el5 so appears this is still a problem.  Flipping back to Assigned.
Comment 15 Jay Turner 2008-11-18 07:08:44 EST
I just booted up my system again with module-init-tools-3.3-0.pre3.1.42.el5 and even with "quiet" mode disabled, I don't see any messages on boot about the padlock module.  I do get the following message in syslog, but I don't consider that a serious problem.

Nov 18 07:01:48 haring kernel: padlock: VIA PadLock not detected.

Tim, what are you seeing?  I just wanted to make clear there appears to be different behavior across a few machines.
Comment 20 Jon Masters 2008-11-18 12:00:46 EST
Tim, which version of module-init-tools do you have installed?

$ rpm -q module-init-tools

Should tell us you have 3.3-0.pre3.1.42.el5, which has the fix. Otherwise, I'll see if I can look at your laptop later this pm and see what else it might be. If it's happening in the initrd, it's not module-init-tools but mkinitrd at fault.

Comment 22 Jay Turner 2008-11-19 08:08:58 EST
With Snap3 I'm no longer seeing the messages I was getting.  That's true.  But as you can see from comment 19, I'm wondering if the difference is I'm being prompted for the passphrase by initscripts and Tim might be getting prompted by the initrd.  I'm trying a test on a test box currently and will report what I find.
Comment 23 Jay Turner 2008-11-19 09:13:12 EST
OK, have a root-cause to Tim's problem.  It is indeed the initrd which is producing this error.  Since we're calling "insmod /lib/padlock.ko" in the initrd the only true solution is to not write that command to the initrd.  In other words, squashing the message in module-init-tools correctly solves the situation where initscripts takes care of LUKS.  The initrd issue is a totally separate defect therefore I'll clone to another issue and move this one back to Verified.
Comment 24 Jon Masters 2008-11-20 10:38:28 EST
Yeah, we need another bug for the mkinitrd problem. It's the version of "module-init-tools" in mkinird that's got the problem. Actually, it's not so much that we shouldn't write the insmod into the initrd, it's that the initrd should handle this more cleanly - Fedora does, but RHEL5 might not be able to at this point.

Alternative options include turning off the module, a release note, or modifying the module not to error out on lack of hardware. See other BZ.
Comment 25 Jay Turner 2008-11-20 11:08:36 EST
Just a note since it appears BZ no longer includes a comment for a cloned bug, bug 472227 was created the track the mkinitrd defect.
Comment 27 errata-xmlrpc 2009-01-20 15:54:08 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.