Bug 59100

Summary: Installer fails to run lilo succesfully
Product: [Retired] Red Hat Linux Reporter: Julian Gough <jgough>
Component: installerAssignee: Michael Fulbright <msf>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-01-30 23:28:19 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 Julian Gough 2002-01-30 23:28:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.17-0.12custom i686)

Description of problem:
During the install process,  for a dual boot system containing windows, if you
type a name with a space for windows,  then lilo.conf is misconfigured and lilo
does not run.  When you reboot it goes straight to windows ... no linux!!!  and
no lilo.
Probably behaves badly if you put a space in any label but I have not tested
this.

This may seem like a trivial and unlikely problem, but nowhere does it say there
must be no spaces, and an inexperienced user could easily be stumped by this. 
There are no error messages,  and the result is fatal.

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


How reproducible:
Always

Steps to Reproduce:
1.Install redhat 7.2 from cd onto a pre-partitioned disk already containing
windows
2.type in a label for lilo for windows with a space in it
3.end installation
	

Actual Results:  Lilo not installed,  does not boot.

Expected Results:  An error message should be generated, or better still no
spaces should be allowed to be entered as lilo labels during install.  It should
not allow exiting the installer without succesfully running lilo.

Additional info:

Comment 1 Jeremy Katz 2002-02-01 06:14:19 UTC
This is already fixed for future releases