Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 26992 - aacraid 2.2.17-14 2gb not bootable
aacraid 2.2.17-14 2gb not bootable
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
i386 Linux
low Severity low
: ---
: ---
Assigned To: Michael K. Johnson
Brock Organ
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2001-02-10 17:31 EST by Josko Plazonic
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-10 17:31:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Josko Plazonic 2001-02-10 17:31:15 EST 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)


2.2.17-14smp kernel rebuilt with following changes: 2GB max mem rather 
than 1 (as the machine in question has that much memory), add NFSv3 
patches meant for 2.2.17.  Installed the kernel on PowerEdge 4400 where 
filesystem is on raided drive (Perc 3/di, aacraid/percraid driver), built 
the initrd image.  Would not use initrd image, ever (not even echo msgs in 
initrd image that should be displayed before attempted modprobe) and 
therefore kernel cannot proceed as it cannot access raided hard drives.  
The delay while decompressing initrd seems to be there but no actual use 
of files in initrd image.  The same config used on a floppy again does not 
boot on the server but the same floppy will attempt inserting the module - 
and fail as other machines do not have perc raid card but module will show 
detection failure msgs.  

Reproducible: Always
Steps to Reproduce:
1. Rebuild 2.2.17-14smp with NFSv3, 2GB (as rpm).
2. Install rpm (-ihv), build with mkinitrd (2.2.17-14smp... ) initrd 
image, correct lilo.conf, lilo.
3. Reboot and watch the failure occur on PowerEdge 4400 w/ 2GB, Perc 3/di, 
dual cpu.


We had to revert back to 2.2.16 from Dell's support website (patched and 
rebuilt with NFSv3, 2GB mem and latest security patches) which I 
understand was prepared with RedHat's help.  This kernel worked perfectly 
(version without latest security corrections had 187 day uptime - again, 
custom rebuilt by us to include NFSv3 and 2GB support - brought down to 
apply 2.2.17-14...).  As this is production machine we didn't have time to 
try redhat's original 2.2.17-14 to see if 1GB to 2GB memory change had 
anything to do with the problem but I strongly suspect it does (NFSv3 
patch should have nothing to do with this) or if even 2.2.17-14 has 
problems with this hardware config (note that the same floppy with 
appropriate config worked on different machines with less mem and no raid 
drive - raid drive shouldn't matter as it didn't reach inserting of module 
so then either memory or smp should be show stoppers).  Oh yes, rebuilding 
done on uptodate redhat 6.2 machine.
Comment 1 Josko Plazonic 2001-05-17 21:21:47 EDT 
Not relevant anymore - fixed it with custom 2.2.19-6.2.1 - again modified for 
2GB memory (plus other fixes for NFS like smp fix) AND made sure this time 
BIGMEM is on as that was very very probably the problem last time (since only 
if BIGMEM is on relocate_the_initrd_before_kernel_overwrites_it fix is used 
even though the patch is always applied - uh those #ifdefine's...).  New rpm's 
worked without any problems and machine has been up and running fine so far (2 
days and going...) - including working aacraid (therefore initrd) and full 2gGB 
of mem.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.