Skip to main content

What's in MBR/Track0 and how can/does TIH manipulate it's component parts ??

Thread needs solution

This has to do with the whys and wherefores of "MBR and Track 0". From notebook #1 I created an archived image of the system partition and thus an archived MBR embedded in that archive. My objective was to get that onto a different physical drive (in otherwise identical notebook #2). The scenario here is that I wanted the system partition only, not the other partitions of the source disk, but I also wanted the MBR of the source disk. The original (NB1) is a single boot system (XP) and has Acronis Startup Recovery Manager (ASRM) activated ("F11" option at boot).

I wanted only the system partition i.e. for all the applications that had been installed. I chose not to clone because NB2 doesn't need the other (data) partitions from NB1 (the NB2 HDD is too small to hold it all anyway). But I also wanted the disk signature because it may be important to the functioning of certain application programs. I could think of no way to do that (short of editing the MBR manually somehow) except to either clone (which I chose not) or "restore MBR and Track 0" along with the system partition. So when I restored the image and MBR to NB2 I was expecting 2 good outcomes: (1) getting the disk signature contained in the MBR and (2) getting the ASRM boot option, as I understand that the "F11" ASRM boot option comes from the master boot code in the MBR. I haven't yet confirmed that the disk signature came over ok, but there was another complication I'll describe.

Before doing the restore, I had prepared the NB2 disk with "format" (note I didn't create any extra partitions on it). After restoring the image and MBR I got "MBR Error 2" at bootup. The boot then proceeded directly into Windows i.e. there is no message prompting F11 for Acronis Startup Recovery Manager. After some research I eliminated the MBR error by running fixmbr from XP's Recovery Console. The F11 prompt still did not appear, maybe that should be no surprise.

The missing ASRM option is not a big problem as I can reactivate it in a separate step, but I'm curious to know why it didn't come thru. Should I not have expected it to come thru, or maybe it would have come thru if the MBR Error had not occurred? As a side note, I have performed "clone disk" on another occasion and the ASRM option came thru (as though "clone" restores the MBR differently (better?) than "restore MBR" does).

I've written this all up trying to get better educated and improve my strategy/process. That is, besides (and behind) the questions I've raised, there are certain assumptions/conclusions I've made, now in question, and other things I'd like to know:

- My understanding is that a complete MBR contains the Master Boot Code, the Disk Signature and the Partition Table (nothing more, nothing less), I may be wrong. And I was guessing that "restore MBR" would restore the master boot code and therefore the ASRM boot option, but now I'm not so sure. (Did the archive operation in fact even store the boot code?)

- I guessed that the MBR Error 2 occured because the archived MBR's embedded partition table specified partitions that didn't exist on the new drive. Thinking back, maybe I could have avoided the MBR Error by preparing matching (dummy) partitions on the new drive to satisfy the partition table (I didn't think to try that). But then again, some say (http://forum.acronis.com/forum/6481) that when TIH restores the MBR it doesn't touch the partition table ... if that's so then what caused MBR error 2 ?.

- What exactly is MBR Error 2? I've seen or heard of other MBR errors (1, 3) elsewhere, but have never found a list/description of what the specific MBR error codes represent.

- I am guessing that fixmbr simply repaired the partition table and nothing more, but I don't know that for certain. That is, I see no reason it should alter the disk signature or the master boot code. I now see there is an "Acronis FixMBR" utility (http://forum.acronis.com/forum/3872), perhaps it will help to know how its behavior differs from the version in XP's Recovery Console.

- As for the disk signature, I suppose I could examine the HKLM\System\MountedDevices registry to check it but that is painful. Besides, I'd like to know how to view the signature directly from a disk read (I have Acronis Disk Director but its "edit" function doesn't seem to display it). Some (http://forum.acronis.com/forum/6146) hint that there is a "recover disk signature" checkbox in TIH but I have looked and never seen it (in TIH 11 Home).

I appreciate any comments & corrections that would help set me straight, fix any bad assumptions I've made or lead me to a better method. Thanks for reading !!!

Chuck

0 Users found this helpful

Chuck:

I'll take a stab at answering some of your questions. To cut to the chase, restoring partitions to a different disk with TI will not normally preserve the Disk Signature of the original disk, which is what happened to you. If you need to preserve the Disk Signature then you need to check off the option in TI 2010.

The "MBR Error" messages are produced by the Acronis boot code in the MBR when you have activated the ASRM. The message indicates that the boot code cannot locate the specific files needed for the "Press F11 ..." function. The reason that this happened is that the ASRM boot code references its files by absolute sector location on the disk. When you restore a partition with TI each sector does not necessarily get put back into the exact same location, thus the error message when booting. To get around this when imaging you need to first de-activate the ASRM, create your image, restore it, then re-activate the ASRM. In your case you should now be able to re-activate the ASRM to restore its functionality.

To answer your other question, yes - the restore MBR function did copy the Acronis boot code to the MBR. However, code execution failed because the files that the PC was attempting to boot to were moved to a different location. FixMbr does not touch the partition table (no MBR fixing code nor MBR restoration will alter the partition table; that's dangerous to do if the user has done any re-partitioning). It only replaces the boot code in the MBR with Microsoft's simple boot code. In your case it would have replaced the ASRM boot code with the generic Microsoft boot code.

Finally, when restoring to a disk you do not need to prepare the disk in any way. It does not have to be partitioned nor does it have to be formatted. TI creates the needed partition(s) as part of the restore process. Formatting is folly because the first thing TI does during a restore is to delete any existing target partition, so there goes your formatting in a poof!

Hopefully this helps some!

P.S. To view the Disk Signature with Disk Director use the Disk Editor and view Absolute Sector 0. This article shows the location of the 4-byte Disk Signature. In the article it is called the NT Drive Serial Number. Scroll down to the large color picture of a Disk Editor view. The Disk Signature consists of the four bytes beginning at 01B8h (highlighted with a Cyan-colored marker).

Thanks for all the information, Mark. It certainly helped.

I gather that "signature" and "serial number" are interchangeable terms at least in Acronis-land (I had seen "serial number" in disk editor but wasn't convinced it was the "signature"). And so if I want to restore disk signature, I should pitch TIH 11 and get TIH 2010. (Unless I'm willing to manually edit it e.g. using Disk Director).

I now understand that it doesn't matter how many partitions the original table had vs. how many I'm intending to restore, because the "restore MBR" shouldn't have touched the partition table anyway. I was barking up the wrong tree, the MBR error had nothing to do with partitions/count, but was because the Acronized boot code couldn't find its ASRM code by absolute position.

I think I might (instead of deactivating ASRM before archiving as you say), simply let the error happen then fixmbr after restoration (to get the generic boot code back) ... if it is fewer steps to the same result.

I gather any 'fixmbr' will touch only boot code, not signature or partition table ... so I still wonder what advantage or difference there is if any, between the "Acronix FixMBR" utility (didn't use it yet), and XP Recovery Console's fixmbr. Maybe it is the same, just offered up for convenience.

Thanks again for the help.

(edit) P.S.: After all this, it seems to follow that "restore MBR" is good for certain limited use cases only, if at all. By process of elimination: it doesn't touch the partition table, and it doesn't touch the signature (except by option in TIH 2010), the only thing left is boot code. But now we know that transplanting ASRM/F11 boot code doesn't work. What other kind of boot code is interesting ? Maybe in a multiboot system with boot manager (I haven't messed much with that), but even that case might fail if the boot code or manager trips due to absolute addresses/position issues. And in my case, I am best off perhaps to simply NEVER check the "restore MBR" box, restore just the system partition then run TIH from it to reactivate the ASRM.

Chuck:

Yes, that is the best and simplest method. Just restore the partition(s) of interest and then reactivate the ASRM.

The "MBR and Track 0" feature is only intended for people using a third-party boot manager (like LiLo, Grub, BING, Grub4Dos, etc). Windows-only users should not need to use the feature. And yes, some of these boot managers (LiLo in particular) rely on absolute addressing so even after restoring the MBR the user may still need to reactivate their boot manager. I know from personal experience that Grub and Grub4Dos both restore perfectly to the MBR using the Acronis restore "MBR and Track 0" feature.

I think that the Acronis FixMBR utility is the same functionally as FixMbr on a Windows XP disk. However, it may differ slightly but the end result is the same. The function used in the standard Microsoft MBR is quite simple - it searches the partition table to find the partition that is marked as "Active" and then jumps to that location. The code segment is 300 bytes long and the error messages occupy the next 80 bytes.

Vista and Windows 7 added a few extra bytes to handle booting to partitions that are encrypted with BitLocker.

I linked to the wrong page in the article in reply #1. I've fixed the link.