Bug 65442

Without the python traceback, it is nearly impossible to say what happened here.
   Could you please attach it?

Created attachment 915019 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

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

here is lilo:

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=20
message=/boot/message
default=linux
linear

image=/boot/vmlinuz-current
	append="init 1"
	vga=normal
	label=Maint_init1
	read-only
	root=/dev/hda1

image=/boot/vmlinuz-current
	append="init 2"
	vga=0x317
	label=NormVGA_init2
	read-only
	root=/dev/hda1

image=/boot/vmlinuz-current
	append="init 3"
	vga=normal
	label=runlevel_3
	read-only
	root=/dev/hda1

image=/boot/vmlinuz-current
	vga=0x317
	label=Custom
	read-only
	root=/dev/hda1

image=/boot/vmlinuz-test
	vga=0x317
	label=Test
	read-only
	root=/dev/hda1

image=/boot/vmlinuz-2.4.18-3
	label=linux
	initrd=/boot/initrd-2.4.18-3.img
	read-only
	root=/dev/hda1


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

kHlbaLILO

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.

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.

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.

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

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
#boot=/dev/hda

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.

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. 
  

Time tracking values updated

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.