Red Hat Bugzilla – Bug 64469
Install of Skipjack Beta 2 with Grub over 7.2/Lilo results in unbootable system
Last modified: 2007-04-18 12:42:26 EDT
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
Steps to Reproduce:
1.Install 7.2 with lilo on /dev/sda MBR
2.Install 7.2.93 beta with Grub on /dev/sda1
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).
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.
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...
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.
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).
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