That's what I never got around to the last time ... ... maybe I'll try it this time using either BCDEdit or Dan's MBRsaver tool. I've started reading up on both of them.

Quote:

The above partition was cylinder aligned. I deleted the partition and created a MB aligned partition with BIBM. The same Win7 image was restored into this partition. Win7 booted and the partition remained MB aligned.

That confirms what Dan wrote in Reply #9:

Quote:

So if you put Ghost in a situation where it has to create the partition before restoring the contents, it's always going to do it CHS-aligned. (...) And you can pre-partition a target drive with MB-aligned partitions and Ghost will happily restore images into those partitions without upsetting the alignment.

The only thing I have noticed the few times I created Disk-to-Image and restored Disk-from-Image is that even if I have pre-partitioned the new disk, Ghost will suggest different sizes even if the source disk and target disk are identical with identical partition sizes. When that happens, my bet is that the resized partitions (even if I choose the original sizes) will become CHS aligned. My experience is that Ghost 2003 never suggests different sizes when creating Partition-to-Image and restoring Partition-from-Image. Also, the "-fdsp switch" is not needed when working with the system partition, only when working with the whole disk.

Old chinese proverb:If I hear - I forget, If I see - I remember, If I do - I understand

The "installing Windows 7" step seems unnecessarily excessive. It sounds like the only reason you're doing that is to generate a DiskID. If all you need is some random DiskID, you can manually type something in with a sector editor like Diskedit or Roadkil's Sector Editor. Or if you want to restore the same DiskID as on the original source disk, there are a number of ways to do that.

I don't know how the Windows 7 installer creates the DiskID but after an image restore, if it doesn't match, the OS won't boot. Ghost 2003 zeros the DiskID when restoring a Disk-from-Image and it worked with Windows XP and earlier OS. The BCD edit that Brian and you discuss will fix this (Windows 7 will boot without a correct DiskID) and I will try that when the components get here.

Quote:

Also, IME Ghost 2003 doesn't overwrite the DiskID if you do a partition restore vs a disk restore.

I agree. I have only created and tested restoring Disk-from-Image to learn and make sure it works. I have never restored out of necessity.

Now I don't understand how a partition restore to a new hard disk (pre-partitioned or not) will boot? The BCD is not included in the partition image ... ... and is needed for it to work, right? That's why I "insist" on first installing Windows 7 on the new hard disk and next restore partition-from-MyTrustedOldImage. It also avoids the "automatic resizing issue" that I discussed in my reply to Brian.

Quote:

I'm not quite sure if you're under the impression AF technology prohibits pre-partitioning with XP. It doesn't ... but it's just not a good idea. So it would be more accurate to say, "I shouldn't use Windows XP to pre-partition."

Yes, I know. I have read that the performance hit can be substantial if the partitions aren't "properly" aligned. If you compare the performance of the Hitachi 500 GB 7K1000.D with performance of the 500 GB 7K1000.C (assumingly affected by misalignment):

Max data transfer rate = 1822/1546 Mb/s > + 18%

I don't know if + 18% is more or less signinficant than the performance hit from misalignment but my thought was that if I don't get it right, I can stick with the previous generation and stop worrying ... ... !

Old chinese proverb:If I hear - I forget, If I see - I remember, If I do - I understand

I don't know how the Windows 7 installer creates the DiskID but after an image restore, if it doesn't match, the OS won't boot.

That is a fallacy. In my test above each HD had a different DiskID (the DiskID on the new HD wasn't changed by the restore) and the new Win7 booted normally. I've seen this after restoring partition images with Ghost 2003, Ghost 15 and TeraByte Unlimited to new HDs.

As Dan mentioned, if you mistakenly restore a partition as cylinder aligned it can be converted to a MB aligned partition without repeating the restore.

Edit... As discussed in another thread, I could restore a Ghost 2003 image to unallocated space on a HD because that HD had been previously Initialized. It had Boot Code and a DiskID. Ghost 2003 can't restore a partition image to a HD that hasn't been Initialized.

The BCD is not included in the partition image [...] and is needed for it to work, right?

The BCD is a file in the Win7 partition, so Ghost 2003 will backup/restore it just like any other file.

Win7's BCD serves the same purpose as XP's boot.ini file, except that in typical Microsoft fashion, they turned what used to be a plain text file (boot.ini) into a non-human readable binary file. That's why you now need special tools to edit the BCD.

A salient point to this thread is that Ghost knew what a boot.ini file was for, and it would make adjustments to it if that was necessary for the restored OS to be bootable. However, Ghost 2003 knows nothing about what a BCD file is for, so while it can back it up and restore it, it will not know to make any adjustments to it if necessary.

That's one of the points behind the "BCD generalization" steps Brian has outlined. If you don't have a SRP and you generalize the BCD, then Ghost 2003 wouldn't need to have to make any changes to it--which is convenient because we know that wouldn't happen anyway.

If it helps, I'll describe a technique I have used to quickly backup/restore a Win7 system with Ghost 2003. For illustration, I'll use as an example a brand new Dell/Win7 PC, which comes from the factory with a small DellUtility partition, a 10-20GB Recovery partition, and a main OS partition occupying the rest of the space.

To be able to completely restore a disk to OEM condition, there are four pieces of the OEM HDD to backup: the three partitions plus Track-0. I use Ghost 2003 to make partition-to-image backups of the three partitions, and use something like Terabyte's MBRwork utility to backup the first 63 sectors (Track-0) of the disk.

That's all. It's pretty straightforward, and I can then go about repartitioning and customizing things as I like.

If/when I want to restore the disk back to OEM condition (perhaps to resell it or pass it down to a relative), all I have to do is restore the Track-0 backup, reboot (so the new partition table is recognized), and do three partition-from-image restores.

The Track-0 backup captures/restores the MBR, the DiskID, the partition table, the active partition boot flag, and any extra proprietary boot track sectors an OEM might have added. (Dell and HP, for example, can hide additional code to facilitate booting their Recovery partitions.) Thus, restoring the OEM Track-0 on a new, blank HDD effectively lays out the partition boundaries to be identical to the OEM HDD--even MB-aligned if the OEM was MB-aligned. With the empty partitions thus laid out, Ghost 2003 will restore partition images into them without disturbing the alignment.

I've used this technique more than a few times, and can verify it works.

For illustration, I'll use as an example a brand new Dell/Win7 PC, which comes from the factory with a small DellUtility partition, a 10-20GB Recovery partition, and a main OS partition occupying the rest of the space.

So, it's a Win7 system, but Dell is not using the System Reserved Partition (SRP) with the boot files that would occur if I were installing Win7, using its default installation settings, on my own personally built system?

So the *boot configuration data* (BCD) file is on the main Win7 OS partition?

The "starting offset" refers to the sectors before the partition. "3F" is a hexadecimal value; in decimal that is "63". This is the size of one head (or "track") in terms of a standard CHS geometry. The hex value "800", in decimal form is 2048, so this is referring to the first MiB of space, from the start of the disk. Because a 1-MiB alignment boundary is used by the Vista partitioner(s), 1 MiB is "reserved for" the Master boot record (MBR), instead of the traditional 63 sectors (31.5 KiB).

And using the 1-MiB for the reserved space at the beginning of the HDD for the MBR was necessary to offer alignment of the rest of the HDD.

So, is the Dell system not *aligned*?

If the MBR reserved area is 1-MiB (2048 sectors)--is there a chance you might not capture all the *extra proprietary boot track sectors an OEM might have added* if they extend beyond the first 63 sectors?

Quote:

Thus, restoring the OEM Track-0 on a new, blank HDD effectively lays out the partition boundaries to be identical to the OEM HDD--even MB-aligned if the OEM was MB-aligned.

The MBR only uses the first absolute sector 0--does restoring that automatically restore the 1-MiB boot track region that also sets up the alignment of the HDD again?

So the *boot configuration data* (BCD) file is on the main Win7 OS partition?

The BCD is a file in the "\Boot" folder of the active partition. In a split SRP+OS system that puts it on the SRP, while on a system where the OS partition is the active partition the BCD is there.

Quote:

So, it's a Win7 system, but Dell is not using the System Reserved Partition (SRP) with the boot files that would occur if I were installing Win7, using its default installation settings, on my own personally built system?

On Dell's Win7 systems the Recovery partition doubles as a SRP, so Win7 boots via the Recovery partition. On Dell's Vista systems the OS partition is the active partition, so the Recovery partition boots via the OS partition.

But that's not the point. My point is all those details are immaterial if you're just trying to duplicate an existing system. It doesn't matter whether you have a SRP, or a Recovery partition, or neither, or which one is the active partition, or whether it's CHS-aligned or MB-aligned ... it's all immaterial if all you're doing is making an exact clone. And Ghost 2003 can easily do that with a backup of Track-0 and partition images.

The "MBR", like "drive", has never had a precise definition, and unfortunately it sounds like they're trying to unilaterally redefine it according to somebody's personal preference.

Most people say the Master Boot Sector (the first sector on the HDD) is the MBR, others say only the boot code part of that sector is the MBR. Systems with multiboot managers (like Grub, BING/BIBM, Acronis Secure Zone, et al) use more than one sector and often refer to the extra sectors as an "extended boot record" or "MBR extension". IAC, those terms have generally referred to just the amount of sectors that were necessary to contain all the code, not the entirety of empty space before the first partition. I've never heard of the empty sectors being referred to as the MBR, and just because you move the first partition further away from the front doesn't mean you now have a larger MBR to backup.

Remember my MBR backgrounder: the IPL boot code merely turns control over to a PBR. Nothing more. If you have a true boot manager you might have to use more than a single sector to do it, but the end result is still the same: pass control to a PBR, regardless of what OS is on it. FTR, note that the standard MBR code installed by the Win7 installation process still fits in a single sector--just like Vista, XP, Win98, and DOS. Changing where you place your partitions doesn't change the definition of the MBR.

Quote:

And using the 1-MiB for the reserved space at the beginning of the HDD for the MBR was necessary to offer alignment of the rest of the HDD.

Keep your eye on the ball, NightOwl: HDDs do not get aligned. We align partitions, not HDDs. And the only reason we align partitions is because that aligns clusters, which is the only factor that actually matters.

Don't think of it as "reserving 1MB"--you're not "reserving" anything. You're using 1 sector for the MBR, and then positioning your first partition at the earliest multiple of 2048 sectors that you can, following the MBR.

Quote:

If the MBR reserved area is 1-MiB (2048 sectors)--is there a chance you might not capture all the *extra proprietary boot track sectors an OEM might have added* if they extend beyond the first 63 sectors?

Yes, if anybody used more than 63 sectors, but I've never seen any manufacturer use more than about 14 or 15 sectors. You can capture 2048 if you want, but all you're going to get are more zeroes.

You could also cause potential restore problems if you capture 2048 and your first partition is CHS-aligned, because then your backup overlaps your first partition. For that reason, and because sectors 63-2048 will never contain MBR code anyway, I make it a habit to never backup more than the first 63 sectors.

Quote:

So, is the Dell system not *aligned*?

Again, remember that it's partitions that get aligned. Dell's Vista and Win7 systems use a 1-sector MBR, a CHS-aligned Utility partition, and MB-aligned Recovery and OS partitions.

Remember that the goal is to align NTFS clusters because Windows writes whole clusters at a time. The fact Dell CHS-aligns their Utility partition is inconsequential because it's not NTFS and because it's not even accessible to Windows anyway.

I know that BCDEdit is native to Windows 7 but Dan informed that his tool could do the job too.

I don't think I did. Are you referring to Reply #12?

"Or if you want to restore the same DiskID as on the original source disk, there are a number of ways to do that. (Did I mention my MBRsaver tool can do that?"

MBRsaver can individually restore any of the three parts of the Master Boot Sector--the boot code, the DiskID, or the partition table. Most MBR utilities can only do all three together. MBRsaver doesn't get involved in any other sector of the hard drive.

Yes, I was too quick about re-reading your reply. The issue with the DiskID is a different matter. The DiskID can be edited using your tool "MBRsaver". Using Brian's "generalized BCD" (edited using BCDEdit) avoids the problem (as well as the use of the "-fdsp switch").

I'm dual booting (Win XP pro - Win 7 pro) and I now realize that's possibly why it takes three experienced forum members a thread of several pages to get it through to me ... ... !

Old chinese proverb:If I hear - I forget, If I see - I remember, If I do - I understand

When using MBRsaver is there a simple method of knowing which HD you are dealing with?

Unfortunately, no. That's something I never got around to putting in MBRsaver.

I originally created MBRsaver over a decade ago. That was during the days when I was exploring how Win2K remembered drive letters, and it was handy to have a quick-and-dirty way to restore just a HDD's DiskID by itself. I always knew which device ID I was working with while I was up to my elbows in some project, but it's admittedly user-unfriendly for everyday use or coming in blind on some random system. There's a few improvements like that which could be added, but it's just never been high enough on my priority list to get around to it.

Quote:

I use

dsrfix /80dsrfix /81etc

to identify my BIOS HD0 in a 3 HD computer.

Yeah, I do the same thing. If I'm working on a multi-HDD system and not sure which BIOS ID I want, I trial-and-error it with Dsrfix to see whether it's /80 or /81, etc., then use the same switch with MBRsaver.