Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 466296

Summary:	When enabling full disk encryption, some modules are loaded twice in initrd
Product:	Red Hat Enterprise Linux 5	Reporter:	Gary Case <gcase>
Component:	mkinitrd	Assignee:	Peter Jones <pjones>
Status:	CLOSED WONTFIX	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.4	CC:	atodorov, benl, ddumas, syeghiay
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	When using an encrypted device, the following error message may be reported during bootup: insmod: error inserting '/lib/aes_generic.ko': -1 File exists This message can safely be ignored.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-07-01 22:05:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	454962

Description Gary Case 2008-10-09 16:13:32 UTC

Description of problem:
When the initrd is created during RHEL5.3 install, the aes_generic.ko file is loaded twice. This generates a harmless (but troubling) error message on boot:

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

If you look at the init file in the initrd package, you see the cause of the problem:

echo "Loading aes-x86_64.ko module"
insmod /lib/aes-x86_64.ko
echo "Loading aes_generic.ko module" 
insmod /lib/aes_generic.ko            <-- 1st load request
echo "Loading aes_generic.ko module"
insmod /lib/aes_generic.ko            <-- 2nd load request
echo "Loading crypto_api.ko module"
insmod /lib/crypto_api.ko


Version-Release number of selected component (if applicable):
RHEL5.3 20081006.0 build

How reproducible:
Every time the system boots.

Steps to Reproduce:
1. Install RHEL5.3, checking the disk encryption checkbox
2. Boot system
3. Error appears 
  
Actual results:
Error appears on screen, then boot continues normally.

Expected results:
No errors.

Additional info:

Comment 1 David Lehman 2008-10-09 16:47:10 UTC

Anaconda doesn't do anything special with mkinitrd. In fact, it doesn't even directly call mkinitrd.

Comment 2 Gary Case 2008-10-09 22:41:47 UTC

In the 32-bit arch, the insmod and echo lines for the /lib/padlock.ko module are duplicated but the aes_generic.ko line only appears once.

Comment 4 Denise Dumas 2008-12-02 20:08:39 UTC

Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
This release note is for 5.3.

When using an encrypted device, you may see the following error message on boot:
insmod: error inserting '/lib/aes_generic.ko': -1 File exists

This message is harmless and can be ignored.

Comment 6 Ryan Lerch 2008-12-02 23:11:39 UTC

Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1,6 +1,5 @@
-This release note is for 5.3.
+When using an encrypted device, the following error message may be reported during bootup:
 
-When using an encrypted device, you may see the following error message on boot:
 insmod: error inserting '/lib/aes_generic.ko': -1 File exists
 
-This message is harmless and can be ignored.+This message can safely be ignored.

Comment 7 Denise Dumas 2009-06-30 20:48:48 UTC

Moving to RHEL 5.5 so it doesn't get mistakenly closed by the bot

Comment 8 Alexander Todorov 2009-08-24 07:42:53 UTC

Denise,
isn't this one a duplicate of bug #472227 ? At least they are quite close.

Comment 9 RHEL Program Management 2010-07-01 22:05:00 UTC

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.