When I updated my dual boot (Windows and Linux) PC my grub menu.lst file was deleted and I could no longer boot into Windows or Linux.
Finally I have succeeded in installing grub2 and I can boot both OSs but I cannot repair my Windows OS with the recovery console.
I've still some problems with grub2 and Windows 7 but I expected to repair it from the recovery console.
I assume the mbr of my Windows disk is ok because it works with the chainloader from grub2.
The problem is I cannot boot Windows without the chainloader or grub. It even failed to write a new boot sector because Windows cannot detect the filesystem. This happens to me with the bootrec.exe /FixBoot command. I also cannot command bootrec.exe /RepairBCD it gives the same error.
I have an HP system that came with Vista installed and also a hidden restore partition. I subsequently upgraded to Win7(32 bit) Ultimate, and from there to Win7 Pro. Now the hard drive is failing. I managed to use partimage to grab the recovery partition (without errors) before I put it on ice in preparation for a freezer-based recovery of the Win7 partition.
On another drive I created 3 primary partitions and one extended partition:
Next, I installed Ubuntu 10.4 and allowed grub2 to install the MBR. Then, I used partimage to populate the recovery partition with the image that I pulled off the failing drive. Now, before I attempt to recover the Win7 partition I want to be sure I can access the existing recovery partition. And I can't. I can see the files but I can not boot it up. Grub sees it as a Windows partiton and lists it in the menu. But when I try and boot to it I just stare at a blank screen with a blinking cursor. I tried to bypass grub by using gparted to make the recovery partition active and boot directly to that instead of grub, but I still boot into grub.
So with that background, let me pose my questions.
I am obviously missing some pieces here because I can not get my recovery partition to load. I would think the grub "chainloader" (why +1?) command would just exec PBR code. If this is true then something in my recovery partition is hosed.
On systems with such a recovery partition, usually the active partition is the recovery partition. The recovery partition displays the "Press F11" message, and if not pressed, forwards over to the main OS partition.
The MBR is essentially dumb; all it does is choose one of the partitions, and forwards over to that partition's VBR.
If you wanted a linux/windows dual boot, then the recovery partition would need to be forwarding to the GRUB partition, which would then allow options, and would forward to Windows if Windows got picked.
I'd not waste time with the recovery partition -- you can get all the drivers there from HP's web site, and if you've already got 7 on the box I think we can both agree wanting to revert back to Vista is unlikely.
So, to your specific questions.
Hope that helps :)
Yes grub does put some of itself in track 0. I personally never put grub in the mbr, I always use a "normal" mbr and install grub in a primary partition.
Whether using a part of the disk that is not marked as being used will cause a problem will depend. I believe that the disk partitioner in Windows Vista and 7 behaves differently to previous version, but I don't know if it utilises the spare parts of track 0.
I did hear recently of people having problems because a trial version of a program (Adobe something?) writes to that area of the disk overwriting some of grub (in order to be able to stop people reinstalling the trial again and again I suppose). (Listen to a recentish episode of the Ubuntu UK podcast for details) My view is that if you write to areas that don't belong to you, you can't complain about other people doing exactly the same thing.
The mbr bit of grub writes the physical disk address of the next stage of itself into its own code, and takes no notice of partitions at all, active or not.
The MBR (1 sector, 512 bytes) contains boot code and the partition table. The "default" MBR code finds the active primary partition and chain loads it. (In GRUB parlance, +1 means the first sector, the boot sector of that partition.)
When you install GRUB into the MBR, it replaces the default MBR code (keeping the partition table of course) and instead loads the rest of the GRUB core image, which is installed in the "MBR gap" -- the supposedly unused part of the first "track" that comes after the MBR sector. If you install GRUB into a partition, it installs it as the boot sector; the default MBR code chain loads that GRUB boot sector.
So that's why you're always running GRUB -- that's what the code in the MBR has been modified to do. You can restore the default MBR code with some variation of fixmbr.
But at best, that would only prove that your image of the recovery partition is good, and that you can access it through a vanilla MBR. Actually, if you prove that your image of the recovery partition is bad, maybe that's why it didn't work through GRUB, and if it was good, it would have worked. So that might be better, if you can make a good copy.
It's possible that the recovery partition won't boot through GRUB, for some bizarre reason. There may have been some special sauce in the factory original MBR that was a prerequisite for the recovery partition. I have eschewed systems that had them, so I can't offer much insight there.