Red Hat Bugzilla – Bug 129487
Unable to boot kernel on ANY Compaq system
Last modified: 2007-11-30 17:10:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a1)
Description of problem:
I have been unable to install or boot FC2, FC3T1, or devel using the
default kernels on ANY Compaq system that I have access to. The
Compaqs are DL360s, 1850's, and 4500s with SMART array controllers and
896 meg of RAM.
Simply booting the install loads anaconda, which then complains there
is not enough memory.
Supplying the simplified mem parameter never makes it to anaconda, and
errors out with the following:
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
VFS: Cannot open root device "LABEL=/" or unknown-block(8,3)
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on unknown-block(8,3)
map=exactmap map=640K@0 map=895M@1M
Now, the system simply stops after displaying "Uncompressing Linux...
OK, booting the kernel."
Note also that regardless of what root= options I've tried, I still
get a kernel panic in scenario 2.
I've also tried nousb, nopcmcia, noprobe, acpi=off, skipddc, in
multiple combinations without any benefit or difference in errors.
Strangely, if I replace the kernel on the install disk with one I've
built myself, I can get through the installation fine, but then cannot
boot the kernel that is actually installed by anaconda. Presumably, if
I were to boot via rescue and replace the installed kernel with mine,
I would be able to boot the system OK.
This has me flummoxed. If you need more info from the boot process,
let me know what items. Obviously, I'm not making it far enough in the
kernel panic scenarios to switch consoles to get the output of the
Version-Release number of selected component (if applicable):
kernel-smp-2.6.5-1.358 kernel-smp-2.6.7-1.478 kernel-smp-2.6.7-1.509
Steps to Reproduce:
1.Boot install CD on Compaq DL360, 1850, 4500
2.Fails as detailed above
Actual Results: Kernel panics or hangs. Detailed in comments.
Expected Results: Ability to install and boot Fedora Core on Compaq
Just to clarify, I've also tried the uniprocessor kernels with the
Also, a number of people have recommended a kernel parameter of
"ide=nodma" but that also made no difference.
Hmmm, tracking the boot sequence more closely, it looks as though the
Compaq Smart Array is not being detected by the default kernels in
Cores 1, 2, and 3T1.
If I replace the Fedora kernel with a custom one I've built, the array
is detected and everything boots fine.
OK, another update.
If I install the system using my custom kernel on the bootdisk, the
installed system still fails at boot up (even though the install went
Using suggestions from the mailing list, I booted via rescue mode from
my custom boot disk, chrooted to /mnt/sysimage, and verified that the
following lines were part of the /etc/modprobe.conf:
alias scsi_hostadapter cpqarray
alias scsi_hostadapter1 sym53c8xx
I then ran mkinitrd to rebuild the initrd for
kernel-smp-2.6.5-1.358smp. After doing this, I was able to boot
without any problem.
So, it looks as though there's something missing in the initrd that
ships with Fedora.
It looks as though EISA support may be missing from the kernel builds
for Fedora Core. This is probably a major problem if so, since nearly
all Compaq Proliants use EISA for add-on boards.
Just watching to see how this goes as i have a proliant system i want
to upgrade soon
I'll try to reproduce the problem on a Proliant 2500 here.
Hummmm, hardware trouble. Hopefully I'll be able to fix the 2500 and reproduce
the bug later ...
I have similar problems installing FC3 on a Compaq Proliant 2500R.
Linux kernels need "mem=exactmap" hacks on this hardware. Without
them, linux apparently only detects 640K, for reasons cited in bug
36940 and at http://www.cpqlinux.com/memory.html#METHOD3 -- the
issue's come up occasionally, as recently as bug 115668.
(I've successfully installed RH 6.0 and RH 7.0 on the Proliant 2500R
using the "mem=exactmap" hacks. On my system, with 448M of RAM, the
exact line is "mem=exactmap mem=640K@0M mem=447M@1M".)
However, those hacks stopped working, perhaps with the 2.6 kernels.
See bug 36940, comments 35-37. Since bug 36940 started with RH 7.1,
the bug was closed with "not supported" boilerplate, which sidesteps
the issue. Since it affects FC3 though, it's still a current bug.
As above: When I try to install FC3 *without* using a "mem=..." trick,
it loads the kernel, but complains about not having enough memory.
Also as above: When I try to install FC3 *with* the "mem=..." trick,
it hangs on "Uncompressing Linux... OK, booting the kernel."
This all makes me think it's unrelated to the EISA problem, since the
kernel at least loads if you don't use the "mem=" trick.
Comment #2 above references the Smart Array not being detected.
There's a bug in kernels starting around 2.4.19 that affects EISA
Smart Array cards, I can reproduce it with my Smart 2/E.
See http://www.cpqlinux.com/cpqarray-eisa.html for more info. bug
75335 and bug 70311 also both reference this problem.
I'd *heard* that the fix for cpqarray would appear in the 2.6 kernel,
but I don't know that for sure -- it's one of the reasons I'm trying
to install FC3.
Eureka! This is apparently *not* a compaq-specific bug.
Just tested "mem=exactmap mem=128M@0M" on a Pentium II (asus P2L97,
i440LX chipset), with 128M RAM.
RH 7.0 install CD boots fine.
FC3 install CD locks up at "Uncompressing Linux... OK, booting the
Double eureka! I'm pretty sure this is a duplicate of bug 124312!
(I haven't *completed* an FC3 install, but I've definitely beaten the
"Uncompressing Linux... OK, booting the kernel." hang.)
Use the mem=exactmap syntax from scenario 3 above, but change mem= to
Could someone at Redhat put something about this in the FC release
notes for the next few releases? Something greppable about "exactmap"
or "mem=" that suggested trying "memmap" would have saved me a few asprin.
Another side note on the EISA Smart Array (cpqarray):
FC3 installs on a Proliant 2500R, with an EISA Smart Array.
changing "mem=" to "memmap=" is the fix.
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.