Bug 65442 - installer crashed on cdrom #3 installing lilo
installer crashed on cdrom #3 installing lilo
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2002-05-24 01:09 EDT by Joe Acosta
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version: 9.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-09 00:13:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Comment (106.88 KB, text/plain)
2002-05-24 19:16 EDT, Joe Acosta
no flags Details

  None (edit)
Description Joe Acosta 2002-05-24 01:09:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510

Description of problem:
You'd think that the installer would be smart enought to ask if you have lilo or
grub.  I use grub

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

How reproducible:

Steps to Reproduce:
1. have a RH 7.2 system using grub to boot
2. upgrade to RH 7.3 <hit enter booting of the RH 7.3 cd #1>
3. when prompted what to do with the boot loader choose the first option which
suggests "update"
4. finish the update, and when you get to cdrom #3 and it is going to install
lilo (which it should not) it will crash with a python traceback. sorry I did
not keep it.

Additional info:

I'm not sure if all got installed by that time or what was missing.
Comment 1 Jeremy Katz 2002-05-24 13:40:50 EDT
Without the python traceback, it is nearly impossible to say what happened here.
   Could you please attach it?
Comment 2 Joe Acosta 2002-05-24 19:16:50 EDT
Created attachment 915019 [details]

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Comment 3 Jeremy Katz 2002-05-29 12:57:06 EDT
Interesting... so we thought you were using LILO when you were using GRUB? 
Could you attach the lilo.conf, grub.conf, and a dd of your boot block (`dd
if=/dev/hda of=file bs=512 count=1` if your boot device is hda)?
Comment 4 Joe Acosta 2002-05-29 22:46:04 EDT
here is lilo:


	append="init 1"

	append="init 2"

	append="init 3"




here is grub:

default 0
timeout 20
border AA00FF
splashimage (hd0,0)/boot/grub/custom_image.xpm.gz
#splashimage (hd0,0)/boot/grub/blueimage.xpm.gz
#splashimage (hd0,0)/boot/grub/splash.xpm.gz
# color is not used with splash image
#color white/black black/blue
title GNU/Linux Main kernel
kernel (hd0,0)/boot/vmlinuz-current root=/dev/hda1 ide2=noprobe
title GNU/Linux Main kernel quiet mode
kernel (hd0,0)/boot/vmlinuz-current root=/dev/hda1 vga=ask fastboot ide2=noprobe#
title GNU/Linux Main kernel vga ask
kernel (hd0,0)/boot/vmlinuz-current root=/dev/hda1 vga=ask ide2=noprobe
title GNU/Linux test kernel
kernel (hd0,0)/boot/vmlinuz-test root=/dev/hda1 ide2=noprobe
title GNU/Linux RH default
kernel (hd0,0)/boot/vmlinuz-2.4.7-10 root=/dev/hda1  ide2=noprobe
title GNU/Linux Main init 3
kernel (hd0,0)/boot/vmlinuz-current root=/dev/hda1 init 3 ide2=noprobe
title GNU/Linux Main init 2
kernel (hd0,0)/boot/vmlinuz-current root=/dev/hda1 init 2 ide2=noprobe
title GNU/Linux Main init 1
kernel (hd0,0)/boot/vmlinuz-current root=/dev/hda1 init 1 ide2=noprobe

Not sure what the dd of my boot block would do... but here it is .. there is no
way to upload a file to bugzill here...

Comment 5 Jeremy Katz 2002-06-04 11:40:18 EDT
We misdetected because your grub config doesn't have the magic bit that we look
for when anaconda writes out the config file and it still looks like you have
lilo installed on the bootblock (grub doesn't always clear those bits).  I've
added a check so that in the future at least if this happens, lilo will get
correctly installed.
Comment 6 Joe Acosta 2002-06-04 12:29:09 EDT
I think it would be better if you changed the GUI to make it more clear as to
what it was 'trying to do'.

Rather than just "assuming" that you detected things correctly it would be
better to prompt something like:  

Lilo was detected as your installed boot loader is this correct? 

then have ( yes / no / not sure ) radio buttons.  If they choose yes then you
can prompt: 
     1) reinstall LILO 
     2) update to grub 
     3) leave boot sector alone 

if they select no just move forward or you can prompt to install / update to grub

if they select not sure then you can default to whatever bootloader you want.  

Also if you detect a grub.conf it would be really bad to just ignore it because
it does not have the 'anaconda magic bit in it'.  This is especially true in an
upgrade.  As I am sure there are probably others out there that installed grub
after they installed 7.2, first testing out grub on a boot floppy then on the
live system.   

My issue was that I assumed that the boot detection thing detected my boot
sector correctly and it was not clear to me that it had detected lilo (the
message was vague).  I also KNOW that I have grub and would be really pissed off
if I upgraded my system and suddenly found out that the install changed my boot
setup to boot lilo instead of grub.

Lastly I read in release notes for 7.2 (I think) that lilo was going the way of
the dodo, if this is true then you should only be upgrading to grub.
Comment 7 Jeremy Katz 2002-06-04 12:44:06 EDT
Users in general don't know or care about what a bootloader is, and asking them
if we detected it right beyond what it currently does just makes things more
confusing in a lot of cases.   The screen very clearly says "The installer has
detected the %s boot loader" so I don't know how much more clear to make it.

The magic bits that aren't required for a stock grub configuration because you
don't have to have them to boot, but unfortunately, we have to have it to know
where you installed the boot loader.

And yes, lilo is on the way out, but there are a couple of cases where people
have to / prefer to use lilo still and just replacing their bootloader for them
on an ugprade is the wrong thing to do.
Comment 8 Joe Acosta 2002-06-04 13:23:39 EDT
"just replacing their bootloader for them on an ugprade is the wrong thing to do."

Hmm we both agree that replacing <boot loader x (in my case grub)> with <boot
loader y (in this case lilo)> on an upgrade is also a bad idea.

Yes I do remember seeing lilo there somewhere, however the item that I thought I
was selecting was 'upgrade boot loader' thinking that it would upgrade my
current boot loader to grub (or a newer version of grub) not a newer version of
lilo (and failing at that). Having read the release notes of 7.2 knowing that
lilo is going away I was under the impression that it would have been grub. (doh!)

This sounds like a grub / lilo issue at this point?

I was under the impression that grub would overwrite the lilo boot data which is
why I was suprised that it actually said lilo in the installer. I figured that
it was just another bug in the install.

Is there any OTHER way to detect grub is installed other than the 'magic bits'?
 Also since it is possible that others have upgraded to grub after an install
(which means you could really piss off some people in the future) is there any
way to get those magic bits there so that they(I) can prevent this in the future?

While it it true that most people dont care about a boot loader it is also true
that getting LI when the system boots is a bad things (this is why I dislike
lilo and like grub).  It is also true that Redhat does have users out there that
do know the difference between grub and lilo.

Comment 9 Jeremy Katz 2002-06-04 14:49:18 EDT
Yes, and those users can in theory read what is presented to them, see that it
is incorrect and not let it continue.  There is no way at all for me to be able
to guess between all of the permuatations of master boot records and boot
partitions where your boot loader might be installed and there's nothing in the
grub config file by default to point it out.  So anaconda writes a comment in
there (note that we always write a grub config out, even if we install lilo as
the bootloader) that it then later looks at the be able to install the boot loader.

The comment that we look for is of the form

anywhere within the config file.  Then we go spelunking through the boot sector
and actually make sure it has a grub signature.  If so ==> using grub.  If not,
check lilo.conf; do similar for the boot sector pointed to there and see if it
has a lilo signature.  If so ==> using lilo.  Unfortunately, installing grub
doesn't completely wipe the boot sector like lilo as you can actually install
grub to the beginning of a fat partition and the location of the LILO marker is
important for FAT partitions to not be erased.

And to prevent problems in the future, I double-check now that whichever boot
loader is detected is actually selected as part of the upgrade set, so we should
always be able to have a valid bootloader config after upgrading.
Comment 10 Joe Acosta 2002-06-04 15:12:08 EDT
Interesting then.  You did not find the magic key cause I had a custom
grub.conf, so you never went looking through the boot sector for it.  

What is the magic key that you search for in lilo that I must have had?
boot=/dev/hda ?  Or does it fall back on lilo?

If that is the case then what happens if I remove the lilo.conf and have no
magic key in grub.conf?  Does it just fail to detect it or does it fall back on
one or the other? Or does it look at the boot sector?

Also we are not talking about 'every permutation here' of boot sectors. Noone
should expect you to support things that you don't ship. You do ship grub and
lilo so proper detection of those is something you should support.

If one does lilo -U or lilo -u after installing grub will that just uninstall
lilo or will that screw up grub as well?  Guess I'll test that. 

Comment 11 Michael Fulbright 2002-12-20 12:38:25 EST
Time tracking values updated
Comment 12 Joe Acosta 2005-09-09 00:13:15 EDT
I'm on FC 4 now, and RH 7.3 is not longer supported AFAIK, so I'd say close this.

I'm changing the status to CURRENTRELEASE, because I haven't had problems since
I upgraded to RH9, and none of the FC(1-4) have shown this issue.

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