Hide Forgot
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.
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.
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
So when you rebuilt your initrd, it was ok? Jon.
It was not 100%. Because after rebuilding initrd I ran accross bug #466296
Is this now resolved?
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).
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.
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.
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.
(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).
Created attachment 593148 [details] proposed upstream patch
Created attachment 593149 [details] proposed RHEL-5 patch
Upstream posting: http://marc.info/?l=linux-kernel&m=134018428502128&w=2
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.
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.
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