Bug 64469 - Install of Skipjack Beta 2 with Grub over 7.2/Lilo results in unbootable system
Summary: Install of Skipjack Beta 2 with Grub over 7.2/Lilo results in unbootable system
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: anaconda (Show other bugs)
(Show other bugs)
Version: skipjack-beta2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-05 23:26 UTC by Tom Warfel
Modified: 2007-04-18 16:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-05-09 18:59:05 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 Tom Warfel 2002-05-05 23:26:22 UTC
Description of Problem:
I had previously had a working copy of RedHat 7.2 installed on a machine
using Lilo (installed on sda MBR) as the boot loader.  Wanting to try
skipjack, I installed and reformatted the drive, not preserving anything.
Mind you, I had forgotten I had installed lilo on MBR and not on sda1
when I set things up months ago.  So anyway, I chose "grub" as it is
now the recommended bootloader, and chose "install on first sector of
boot partition (/dev/sda1 (mounted as /boot)).  It seemed happy with that
choice, and we trundled through the lengthy search for disk errors, 
loaded the three CDs, and an hour or so later, when it rebooted, 
there was the old lilo prompt! Ack!  I could boot off the floppy,
but didn't see an easy way to get it to show the Grub loaded
installed on sda1 rather than the old MBR-loaded lilo.  The "boot
with DOS" was less than helpful, as I don't have MS-DOS, and when
I downloaded Caldera's DR-DOS 7.03, it's fdisk program says it
tried but failed to rewrite the MBR.

Version-Release number of selected component (if applicable):
Skipjack Beta 2 - i386

How Reproducible:

Steps to Reproduce:
1.Install 7.2 with lilo on /dev/sda MBR
2.Install 7.2.93 beta with Grub on /dev/sda1

Actual Results:
I can only boot from floppy.  Cannot get MBR to update, and doing
"grub" updates only update the version installed on the boot sector
of sda1 (which never gets run).

Expected Results:
I should have been presented with a warning _before_ the long 
(but futile) reformat and installation that my old bootloader
left its dregs on the MBR, and either 1) been given a means to
fix the MBR from within the installation program, or 2) been warned 
of the fact that installing GRUB (or lilo, for that matter) on sda1 
rather than the MBR would be futile and result in a non-bootable system.	

Additional Information:
I re-installed (with reformats and all) but this time pointed
grub to install on the MBR.  It all works as expected now, but it would
have been nice to have been warned of this at the time of install.
Had this been a real production machine instead of a test machine,
I'd be cursing mightily...

Comment 1 Doug Ledford 2002-05-06 20:50:55 UTC
This isn't really a lilo bug at all.  It's argueably not a bug at all (and
usually that's what we say).  The deal is, on a fresh install instead of an
upgrade, we don't know that there is lilo gunk on the MBR.  However, as often as
this particular problem has come up, I'm tempted to suggest that this be changed
from a bug report to a RFE (Request For Enhancement) in anaconda and make it so
that anaconda can detect exactly what is on the MBR of the boot drive during an
install and warn you if the boot loader setup you have selected will result in
an unbootable system.  I'm changing the component to anaconda so that the proper
people can reply to that suggestion.

Comment 2 Tom Warfel 2002-05-07 00:46:12 UTC
Thank you; that would be great. Intuitively (to me, anyway), 
a "clean install" should result in a bootable system, regardless
of how the components had been previously used.  If the machine
cannot make the system bootable, either some kind of warning 
saying "you better install on MBR instead of /sda1 because there's
junk there now that won't let it boot", or better yet, just
create a clean MBR (there are those of us who don't have a copy 
of MS-DOS floating around - and DR.DOS 7.03's fdisk didn't work).

Comment 3 Jeremy Katz 2002-05-09 20:43:58 UTC
That's why we clearly state in the help and on the screen that you need to
install to the same place.  Blowing away people's MBR without telling them is
completely unacceptable because it makes it difficult/impossible to do multiple
installs on the same machine or use alternate bootloaders not shipped in Red Hat

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