Bug 59761

Summary:	LILO doesn't replace pre-existing LILO
Product:	[Retired] Red Hat Linux	Reporter:	Megan Bock <mbock>
Component:	anaconda	Assignee:	Michael Fulbright <msf>
Status:	CLOSED RAWHIDE	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3
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:	2002-03-20 17:07:59 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 Megan Bock 2002-02-12 21:27:13 UTC

Description of Problem:
When installing Hampton beta 1 on top of a non Red Hat Linux 
installation and using LILO, LILO doesn't replace the pre-existing LILO, and system will not 
boot. Note: all partitions were reformatted during installation. 

Two variations 
observed:
Variation #1: Boot shows other distro's splash screen (or text prompt) and then goes 
into the Red Hat interactive startup, where numerous items fail. System then hangs on "Starting 
system logger" for several minutes and eventually goes into an endless cycle of apmd[549] and 
INIT: Id <number> respawning too fast: disabled for 5 minutes.

Installing Red Hat with LILO 
again does not resolve problem.

Variation #2: Boot hangs at LI or LIL

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


How Reproducible:
Every time I install 
over another distro using LILO. Installations over another distro with Grub are fine. (Tested 
over two other distros on five systems.)

Steps to Reproduce:
1. Install Red Hat on top of 
another distro. 
2. Set mount points for and reformat *all* existing partitions.
3. Choose 
LILO as the boot loader.

Actual Results:
LILO used by previous installer comes up & system 
does not boot.
-- OR --
LI or LIL appears & system does not boot.

Expected Results:
System 
should boot.

Additional Information:

Comment 1 Doug Ledford 2002-02-13 22:19:58 UTC

Unfortunately, this sounds like user error.  From your description, I would
surmise that the "other distro" is setup to install lilo on the master boot
record, and when you are installing the Red Hat product, you are selecting lilo
but you are *not* selecting to install it on the master boot record.  This
leaves the master boot record pointing to a now non-existing lilo second stage
boot loader, resulting in failure when it tries to load stuff up.  Since we
aren't upgrading and existing Red Hat linux installation, we can't determine if
you previously used the master boot record for lilo or not, so it is up to the
user to specify the correct setup for going over their previous installation. 
If this isn't the case, then reopen the bug with more details about which lilo
installations are using the master boot record and which ones aren't.

Comment 2 Megan Bock 2002-02-14 14:57:36 UTC

"I would surmise that the "other distro" is setup to install lilo on the master boot record, and 
when you are installing the Red Hat product, you are selecting lilo but you are *not* selecting to 
install it on the master boot record."

Yes, other distros were set up to write LILO to MBR, but 
in each case when I installed Hampton I selected it to install on the MBR as well. IE, *all* 
installations of LILO are written to MBR.

New Information:
I tried installing Hampton 1 
over a Red Hat 7.2 installation. The 7.2 had GRUB installed, and I again reformatted all 
partitions and chose LILO (writing to MBR) for Hampton. The new Hampton installation booted, but 
it booted using GRUB. I did this twice with the same results both times.

Comment 3 Doug Ledford 2002-03-20 17:07:54 UTC

Then this isn't a lilo problem (lilo simply does what it is told to do, it is up
to the install code to write a correct lilo.conf during installation).  Changing
package and owner to the proper package.

Comment 4 Jeremy Katz 2002-03-24 07:03:52 UTC

There were problems with partition tables not being properly reread in Hampton
beta1.  If you see this in later betas, please reopen.