Bug 344841

Summary: fails if data entered wrong
Product: [Fedora] Fedora Reporter: Ray Todd Stevens <raytodd>
Component: anacondaAssignee: David Cantrell <dcantrell>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 7   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-12 03:01:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ray Todd Stevens 2007-10-22 02:23:27 UTC 
Description of problem:

During a cdrom upgrade and cdrom install both if you enter wrong data in the
section which contains the server name and directory fields it will come back to
this screen and allow you to reenter the data, but:

a.   It does so without a message telling you why

b.   And this is the biggee it will not then work even if you enter the data
corectly.


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


How reproducible:

100%

Steps to Reproduce:
1.   cdrom boot
2.   select network install (http as ftp is still not working)
3.   enter the network information.  This is fixable if you get it wrong.
4.   enter bad data in either the server of directory fields.
5.   The system works for a while then returns to the entry screen for the
server and directory
6.   enter correct data
7.   The system then hangs on loading stage 2
  
Actual results:


Expected results:


Additional info:

This seems to be pretty independent of a set of hardware.  If "works" with 

fresh install
new install on existing system
upgrade

scsi and ide drives and mix of the two

1 drive
multiple drives
lvm or no lvm
Comment 1 Ray Todd Stevens 2007-11-20 19:18:33 UTC 
This same problem exists in fc8
Comment 2 Ray Todd Stevens 2008-02-18 16:08:17 UTC 
I just checked, and this is fixed in 9-Alpha

I assume that would be a reason to close this one.