recent kernel upgrades damage mbr

Wed Jun 18 22:00:02 UTC 2008

On Wednesday 18 June 2008, Mikkel L. Ellertson wrote:
>Gene Heskett wrote:
>> On Wednesday 18 June 2008, Mikkel L. Ellertson wrote:
>>> This is not going to help, because the old MBR will be pointing to
>>> the wrong location for stage 1.5, so you will get an error on boot.
>>> Remember, the part of GRub that is in the MBR loads from a fixed
>>> disk location. It does not read the file system. So, unless stage
>>> 1.5 is in the same place on the disk, (head, cylinder, sector) it is
>>> not going to be able to load it.
>>>
>>> Your best bet is to fix the device map, and run grub-install.
>>>
>>> Mikkel
>>
>> I have Mikkel, twice, and grub-install (or one of its friends) overwrote
>> it both times.  Lets just say it was "educational".  I now have backups
>> under other names there.
>>
>> --------device.map--------
>> # this device map was generated by anaconda
>> (hd0)     /dev/sdb
>> --------------------------
>> No mention of any other drives seems to be allowed, and there are 2
>> others.
>
>This is strange, because grub-install is not supposed to change the
>device map unless you use the --recheck option.
>
>> Also NDI why it says Anaconda, cuz Anaconda hasn't been exec'ed on this
>> box since last February when (I think nvidia blobs had something to do
>> with it) when something, for the 2nd time in 3 months, wiped the mbr from
>> the boot drive.  Now I'm on an old ATI card running the radeon driver, and
>> no further problem (knock on wood). Maybe, if and when I get around to
>> building another box, the new mobo's bios won't be so fscking brain dead
>> and I won't have to screw around with this anymore.
>
>I forgot - one other thing that may help is to change
>/etc/sysconfig/grub to match what you need in the device map. That
>may be where the changed device map is coming from.
>
>> While we're on the subject of mbr's, how big is it?  The first 512 bytes
>> of the one I just saved is virtually empty.  So I overwrote it with a 4kb
>> version, but that is bearing some resemblance to a list of inodes.
>
>The MBR, including the partition table is normally 512 bytes. If it
>is empty, then you may be using the wrong device. Did you use
>/dev/hda1, and not /dev/hda? Writing 4kb can lead to file system
>corruption.
>
All libata here, so all drives are 'scsi'
Here is mtab:
/dev/sda3 / ext3 rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
/dev/sdb2 /home ext3 rw 0 0
/dev/sdb3 /usr ext3 rw 0 0
/dev/sdb1 /var ext3 rw 0 0
/dev/sdc1 /amandatapes ext3 rw 0 0
/dev/sda1 /boot ext3 rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
/dev/sdd1 /media/usbkey vfat rw 0 0

Boot is on sda1 of course, sda2 is a dos thing I don't often mount, and / is on 
sda3, the remainder of a 500GB PATA drive.  sdc is the only actual sata drive 
here.

It may be that the recheck util is the guilty party, I recall running it for 
effect, and having to go into recovery mode before I could reboot again, cuz it 
put the 400GB SATA drive as /dev/sda, which this bios cannot see.  This was all 
about 5 months ago, and that qualifies as something short term enough to be 
blamed on CRS.

I've rechecked that by throwing it into hexdump, and this looks much more 
believable:

[root at coyote lib]# dd if=/dev/sda bs=512 count=1 |hexdump
1+0 records in
1+0 records out
512 bytes (512 B) copied, 3.2839e-05 s, 15.6 MB/s
0000000 48eb 1090 d08e 00bc b8b0 0000 d88e c08e
0000010 befb 7c00 00bf b906 0200 a4f3 21ea 0006
0000020 be00 07be 0438 0b75 c683 8110 fefe 7507
0000030 ebf3 b416 b002 bb01 7c00 80b2 748a 0203
0000040 0080 8000 6c51 0004 0800 90fa f690 80c2
0000050 0275 80b2 59ea 007c 3100 8ec0 8ed8 bcd0
0000060 2000 a0fb 7c40 ff3c 0274 c288 be52 7d7f
0000070 34e8 f601 80c2 5474 41b4 aabb cd55 5a13
0000080 7252 8149 55fb 75aa a043 7c41 c084 0575
0000090 e183 7401 6637 4c8b be10 7c05 44c6 01ff
00000a0 8b66 441e c77c 1004 c700 0244 0001 8966
00000b0 085c 44c7 0006 6670 c031 4489 6604 4489
00000c0 b40c cd42 7213 bb05 7000 7deb 08b4 13cd
00000d0 0a73 c2f6 0f80 ea84 e900 008d 05be c67c
00000e0 ff44 6600 c031 f088 6640 4489 3104 88d2
00000f0 c1ca 02e2 e888 f488 8940 0844 c031 d088
0000100 e8c0 6602 0489 a166 7c44 3166 66d2 34f7
0000110 5488 660a d231 f766 0474 5488 890b 0c44
0000120 443b 7d08 8a3c 0d54 e2c0 8a06 0a4c c1fe
0000130 d108 6c8a 5a0c 748a bb0b 7000 c38e db31
0000140 01b8 cd02 7213 8c2a 8ec3 4806 607c b91e
0000150 0100 db8e f631 ff31 f3fc 1fa5 ff61 4226
0000160 be7c 7d85 40e8 eb00 be0e 7d8a 38e8 eb00
0000170 be06 7d94 30e8 be00 7d99 2ae8 eb00 47fe
0000180 5552 2042 4700 6f65 006d 6148 6472 4420
0000190 7369 006b 6552 6461 2000 7245 6f72 0072
00001a0 01bb b400 cd0e ac10 003c f475 00c3 0000
00001b0 0000 0000 0000 0000 caf5 000c 0000 0180
00001c0 0001 fe83 1f3f 003f 0000 d7e1 0007 0000
00001d0 2001 fe82 1e7f d820 0007 823f 003e 0000
00001e0 1f41 fe83 ffff 5a5f 0046 f1e2 39f1 0000
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55

I'll go fix my backups.

>Mikkel

Thanks Mikkel.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
All of life is a blur of Republicans and meat!