Grub2 MBR vs. Windows MBR

Question

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:

1. Recovery partition (NTFS)
2. Win7 partition (NTFS)
3. Ubuntu root (ext4)
4. Ubuntu swap (ext4) (logical 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.

1. As I understand it, the standard IBM/WIndows MBR code looks in the partition table for the first primary partition with the active/bootable flag set and then transfers control to the code it finds at the beginning of that partition, or the "partition boot record" (PBR). The PBR then locates NTLDR/BOOTMGR/grub/etc and loads it. Is my understanding correct?
2. Where in the boot process is the interrupt key (f11 in the case of HP) to boot into the recovery partition handled? MBR? PBR? Boot manager/loader?
3. When grub writes the MBR it also seems to use the rest of track 0 and the MBR code executes this code before moving on to load the rest of the grub code in whatever partition it is loaded in (in my case partition 3). In this sense it disregards the active/bootable flag in the partition table. Have I understood this correctly?

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.

Answer 1

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.

1. Yes, your understanding is correct
2. Answered above
3. Not sure specifically what GRUB does when installed to the MBR. To my understanding it didn't really put business logic there, but I could be wrong.

Hope that helps :)

Answer 2

Question 3: 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.

Answer 3

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.