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 "\353H\220") at grubby.c:2463
2463 if (memcmp(boot, bootSect, 3))
(gdb) p boot
$1 = (const unsigned char *) 0x7fffffffd6c0 "\353H\220"
(gdb) p bootSect
$2 =
"\353H\220", '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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
