Bug 59761 - LILO doesn't replace pre-existing LILO
Summary: LILO doesn't replace pre-existing LILO
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-12 21:27 UTC by Megan Bock
Modified: 2007-04-18 16:40 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-20 17:07:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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 
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

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:
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.

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