Bug 61027 - System fails to boot after install (Hampton beta1)
Summary: System fails to boot after install (Hampton beta1)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-03-12 14:37 UTC by Issue Tracker
Modified: 2007-04-18 16:40 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-03-18 14:58:59 UTC
Embargoed:


Attachments (Terms of Use)

Description Issue Tracker 2002-03-12 14:37:04 UTC
Description of Problem:

After completing install Hampton beta 1 the system stops on reboot with: 

Booting linux.......... 
Boot loader: LILO 
Tried booting CD to rescue mode to repair, same result. 

System: DL760 
Mem: 5GB 
Boot controller: Integrated Array 
Root disk: 9GB RAID0 

Boot loader: Tried GRUB and LILO 
Version-Release number of selected component (if applicable):


How Reproducible:


Steps to Reproduce:
1. 
2. 
3. 

Actual Results:


Expected Results:


Additional Information:

Comment 1 Jeremy Katz 2002-03-13 19:57:28 UTC
What drives are in this system?  Also, does the same thing happen with Hampton
beta 2?  (Hampton beta 1 and beta 2 are drastically different installer code bases)

Comment 2 Jay Turner 2002-03-21 03:29:17 UTC
Can I close this out since we have moved away from the Beta 1 installer?

Comment 3 Michael Fulbright 2002-03-21 16:12:38 UTC
We should drop this unless its a problem with the later Hampton betas.

Is this a problem with beta 3?

Comment 4 Bill Nottingham 2002-03-26 17:36:00 UTC
We really need some sort of response on this, or we will be forced to close it.

Comment 5 Norm Murray 2002-03-29 02:57:07 UTC
Attempted install of beta 2.  Did it (a) once on the third virtual disk of a
18.2 gig divided into 3, and (b) did it the second time on a 4 gig.  In both
cases, I was able to complete the install. For both tests I used the same server.

In (a), I had a GRUB loader on the first disk and configured it with all the
necessary information to boot the 3rd and attempted booting it several times
without success.  Each time it would try to load the kernel image, it would say
it was corrupt.

In (b) I wanted to eliminate any wierdness induced by the 3-disk split scenario
so I used a single 4 gig SCSI.  Again, the install completed w/o error, but when
I attempted to boot, not even the GRUB loader would load.

Comment 6 Michael Fulbright 2002-04-04 20:09:06 UTC
Are you booting from a SCSI drive attached to a SCSI controller, or from a
hardware RAID device?

Is one of these machines available in our Raleigh office so we can work on it?




Comment 7 Jay Turner 2002-04-16 16:00:24 UTC
Really need to get some feedback on this tao.  We are getting really close to
freeze and need to know if this is still an issue or not.

Comment 8 Norm Murray 2002-04-24 15:53:30 UTC
Updates: 

With beta 4 the first boot of the OS fails differently than with beta 3. With
beta 4 the install completes to the embedded array controller w/o error. On
reboot the cursor flashes in the upper left corner of the screen and the system
will not boot.

Boot CD#1 using "linux rescue" on the command line. Allow the system to mount /
on /mnt/sysimage. Then chroot /mnt/sysimage. The /etc/lilo.conf shows:

boot=/dev/cciss/c0d0

Should be:

boot=/dev/ida/c0d0

After modifying the file and executing /sbin/lilo the system boots from the
embedded array controller as expected.

Configuration:
DL760 P46(10/08/2002) 2 x 700Mhz Xeon, 12GB RAM
Boot controller: ROC
Boot disk: 9GB RAID0 (8.5GB useable space)
slot 1: 10/100 NIC 82557/8/9
Slot 10: SA5312 fw1.86, 1 logical volume 560GB, RAID5
cciss version:2.4.5 (modified by Redhat)
cpqarray:2.4.5
kernel version: 2.4.18-0.13bigmem #1 SMP
/etc/redhat-release:  Red Hat Linux release 7.2.93 (Skipjack)

Comment 9 Jeremy Katz 2002-04-26 21:17:19 UTC
This is the ever-fun "can't determine x86 boot order" bug, then.  Milan has the
code to allow this to be specified (dupe of lots of other bugs from Compaq like
this)


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