[lug] A challenge...

D. Stimits stimits at comcast.net
Thu Jul 14 15:48:22 MDT 2005


...
>> During the install, exactly _where_ are you installing grub to?
>>
> 
> It says "Master Boot Record"
> 
>> If I had a Fedora Core system with this problem, I'd boot it with the
>> rescue cd, then do a grub-install on the root of every drive to be safe:
>>
>> grub-install /dev/sda
>> grub-install /dev/sdb
>> etc.
>>
>> If there's a rescue disk for debian, you might try that (it could just
>> be configuration ignorance on my part, but I haven't been successful
>> trying that fix while running Knoppix).
>>
>> Hey - actually, a Fedora Core rescue CD might work for you, too. I know
>> this because I fixed a friend's Gentoo system with that same problem by
>> using the Fedora rescue CD.
>>  
>>
> 
> I tried the Fedora rescue disk without much luck so I went with 
> Knoppix.  I have apparently run grub-install correctly as I get back a 
> message that says it was successful.  While running grub-install the 
> floppy drive is active.  When I check filetimes in /boot the grub files 
> are being updated.  However, if I mount the floppy and look at the 
> contents nothing is there.  The machine does not boot.  I can mount  a 
> floppy and write to it so the drive seems to be OK.

Keep in mind that during install the installer does NOT necessarily use 
the same LBA mode as the BIOS uses during initial boot. You can do a 
correct install to the MBR all you want, if you change the LBA mode (in 
other words, use the BIOS prior to linux taking over), you will never 
succeed, no boot record will ever be found. I have an older computer 
that will die like this every time fedora is installed...it works just 
great with defaults, then it can't find the boot record. But if during 
install I use the non-default for LBA/non-LBA (I forget which is 
default), suddenly it *can* find the MBR. Testing it from a rescue disk 
will not necessarily work, if linux is not using the BIOS access modes, 
while boot does use BIOS access modes.

But...that aside...here is something you can test if you have dd and the 
ability to view the hex value of bytes in a file. dd is almost always 
installed on everything, whether knoppix or rescue disk. You can use 
either hexdump or khexedit (I love khexedit, very nice app) to view hex 
bytes...I'm sure someone here can come up with some other simple way to 
read hex bytes.

Ok, here is the information: Each boot record is 512 bytes, regardless 
of whether it is MBR or PBR. All x86 boot records always end with "magic 
bytes" if it is a valid boot record. Those bytes are 0xaa and 0x55. So, 
use dd to create a file that is an image of the boot record (and FYI, 
this works in reverse to restore botched boot records):
cd /tmp/
dd if=/dev/hda of=hda.img bs=512 count=1

If your drive is other than hda, substitute. If you want to look at a 
PBR instead of MBR, use something like hda1 instead of hda.

You now have an exact duplicate of your boot record. View the last 
bytes, be sure they show aa55:
cat hda.img | hexdump

If those bytes are aa55, likely you have a valid boot record, or at 
least something that was initialized right at some time. It doesn't mean 
you will read the same thing if you switch LBA/non-LBA modes. If it *is* 
aa55 and it can't find a boot record, chances are your BIOS sees 
something else. If your BIOS, during boot, sees aa55 but the boot record 
is invalid, it will more likely have some other odd error, like garbage 
printed out, as it would attempt to load an invalid boot record. When it 
tells you it can't find a boot record, it's a different game. My older 
P166 plays that game.

D. Stimits, stimits AT comcast DOT net




More information about the LUG mailing list