Bug 49180

Summary: lilo picks wrong boot device during kickstart run
Product: [Retired] Red Hat Linux Reporter: Martin Lichtin <lichtin>
Component: anacondaAssignee: Brent Fox <bfox>
Status: CLOSED NOTABUG QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
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: 2001-07-18 15:22:31 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 Martin Lichtin 2001-07-16 17:20:21 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
My ks.cfg looks like:

lilo --location mbr
part / --size 3072 --asprimary --ondisk rd/c0d0p
part swap --size 1024 --asprimary --ondisk rd/c0d0p
part /tmp --size 1024 --asprimary --ondisk rd/c0d0p
part /var --size 1024 --ondisk rd/c0d0p

You can see that I only use one disk, /dev/rd/c0d0.
However, /etc/lilo.conf gets configured with:

boot=/dev/sda

It's true, I have a /dev/sda disk sitting in the machine, but the 
boot device should be set as

boot=/dev/rd/c0d0

right?

Looks like a bug in the way the boot device is chosen.


How reproducible:
Always

Steps to Reproduce:
1. Run kickstart with a /dev/rd/c0d0 and a /dev/sda disk
2. 
3.
	

Additional info:
Comment 1 Brent Fox 2001-07-18 15:22:27 UTC 
Weird.  I'm curious...if you were to specify a /boot partition in the kickstart
file, would that make a difference?

For example:lilo --location mbr
part / --size 3072 --asprimary --ondisk rd/c0d0p
part /boot --size 35 --asprimary --ondisk rd/c0d0p
part swap --size 1024 --asprimary --ondisk rd/c0d0p
part /tmp --size 1024 --ondisk rd/c0d0p
part /var --size 1024 --ondisk rd/c0d0p
Comment 2 Brent Fox 2001-07-28 15:47:21 UTC 
Closing due to inactivity. Please reopen if you have more information.