Bug 67939 - bootnet.img installer hangs after IP Configuration
Summary: bootnet.img installer hangs after IP Configuration
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: anaconda
Version: limbo
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks: 67218
TreeView+ depends on / blocked
 
Reported: 2002-07-04 15:49 UTC by Michael Eckhoff
Modified: 2007-04-18 16:43 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-07-10 03:35:15 UTC
Embargoed:


Attachments (Terms of Use)

Description Michael Eckhoff 2002-07-04 15:49:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 
1.0.3705)

Description of problem:
After booting the bootnet.img disk image in both graphical and text mode, the 
screen stays blue (with standard redhat header and command footer) after IP 
configuration.  Virtual consoles show that an ip address was receied and the 
network card was detected.  Same behaviour exists if you put in a static IP 
configuration.  Last message on message console says that the reverse lookup 
was successful.  Allowed system to sit for 7 hours with no results.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.  Boot bootnet.img disk
2.  Select graphical or text install
3.  Configure IP address (either by DHCP or static - doesn't matter)

	

Actual Results:  The 'Configure ip address' dialog goes away, the virtual 
console says that it got an ip address, gateway, etc. and the primary console 
stays blue for hours.

Expected Results:  Next stage of the installer.

Additional info:

Comment 1 Michael Fulbright 2002-07-10 00:36:07 UTC
What are the last few messages on VC3?

Comment 2 Michael Eckhoff 2002-07-10 03:33:47 UTC
Well, I made a new bootdisk off of the same .img that I did the first three
tries to check this, and it worked fine this time.  I'm starting to think now
that it was a bad write, although dd reported 2880 blocks written each time...

Unless you've had other reports of this, I'm going to now attribute it to bad disks?


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