[TriLUG] dual boot laptop loosing boot info

[Joseph Mack NA3T]

On Thu, 9 Dec 2010, Derek Linz wrote:

> Joe,
>
> What's the output of 'fdisk -l'? Is it the Windows 
> partition that's first or the Linux?


x60:~# fdisk -l /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x63e39c64

    Device Boot      Start         End      Blocks   Id 
System
/dev/sda1   *         132        3955    30716280    7  HPFS/NTFS winxp
/dev/sda2           18725       19999    10241437+  83  Linux     test partition
/dev/sda3           20000       21245    10008495   83  Linux     /
Partition 3 does not end on cylinder boundary.
/dev/sda4           21246       60801   317733570    5  Extended
Partition 4 does not end on cylinder boundary.
/dev/sda5           21246       26226    40009851   83  Linux      /usr
/dev/sda6           26227       60300   273699373+  83  Linux      /src
/dev/sda7           60301       60801     4024251   82  Linux swap
x60:~#


> And yeah I'm a fan of grub2, It's a lot more 
> flexible...easy to configure if you want it to be ('sudo 
> grub-mkconfig -o /boot/grub/grub.cfg')

sure but grub.cfg is a nightmare.

winxp is first.

Wheneven I lost the grub boot I could restore grub by 
booting off a cdrom and reinstalling grub. That this worked 
showed that the linux partitions and the partition table was 
OK.

I later checked the winxp partition (which I don't use 
much), I found winxp was hosed too (partition wouldn't 
mount, bits in early part of partition were all changed).

Something was happening to the early blocks of the disk, but 
after the partition table.

So I wrote a cron job to do an md5 on the 1st 63 blocks of 
/dev/sda and the first 63 blocks of /dev/sda1 every hour. 
I've only lost boot once since then (2 days later) and the 
winxp partition was hosed about 2hrs before the boot sector 
was lost (both happened in a single linux session without me 
being aware of it till attempted to boot the next day). So 
apparently there are two different writing events - one for 
the boot area and one for the winxp partition

I then moved the winxp partition up by a Gig (which is where 
it is now - as you can see from the fdisk -l table above), 
to see if the process was writing at the beginning of the 
partition or at block 64. It's been moved for just 2 weeks 
now and nothing has happened to the winxp partition. It only 
took 2 days for the winxp to get written over last time, so 
I take it that the winxp problem has an interim fix.

I assume then that the problem code is writing early in the 
disk and winxp cops it because it is straight after the boot 
area. Why it's doing it to the 1st 63 blocks of winxp 
separately to the boot area, I don't know.

rkhunter didn't find anything but combofix when run in winxp 
kept finding a rootkit and then hanging.

When you install winxp on this thinkpad, to get the thinkpad 
drivers (wifi, video, trackpad...), you do a multiple 
interative process like Microsoft update but from Lenovo. I 
don't remember if I got a BIOS update, but if you need one, 
it comes then. I wasn't having any problems before I did 
this update.

I wondered if I had a BIOS virus. I force reflashed the BIOS 
with the same (latest) version and I haven't had any 
problems since then (about a week). This is encouraging. I 
thought of e-mailing you about it but didn't want to declare 
success prematurely, so have sat on it.

The current theory then is that I had a BIOS virus, which 
seems to be unusual.

If this cure sticks, I'll move winxp back down to block 64 
again.

Joe

-- 
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!