Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question

3 Answers 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.

share|improve this answer
    
Thanks Ken, this corroborates some other info I have been reading about how GRUB installs itself. I wanted to avoid the MS boot loader process if possible because I just do not like the way it operates. I am pretty sure I have a complete and integral copy of the recovery partition, but it's contents are a bit strange. I don't see a bootmgr.exe, but I do have a bootmgr and a boo.mgr. There is also a "boot" dir with a "bcd" file. I dumped the VBR and it appears valid, though it looks as though it is pre-Vista. I say that because the error strings contain "NTLDR" not BOOTMGR. Strange. –  NetWorker Sep 24 '10 at 2:32

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.

share|improve this answer
    
Hi Neal. I believe that the older partitioners left the first cylinder alone completely, the Vista+ ones align the partitions on 1 MB boundaries ignoring geometry altogether. So there is less of a MBR gap than before. I still don't understand why when grub chainloads the VBR on the restore partition it just hangs though. And I really want to know where the F11 bit is handled. It just bugs me when I can't figure this stuff out. I have become obsessed. –  NetWorker Sep 24 '10 at 2:38

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 :)

share|improve this answer
    
Thanks Billy. The only reason I want the recovery partition is for licensing reasons, as my Win7 is an upgrade copy and if I need to reinstall I thought I might need it (though I have done some further investigation and understand I may not). Not sure what was the active partition on the original HP build. The restore partition was hidden. It never displayed a message about pressing F11, you just had to know. I will grab the MBR when I remove it from it's cryogenic chamber (between the peas and the pizza rolls). –  NetWorker Sep 24 '10 at 2:18
    
It turns out that the main Win7 partition was the first partition on the disk and it was active. So it was not booting into the recovery partition. –  NetWorker Sep 24 '10 at 13:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.