Bug 14818 - mkinitrd fails because it can't find percraid.o module
mkinitrd fails because it can't find percraid.o module
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
Depends On:
  Show dependency treegraph
Reported: 2000-07-28 15:11 EDT by kevin_myer
Modified: 2008-05-01 11:37 EDT (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description kevin_myer 2000-07-28 15:11:48 EDT
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 15:20:18 EDT
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 15:50:27 EDT
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.