Bug 25834 - Failed to boot after successful installation
Summary: Failed to boot after successful installation
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lilo   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-03 03:16 UTC by Christopher Keller
Modified: 2007-04-18 16:31 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-08 23:09:03 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 Christopher Keller 2001-02-03 03:16:55 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)

During boot process, kernel hangs while probing IRQ devices

Reproducible: Always
Steps to Reproduce:
1. Boot
AMD Athalon Thunderbird 1.1Ghz CPU
512MB PC133 RAM
ASUS A7V Socket A Motherboard
(2) IBM UltraATA/100 Desktar Drives 30GB
Pioneer DVD 105S
Sony Espressa CD/RW
Soundblaster Live 5.1 Platinum

All latest BIOS patches applied. 

Unfortunately, it's impossible to get a screen dump as the system never 
actaully boots. However, if needed I can summarize the boot messages. It 
appears to hang after deteting the DVD drive (sucessfully).

This is the first Red Hat release that looks to support all the above 
hardware components without patching the kernel.

Comment 1 Christopher Keller 2001-02-03 17:32:10 UTC
The following setting caused the conflict/hang:
Both hard drives (master/slave) on primary ATA100 controller (Promise)
DVD drive (master) on secondary ATA100  controller
CD/RW (master) on primary IDE controller

Work around:
Both hard drives (master/slave) on primary ATA100 controller (Promise)
DVD & CD/RW  drive (master/slave) on secondary ATA100  controller

I'm assuming this is a bug as the original setting worked under Windows ME.

Comment 2 Arjan van de Ven 2001-02-05 12:25:31 UTC
Are you sure there isn't a "panic: cannot mount root-fs" message somewhere ?
And did the original configuration work with your own kernels ?
(if so, could you please include the output of "cat /proc/ide/pdc202xx"
and "cat /proc/ide/via" in the working case).

Comment 3 Christopher Keller 2001-02-05 17:28:23 UTC
Nope. No messages. Simply hung during the boot process during the IRQ
assignment. This was the first red hat release that I got working with my
hardware, so no other configuration worked.

I did re-arrange the perhipherals so that everything is running off the
UltraATA100 controllers; as I mentioned this seemed to eliminate the conflicts
and everything appears to be fine. I didn't go a good job summarizing above
(apologies, it was early), but the conflict was three devices on ATA100 and one
device on Ultra 66/33.

Comment 4 Christopher Keller 2001-02-07 04:49:35 UTC
I've re-arranged the peripherals again and am getting a similar error.

The A7V motherboard has 2 Ultra ATA/100 controllers and 2 IDE controllers.

I've placed a hard drive on each ATA controller (both master). I've placed the 
DVD drive on the primary IDE and the Sony CD/RW on the secondary IDE controller 
(again both master). So, basically, I'm utilizing all four controllers, each 
device being the only (thus master) device on the controller.

I re-loaded fisher onto the hard drive on the secondary UltraATA controller 
(primary houses Windows ME). Installation was flawless and all devices appeared 
to be recoginzed.

Now, when booting, LILO fails to start. I get an "LI" after the BIOS screens 
then the system simply hangs. However, if I boot of the linux boot floppy 
(created during install), the system seems to come up fine.

I've installed/uninstalled LILO a few times with similar results. During the 
load process, LILO was placed onto the Windows ME drive, as it's occupying the 
primary ATA100 controller.

Comment 5 Todd 2001-02-08 07:19:28 UTC
I'm seeing the same hang at LILO after *fresh* (/home was not reformatted)
fisher install

ABIT VP6 which similarly has 2 regular IDE and 2 ATA100 controllers. 

hda (master primary IDE) CDRW
hdc (master secondary IDE) hard drive
hde (master primary ATA) IBM UltraATA/100 Desktar Drives 30GB

/boot is /hde1    i.e. on the ATA100 controller.

I had had previous problems on same system doing upgrade from RH 7.0. lilo.conf 
was correctly edited by installer to reflect fisher changes hower /sbin/lilo 
did not seem to have been run.

Comment 6 Michael K. Johnson 2001-02-08 22:39:51 UTC
This is actually a lilo issue.

Comment 7 Jim 2001-02-08 23:08:59 UTC
I found the exact same thing on a ABIT KT7-RAID.  Uses the Highpoint 370 IDE 
chip. Same amount of memory, same CPU.  I was running two IBM 45GB Ultra-100 
IDE drives in RAID-0 mode.  It seems everything works fine if I boot with the 
floppy.  But when I boot from hard disk with lilo it hangs with "LI" in the 
bottom left of the display.  I did run "lilo -v -v" to ensure it being up to 

As a side note, a friend has the same KT7-RAID but only one drive running Ultra-
100 and he too had the same problem.

Comment 8 Doug Ledford 2001-02-09 11:03:14 UTC
These are lilo.conf issues.  Basically, even though linux thinks the drives are
in some particular order, the BIOS has them in a different order.  In order to
get things working properly, you've got to find the order that the BIOS has the
drives listed in, compare that to the order that linux finds the drives in, then
modify your lilo.conf file to reflect drive locations.  For example:

boot=/dev/hdc  /* if the BIOS finds /dev/hdc first, then put lilo on it */

disk=/dev/hdc  /* start a disk configuration block in the lilo.conf */
	bios=0x80  /* tell lilo that the BIOS sees /dev/hdc as /dev/hda */
	bios=0x81  /* tell lilo that the BIOS sees /dev/hda as /dev/hdb */

image=/boot/vmlinuz  /* /boot is on /dev/hda so we need the disk=/dev/hda */
	read-only    /* section above */

Thats typically enough to get the system booting properly.  Fixing the problem
any other way is beyond the scope of lilo changes because we can't read the BIOS
to tell what order it places the drives in once we have booted into 32 bit
protected mode.

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