Bug 14818 - mkinitrd fails because it can't find percraid.o module
Summary: mkinitrd fails because it can't find percraid.o module
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-07-28 19:11 UTC by kevin_myer
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-07-28 19:11:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description kevin_myer 2000-07-28 19:11:48 UTC
I installed the Dell 2.2.16-4 kernel RPM today on a PowerEdge 4400.  First
kudos to Dell/Adaptec/Red Hat for getting that PERC driver GPLed - now I
won't have to wait for Dell's timetable to perform security upgrades (and
ironically, I just wrote a complaint email about that very fact earlier
this afternoon).  Anyways, the RPM is fine except when I attempt to create
my RAM disk with mkinitrd, it complains about not being able to find the
percraid.o module.  A quick symlink to aacraid.o fixed the problem and I
suppose it stems from the fact that /etc/conf.modules contains
scsi_hostadapter aliased to percraid.o.  It would be nice if there was
someway to automatically either create the symlink or modify
/etc/conf.modules to reflect the new name of the RAID module.

Comment 1 Michael K. Johnson 2000-08-01 19:20:18 UTC
I would hesitate to add re-writing logic for /etc/conf.modules
to our kernel RPM when we replace a proprietary module with
a free one -- there would then end up being no end to the
madness.  And adding that re-writing logic to /etc/conf.modules
would be the cleanest way to do it.

Comment 2 kevin_myer 2000-08-01 19:50:27 UTC
I agree that its probably not a good idea to have an RPM do this for you behind
the scenes.  My symlinking plan didn't work because upon reboot, modutils looked
for the module in /lib/ instead of /lib/2.2.16-4/scsi so what I ended up doing
was leaving /etc/conf.modules intact, and made a copy of aacraid.o and renamed
it to percraid.o.  Upon finding that the module loaded ok and everything worked,
I deleted the renamed module, changed my /etc/conf.modules and things are
running fine.

I didn't expect this bug to generate a kernel RPM modification - but it would be
nice if a change that affects the module that gets loaded to mount the root
filesystem is well documented (preferrably NOT in a Microsoft Word .doc format
if you have any input with the folks at Dell - vim still doesn't import Word
Documents ;)

Thanks for looking into it.

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