Bug 678096

Summary: insmod: error inserting '/lib/padlock..ko' : -1 No such device
Product: Red Hat Enterprise Linux 5 Reporter: Murilo Opsfelder Araujo <mopsfelder>
Component: kernelAssignee: Laszlo Ersek <lersek>
Status: CLOSED ERRATA QA Contact: Cui Chun <ccui>
Severity: low Docs Contact:
Priority: low    
Version: 5.6CC: azelinka, ccui, ddumas, herbert.xu, jcm, jreed, lersek, mopsfelder, ngalvin, rhod, syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-08 04:14:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 807973    
Attachments:
Description Flags
proposed upstream patch
none
proposed RHEL-5 patch none

Description Murilo Opsfelder Araujo 2011-02-16 17:28:46 UTC
Description of problem:
insmod is issuing an error when no VIA padlock device is present.

This issue has been reported in the past (bug #458134) but it is still
present on Red Hat 5.6.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=458134

Version-Release number of selected component (if applicable):
# rpm -q module-init-tools
module-init-tools-3.3-0.pre3.1.60.el5_5.1

How reproducible:
Always.

Steps to Reproduce:
1. Install RHEL 5.6 with encrypted block devices.
2. Boot system.
3.

Actual results:
padlock: VIA PadLock not detected.
insmod: error inserting '/lib/padlock..ko' : -1 No such device

Expected results:
Only message "padlock: VIA PadLock not detected." should appear.

Comment 1 Jon Masters 2011-02-17 17:08:53 UTC
Hello,

Thanks for the bug report. Can you tell me why you think this is a bug in module-init-tools? We did include a fix for this, which was tested. Does this only happen on boot? For example, if you try to manually load the kernel encryption modules, do you see this problem? I suspect it is an initrd issue, but let's find out.

Jon.

Comment 3 Murilo Opsfelder Araujo 2011-02-17 23:22:28 UTC
Hi Jon,

my first shot was that this could be an issue with initrd. But Red Hat
has been released an errata in the past claiming they have fixed this in
module-init-tools. See http://rhn.redhat.com/errata/RHBA-2009-0093.html

I've regenerated my initrd image:

# cd /boot
# mkinitrd -f my_initrd.img `uname -r`

and it worked partially. Because during boot, I ran across another bug:

insmod: error inserting '/lib/aes_generic.ko': -1 File exists

that has already been reported in bug #466296 (also happening on RHEL
5.6 64-bit). See https://bugzilla.redhat.com/show_bug.cgi?id=466296

Murilo

Comment 4 Jon Masters 2011-02-23 04:41:27 UTC
So when you rebuilt your initrd, it was ok?

Jon.

Comment 5 Murilo Opsfelder Araujo 2011-02-23 12:40:38 UTC
It was not 100%. Because after rebuilding initrd I ran accross bug #466296

Comment 6 Jon Masters 2011-05-26 21:54:22 UTC
Is this now resolved?

Comment 7 Murilo Opsfelder Araujo 2011-09-05 17:59:21 UTC
Hi Jon,

Sorry for the long delay to reply you but we were waiting for RHEL 5.7.

This is still happening on RHEL 5.7 (kernel 2.6.18-274.el5).

Comment 9 RHEL Program Management 2012-02-21 00:27:18 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 10 RHEL Program Management 2012-04-02 08:59:29 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 15 RHEL Program Management 2012-06-01 14:14:09 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 16 David Cantrell 2012-06-01 14:17:35 UTC
Reassigning to kernel.  The module should just print 'VIA PadLock not detected" if the device isn't detected, no need to have the failure returned to insmod.

Comment 17 RHEL Program Management 2012-06-01 14:43:14 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 20 Laszlo Ersek 2012-06-20 08:16:59 UTC
(In reply to comment #16)
> Reassigning to kernel.  The module should just print 'VIA PadLock not
> detected" if the device isn't detected, no need to have the failure returned
> to insmod.

Apparently this requires an upstream fix first. Related commits: c39cc377 (only removes the message, doesn't change the outcome) and 3bd391f0 (changes the way xcrypt support is detected, but not the outcome if it's absent).

Comment 21 Laszlo Ersek 2012-06-20 08:18:14 UTC
Created attachment 593148 [details]
proposed upstream patch

Comment 22 Laszlo Ersek 2012-06-20 08:18:45 UTC
Created attachment 593149 [details]
proposed RHEL-5 patch

Comment 25 Laszlo Ersek 2012-06-20 09:44:03 UTC
Upstream posting: http://marc.info/?l=linux-kernel&m=134018428502128&w=2

Comment 28 Ronen Hod 2012-07-23 20:51:48 UTC
Hi Linda,

Laszlo took this bug pretty much by mistake. He has no domain knowledge, and cannot even unit-test it. He doesn't even know who can review it.
Please reassign it to the adequate Kernel engineer.

Thanks, Ronen.

Comment 31 Cui Chun 2012-08-23 06:42:32 UTC
Reproduced in kernel-2.6.18-330.el5.i686 with encrypted block devices. The following message is shown:
----------
padlock: VIA PadLock not detected.
insmod: error inserting '/lib/padlock..ko' : -1 No such device
----------

Verified in kernel-2.6.18-336.el5.i686 according to BZ description request. Only message "padlock: VIA PadLock not detected." is shown, no "insmod: error inserting '/lib/padlock..ko' : -1 No such device" message again.

So this bug is fixed.

Comment 33 errata-xmlrpc 2013-01-08 04:14:37 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0006.html