FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 10-11-2011, 07:13 PM
Lucas Meneghel Rodrigues
 
Default grubby: --bootloader-probe option is broken for grub legacy installs

Hi folks,

I've noticed that on my 64 bit F16 development laptop, executing

grubby --bootloader-probe

shows grubby is unable to detect my grub legacy installation (this
system was upgraded from F15 -> F16). Then Cleber pointed me out that in
the manpage for grubby:


--bootloader-probe
grubby tries to determine if grub or lilo is currently
installed. When one of those bootloaders is found the name of that
bootloader is displayed on stdout. Both could be installed (on
different devices), and grubby will print out the names
of both bootloaders, one per line. The probe for grub requires a
commented out boot directive grub.conf identical to the standard
directive in the lilo configuration file. If this is not
present grubby will assume grub is not installed (note that anaconda
places this directive in grub.conf files it creates). This

option is only available on ia32 platforms.

First reaction is "what the...". Ok, then it should work fine on an
older 32 bit F14 laptop right? Well, turns our it's not working as well.


I do understand that this is a minor bug, and it does not affect
grubby's ability to install new kernels, but yet it is a bug and should
be fixed. Also, as someone not aware of the situation, can someone
explain why on earth this detection shouldn't work on x86_64 machines?


I've started to look at it on gdb and found out that the place where
things go awry is around line 2462, function checkDeviceBootloader:


/* first three bytes should match, a jmp short should be in there */
if (memcmp(boot, bootSect, 3))

memcp will return > 0 and then checkDeviceBootloader will return 0,
which will make grubby to return 0, but not print 'grub'.


Breakpoint 1, checkDeviceBootloader (device=0x6106d0 "/dev/sda",
boot=0x7fffffffd6c0 "353H220") at grubby.c:2463

2463 if (memcmp(boot, bootSect, 3))
(gdb) p boot
$1 = (const unsigned char *) 0x7fffffffd6c0 "353H220"
(gdb) p bootSect
$2 =
"353H220", 'w' <repeats 59 times>,

The only way I can get this memcp to pass is to read only the first byte
of both strings. But then the function would still fail here:


if (boot[1] == 0xeb) {
offset = boot[2] + 2;
} else if (boot[1] == 0xe8 || boot[1] == 0xe9) {
offset = (boot[3] << 8) + boot[2] + 2;
} else if (boot[0] == 0xeb) {
offset = boot[1] + 2;
} else if (boot[0] == 0xe8 || boot[0] == 0xe9) {
offset = (boot[2] << 8) + boot[1] + 2;
} else {
return 0;
}

if (memcmp(boot + offset, bootSect + offset, CODE_SEG_SIZE))
return 0;

So, I thought I'd ask to someone who might have a clue of what's
actually happening here. Since the code is failing on a 32 bit intel
machine, I smell a real bug on the heuristics being used to detect the
boot loader. Hope someone kind enough could explain what is the idea
behind the code detection.


Thanks for your time, and hoping to help fix this bug,

Lucas

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 08:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org