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): module-init-tools-3.3-0.pre3.1.36.el5 How reproducible: Always Steps to Reproduce: 1. install system with encrypted swap or root 2. boot system 3. 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
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!
*** Bug 468913 has been marked as a duplicate of this bug. ***
I'm no longer seeing this load failure with module-init-tools-3.3-0.pre3.1.42.el5.
I just installed snap3 and still see this error. Guess it went into snap4, not snap3.
Snapshot 3 includes module-init-tools-3.3-0.pre3.1.42.el5 so appears this is still a problem. Flipping back to Assigned.
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.
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. Jon.
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.
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.
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.
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.
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. http://rhn.redhat.com/errata/RHBA-2009-0093.html