Description of problem:
All of Live CD, KDE Live CD, and Prime DVD hang at the initial
bootloader screen. This is on a Dell Dimension E520, dual-core
Pentium D, 1GB ram.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Insert CDROM/DVD
Bootloader screen displays, then machine completely hangs.
System boots and installer starts.
I just tried the Live CD on my Thinkpad T42p and it worked there
and did not hang.
More information, FC7 test2 live CD fails in the same way on the Dell
FC6 and RHEL5 install properly and do not hang at the DVD bootloader
screen on this system.
More information, FC7 test1 CD boots properly.
So whatever changed between test1 and test2 introduced the problem.
Syslinux upstream has added the following patch into the 3.3x branch:
I'm adding that into the FC-development rpm, so this
should be in tomorrows rawhide push,
Florian La Roche
This isn't obvious anywhere, but Fedora 7 test bugs should be filed against the
Thanks. I can't tell you how much time I spent trying to figure that
out, none of the fedora wiki, nor bug reporting pages, nor FC7 test
release notes gave any direction in this area.
Test4 still has this bug. So the patch from comment #4
doesn't fix the problem.
I've the same problen here with an asus board. The DVD starts, is loading the
kernel and the system hangs with the message "Ready". The installer starts if i
unplug the sata-drive!
I've forgot to say:
Both, F-6.93-i386-DVD.iso & F-6.93-i386-Live.iso have this problems. There are
no problem when no sata-drives are connectet. Also no problem with pata-drives.
Adding Dell folks.
davem and I have been trying to isolate the problem via email and irc. Using
newer syslinux, it appears the machine is not wedged -- with -2.fc7 the
countdown timer works.
What what we're seeing is a failure in the menus with either 'menu' or
'vesamenu'. If "prompt 1" is set, you get "boot:" correctly, and keyboard input
works fine. So the problem could be keyboard input in menu mode, or it could be
updating the screen, etc. (Dave, refresh my memory here - does the timeout keep
counting down if you hit a key in menu mode?)
The person in comments #8 and #9 is seeing a totally different bug.
That problem appears to be in the kernel, whereas the issue covering
this bugzilla has to do with the bootloader long before the kernel
is even loaded.
In response to Peter's comment #11, yes the counter keeps going down
even if I tap some keys and eventually the kernel boots when the
OK, so Jes has this happening on another Dell (A Woodcrest) with 4G of ram, and
I can reproduce it on an Intel SDV with 4G as well. Any chance you've got 4G of
ram, Dave? And if so, does it work with 2G?
I retract the bit about the SDV. I had unplugged the keyboard I normally use
while trying to reproduce this with a USB kbd yesterday. Works fine on the SDV
if your keyboard is plugged in.
(In reply to comment #12)
> The person in comments #8 and #9 is seeing a totally different bug.
> That problem appears to be in the kernel, whereas the issue covering
> this bugzilla has to do with the bootloader long before the kernel
> is even loaded.
Should I open a new bug report for that?
I was seeing the same problem on FC7test4 on a Dimension 490 Woodcrest
bug. Peter Jones provided me a modified boot image and I was able to
get it going.
However, the USB keyboard is not recognized in the boot loader, but
plugging in a PS/2 one did work. Not sure whats at fault here, but
the USB one worked fine once getting to the real installer gui.
(The modified boot.iso provided to Jes was the one with just the countdown timer
My machine has less than 4GB of ram, I think ram size is a red herring.
I think we need to keep digging at the keyboard intcall stuff in
the com32 code of syslinux.
I think you're right about the intcall stuff. I suspect Jes has usb emulation
turned off and was just seeing the other (timeout) bug. On Dell systems USB
emulation winds up being turned on while BIOS is running whether it's actually
enabled or not, so there's no way to tell without him checking.
You know, it'd be interesting to know if this happens with pxelinux as well --
and if it does, we can do a much simpler test case that doesn't require building
ISO images. Dave, I'll send you an email with details on how to set up such a
The guys from Dell say:
> It looks like we have a test BIOS in house (not yet released) that fixes
> this issue. I've reproduced the issue (with FC7 test3 DVD), and
> verified that the new BIOS fixes the issue.
> I don't have a very good description of the root cause right now, other
> than this broke when a different problem was fixed, so presumably an
> older rev of the BIOS might also work.
> Current BIOS version for Dimension e520 is 2.3.2. If you back it up
> three versions back to v.2.2.0, the problem should get fixed.
So it looks like this is a BIOS bug, and I'm going to close this BZ. Feel free
to reopen it if the need arises.