I responded to a thread in the Ghost 2003 board regarding Ghost 2003/Ghost 8.2 and Windows Vista.  However I thought it might be helpful if placed here where Ghost 12 and Vista users might more readily see (and comment on) my test results.

I just tested restoring a Ghost 12 Vista backup onto a spare SATA harddrive that I was using on an XP pc (data volume not c: ).  

1. I deleted the partitions in XP, so it was empty.
2. I shutdown my Vista pc, and disconnected the 2 internal sata drives.
3. I connected my empty xp sata drive.
4. I booted from the Ghost 12 cd.
5. I selected "Restore my Computer".  Ghost 12 showed a menu of restore points (backup images) that I have stored on my external USB2 hard drive.
6,. I selected the latest c: Vista partition backup.
7. At this point I saw the options that Ghost 12 would use.  A couple things caught my attention:

* There was an option called "Restore original disk signature".  It seems that Symantec has fixed the problems with disk signatures.
* There was an option called "Restore Anywhere - not licensed" which was NOT checked.  I have no idea what this is, but must be a new feature coming in the future.  
* Restore MBR was NOT checked.  I suspect the reason for this is that my Vista c: backup is of ONLY the c: partition.  I have another partition on the physical hard drive.  I think if I had done a complete "Backup My Computer" backup with Ghost 12, it would restore everything.
* In fact, I couldn't modify any of the options.
[Edit:  I was using a ps2 keyboard connected to an add-in card on the Dell, so believe it is possible that the keyboard was not detected by the boot cd.  Will have to re-test that next time with usb keyboard.]
* Auto Validation was also checked.  That's a nice touch.

8. The restore took 11 minutes.
9. I exited Ghost 12 cd, and rebooted.
10. Vista started up normally (well it did give a message that it hadn't shut down properly and did I want safe mode or normal.  I selected normal)
11. Everything worked just fine in Vista from Ghost 12 restore.

Afterwards, I shut down and connected the restored Vista drive, back to the XP computer as a data drive ( d: ) and booted xp.

I started Partition Magic 8 to see if I could see what cylinder the partition was on.  PM8 immediately gave me an error message saying disk format was invalid!  (From that I would conclude that PM8 is NOT "vista certified").  

I finally used the Terabyte PartInfo utility successfully to analyze my restored Vista drive (now attached to the xp system) as well as to analyze my original Vista partition on Dell.

1. The XP c: drive has 63 Hidden sectors (I believe that means it starts on sector 63)
2. The XP d: drive (the Vista restore created by Ghost 12) has 63 hidden sectors.  Not sure why Ghost 12 relocated it from 2048.  (Perhaps if I had wiped the SATA drive first, Ghost would have placed the restored partition at 2048.  At least it works as is without any intervention.)

3. The original Dell Vista c: partition has 2048 hidden sectors (i.e. an offset of 2048).

Conclusion:  I had expected to have needed to perform a Vista boot repair or edit the bcd because the "restore MBR" option was not checked.  I assume that Ghost 12 must have automatically written a MBR on the drive.  At any rate, Ghost 12 obviously understood the Vista drive layout during the restore.

Another interesting fact about the Ghost 12 restore:  The c: Vista partition (on a Dell pc) is the 3rd partition on the physical hard drive.  However, it restored this 3rd partition to the 1st partition position on the clean/blank SATA drive; and it booted.  

The first partition is a Dell utility partition
The second partition is the Dell Recovery partition
The third partition is the Vista c: drive
The fourth partition is one I created by shrinking the c: partition, a d: data partition

In the past, it was necessary to edit boot.ini to "fix up" the boot process so it works.  Now Ghost 12 took care of everything automatically.

By the way, the sata drive had never been used as a boot device in XP, only as a secondary data volume.  And before I used the drive I checked with PM8 (under xp) and it said "First physical sector 63" for drive properties.  

My confidence of being able to restore my Vista Ghost 12 backup is good at this point.

Continuing from   http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1170184062/105#115

John, it's my understanding that if Vista is installed to an empty HD then the partition offset is 2048 sectors. This offset is only seen when Vista creates the partition. If you create the partition yourself and then install Vista to the partition, the offset is 63 sectors.


Quote:

The original Dell Vista c: partition has 2048 hidden sectors (i.e. an offset of 2048).

How did you determine this? I thought the offset related to the sectors from LBA-0. I'm confused as Vista was the third physical partition on the HD.

ptedit can be downloaded from  

ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/

(Third from bottom)

I've just read that ptedit32.exe will run in Vista. (same download site)

PTEdit does not run in Vista, but I got PTEdit32 to work.

It is confusing.  Here is the output from PTEdit for original Dell Vista PC:

http://i24.photobucket.com/albums/c5/ghostimage/PTEditVista.jpg


Here is the output from Terabyte PartInfo utility

PARTINFW 1.10
Copyright (c) 1996-2006 TeraByte, Inc.  All rights reserved.

Run date: 09/23/2007 14:40

====================================================================
          MBR Partition Information (HD0 - 0x18000000)
                        (CHS: 1023/254/63)
+====+====+=============+====+=============+===========+===========+
| 0: |  0 |    0   1  1 | de |    5 254 63 |        63 |     96327 |
| 1: |  0 |    6  30 25 |  7 | 1023 254 63 |     98304 |  20971520 |
| 2: | 80 | 1023 254 63 |  7 | 1023 254 63 |  21069824 | 322048000 |
| 3: |  0 | 1023 254 63 |  f | 1023 254 63 | 343117824 | 282021888 |
+====+====+=============+====+=============+===========+===========+
                        Volume Information
+----+----+-------------+----+-------------+-----------+-----------+
| 0: |  0 | 1023 254 63 |  7 | 1023 254 63 |      2048 | 282019840 |
| 1: |  0 |    0   0  0 |  0 |    0   0  0 |         0 |         0 |
| 2: |  0 |    0   0  0 |  0 |    0   0  0 |         0 |         0 |
| 3: |  0 |    0   0  0 |  0 |    0   0  0 |         0 |         0 |
           MBR Partition Information (HD0) Continued:
+====+====+=============+====+=============+===========+===========+
+====+====+=============+====+=============+===========+===========+
                          BOOT SECTOR INFORMATION
-------------------------------------------------------------------------------
File System ID: 0x7   LBA: 98304  Total Sectors: 20971520   ID: 0x2
                         Jump: EB 52 90
                     OEM Name: NTFS    
                Bytes Per Sec: 512
                Sec Per Clust: 8
                  Res Sectors: 0
                       Zero 1: 0x0
                       Zero 2: 0x0
                         NA 1: 0x0
                        Media: 0xF8
                       Zero 3: 0x0
                Sec Per Track: 63
                        Heads: 255
                  Hidden Secs: 98304
                         NA 2: 0x0
                         NA 3: 0x800080
                Total Sectors: 0x013FFFFF
                      MFT LCN: 0x0D5555
                 MFT Mirr LCN: 0x013FFFF
                Clust Per FRS: 0xF6
             Clust Per IBlock: 0x1
                    Volume SN: 0x42A42E66A42E5D23
                     Checksum: 0x0
                    Boot Flag: 0xAA55
-------------------------------------------------------------------------------
File System ID: 0x7   LBA: 21069824  Total Sectors: 322048000   ID: 0x3
                         Jump: EB 52 90
                     OEM Name: NTFS    
                Bytes Per Sec: 512
                Sec Per Clust: 8
                  Res Sectors: 0
                       Zero 1: 0x0
                       Zero 2: 0x0
                         NA 1: 0x0
                        Media: 0xF8
                       Zero 3: 0x0
                Sec Per Track: 63
                        Heads: 255
                  Hidden Secs: 21069824
                         NA 2: 0x0
                         NA 3: 0x800080
                Total Sectors: 0x013320FF0
                      MFT LCN: 0x0CCC0AA
                 MFT Mirr LCN: 0x01338182
                Clust Per FRS: 0xF6
             Clust Per IBlock: 0x1
                    Volume SN: 0xE004313E43118CC
                     Checksum: 0x0
                    Boot Flag: 0xAA55
-------------------------------------------------------------------------------
File System ID: 0x7   LBA: 343119872  Total Sectors: 282019840
                         Jump: EB 52 90
                     OEM Name: NTFS    
                Bytes Per Sec: 512
                Sec Per Clust: 8
                  Res Sectors: 0
                       Zero 1: 0x0
                       Zero 2: 0x0
                         NA 1: 0x0
                        Media: 0xF8
                       Zero 3: 0x0
                Sec Per Track: 63
                        Heads: 255
                  Hidden Secs: 2048
                         NA 2: 0x0
                         NA 3: 0x800080
                Total Sectors: 0x010CF47FF
                      MFT LCN: 0x0B34DAA
                 MFT Mirr LCN: 0x010CF47F
                Clust Per FRS: 0xF6
             Clust Per IBlock: 0x1
                    Volume SN: 0xF8D07646D0760B60
                     Checksum: 0x0
                    Boot Flag: 0xAA55
-------------------------------------------------------------------------------

John, that's too hard for me. Partitions 2, 3 and 4 are not starting on cylinder boundaries as we are used to seeing. But they do end on cylinder boundaries. Vista does this.
We are used to seeing partitions starting on Head 0, Sector 1. (Apart from the first primary partition which is Head 1, Sector 1)

The logical volume commencing at LBA: 343119872 has 2048 hidden sectors and this is typical of a logical volume created in Vista.

http://www.multibooters.co.uk/partitions.html

It's going to take time for this to sink into my brain.

Brian, as I mentioned earlier this is the Dell pc as delivered from Dell (except I split the 3rd Vista partition into two partitions)
1. Hidden diagnostic partition
2. Dell Recovery partition
3. Vista primary partition
4. Vista partition

The interesting thing about restoring the Vista Primary Partition (3rd one) onto a old SATA drive which I deleted the xp partitions, is that I ONLY restored the Vista Primary Partition.  and yet the old SATA drive booted fine without any intervention or repairs etc.  

That's a lot better than all the lengthy threads I have been following on the TI forum regarding offsets and repairs and TI.

I'm still not sure why Powerquest tool shows slightly different numbers than the Terabyte partition display tool for the same physical hard drive.

"The interesting thing about restoring the Vista Primary Partition (3rd one) onto a old SATA drive which I deleted the xp partitions, is that I ONLY restored the Vista Primary Partition.  and yet the old SATA drive booted fine without any intervention or repairs etc.

That's a lot better than all the lengthy threads I have been following on the TI forum regarding offsets and repairs and TI."


There seems to be a widespread misconception that the partition structure/location requirements are different for Vista vs. XP/earlier.  That's not so.  Vista works just fine in "normal" (let's call it legacy) partitions.  There is no mystery that a restored Vista partition should work in a legacy partition.  An image of a Vista OS partition, regardless of whether the original was 2048-offset or 63-offset, can be restored and work just fine on another partition, whether 2048- or 63-offset, or even something entirely different.  We all know an image of an XP partition can be restored to a different location on a disk, and the principle is the same here.  It doesn't matter what the offsets of the source or the target are.

What is different is the location of partitions that are created with the Vista partitioning programs.  It's important to separate this concept from Vista itself--don't think of it as a feature/requirement of Vista, it's a characteristic of the partitioning utility.  The Vista operating system doesn't care whether it's a 2048-offset or a 63-offset partition.  IOW, you can create a legacy partition with XP, PM8, or even fdisk, and Vista can be installed in that pre-created partition without any problem.  If you're creating the partition during the Vista install, however, then you're using the Vista partitioning utility, and that does not create legacy partitions.  Either way, the OS doesn't care.

Legacy partitions begin and end on cylinder boundaries.  "Cylinders" are a virtual concept, and have had no real meaning since the advent of IDE hard disks around a decade and a half ago.  The one exception to the cylinder-boundary rule is when the beginning of a cylinder needs to have a partition table, such as the very beginning of the disk (space needed for MBR/partition table) or the beginning of a logical partition (space needed for extended partition table--what PM8 refers to as an EPBR).  In those cases, the following partition starts one "track" (another virtual concept) later.  Most disk manufacturers implement the notion of tracks with 63 sectors--hence, the familiar 63-sector offset practice to which we have all become accustomed.

But remember, the notion of cylinders and tracks has been obsolete for a long time, and disks have just been faking it all these years.  Utilities like PM8, ptedit, and partinfo, as well as nearly every other utility in the world, have continued the charade to avoid upsetting old operating systems.  The Vista disk partitioner simply says to heck with old operating systems and abandons the concept altogether.

Rather than cylinders and tracks, think of the Vista partitioner as using units or blocks of 2048 sectors.  (Assorted TI threads have links to the Microsoft pages attempting to explain how they came up with 2048, but that's not important here.  The important thing is Vista can use anything, and Microsoft has settled on 2048, like it or not.)  The Vista partitioner will create partitions that align on 2048-sector blocks.  If a block has a partition table, the following partition will begin one block--2048 sectors--later.  Pretty simple.

Now, what's confusing everyone is that legacy utilities will continue to display partition information as though they were legacy partitions, with cylinders and tracks.  They're not wrong, but it is confusing.  They're not wrong because disks still use legacy partition tables (for now), so the Vista partitioner has to create those (ahem) "wrong" numbers to put in the legacy partition table.  So the Vista partitioner manufactures numbers than look wrong, puts them in the partition table, the legacy tools read those numbers, and show them to you.  No wonder you get confused.

This is a long-winded way of saying you don't need to avoid the legacy tools, but you do need to understand what they are showing you.  The only numbers that are really relevant are the sector-offset and partition size.  Sector-offset is denoted as "Sectors Before" in ptedit and "Hidden Sectors" in PartInfo.  The size of the partition in sectors is shown as "Sectors" in ptedit and "Total Sectors" in PartInfo.

For an illustration of how this all plays out, let's consider Ghost4me's original Dell hard disk.

The first primary partition was created with a legacy utility.  We know the MBR/partition table is on cyl/hd/sec 0/0/1.  (Remember, it's still a legacy partition table, so it's going to show cyl/head/sec values, even though the numbers are imaginary).  That means the first legacy partition cannot start before CHS 0/1/1.  This disk's parameters are 38913 cylinders, 255 heads (tracks) per cylinder, and 63 sectors/track.  LBA sector numbers are zero-based, so CHS 0/1/1 is equivalent to LBA-63--the "offset" shown in the partition table.

Having been created with a legacy utility, the first partition ends on the boundary between cylinder 5 and 6, offset 96390 sectors (63+96327) from the partition table.  Note that one cylinder is 16065 sectors (255*63), and 6 full cylinders (cyls 0-5) would be 96390 sectors (16065*6).  All the numbers fit.

A legacy partitioner would start the second partition at CHS 6/0/1, or LBA-96390 (and that's what you'd see on the old XP systems).  However, the second partition was created with the Vista partitioner.  The Vista partitioner interpets partition-1 as ending in the middle of a 2048-sector block:  96390/2048 = 47.07 blocks.  So partition-2 is created beginning with the next full block.  48*2048=98304, so the next full block begins on the 98305th sector, which is 98304 sectors offset from the first sector, where the partition table is.  In CHS terms, the 98305th sector (LBA-98304 in the zero-based LBA enumeration) translates to CHS 6/30/25:  (6*16065)+(30*63)+25 = 98305.  But remember, the Vista partitioner--and the Vista OS--don't care about imaginary CHS boundaries.

You can do the math for the rest of the numbers:

Partition-2 ends at LBA-sector 21,069,824 (98304+20971520), and 21069824/2048=10,288 full blocks.

Partition-3 begins at offset 21,069,824, and ends at 343,117,824 (21069824+322048000), which is 167,538 full blocks into the disk.

Partition-4 begins at offset 343,117,824 and ends at 625,139,712, which is 305,244 full blocks into the disk.

Now, realize that partition-4 is an extended partition (type 0F).  That means the primary partition table actually points to an extended partition table, which precedes the logical partition itself.  So, "partition-4", which begins on LBA-343117824, is actually another partition table.  The logical partition begins one block later--an offset of 2048 sectors from the extended partition table, not from the primary partition table.  (FTR, a legacy partitioner would have placed the logical partition 63 sectors after the extended partition table.)

Ghost4me should note that the PartInfo report does not show the extended partition in the "Boot Sector Information" part of the report, it shows the logical volume that is within the extended partition.  Hence, the 2048 "Hidden Sectors" and the file system ID of 0x07.  IOW, there is no inconsistency between ptedit and PartInfo, as long as you understand what they are showing you.

As for why an image of the original 2048-offset partition restores as a 63-offset partition, consider the partitioner.  When you restore an image on a blank disk, Ghost must create a partition first, then fill it with the contents of the image.  Ghost is the partitioner.  And it's creating partitions the legacy way.  But, again, it doesn't matter to the OS.

Dan Goodell

Excellent explanation--very enlightening.



Ghost4me


Quote:

1. I deleted the partitions in XP, so it was empty.

Well, that space on the HDD was converted to *unallocated* space, but you later say:


Quote:

I have another partition on the physical hard drive.

So, the HDD has a layout structure, the MBR was present and occupies the absolute sector 0, and the boot region of sectors 0 thru 62 (total of 63) is present on the HDD--so it is not a *virgin* empty HDD.


Quote:

* Restore MBR was NOT checked.

When doing a *Partition* restore to a HDD with an existing partition structure--my experience with other versions of Ghost has been that it, by default, will refuse to alter the existing MBR, except to update the Master Partition Table if the layout has been altered as far as starting and stopping addresses of the partitions.


Quote:

* There was an option called "Restore original disk signature".

I think that's one of the alterations to the default settings if you want to use Ghost 2003 to save and restore a Vista partition without using the *bcdedit* changes to the new Vista boot setup.


Quote:

* In fact, I couldn't modify any of the options.

Those are probably the needed settings to avoid having a boot failure when restoring a Vista partition!


Quote:

Conclusion:  I had expected to have needed to perform a Vista boot repair or edit the bcd because the "restore MBR" option was not checked.  I assume that Ghost 12 must have automatically written a MBR on the drive. At any rate, Ghost 12 obviously understood the Vista drive layout during the restore.

The drive already had the boot region present with a MBR--because the option to restore the MBR could not be selected, I doubt Ghost 12 wrote a new MBR--just updated the Master Partition Table because you changed the partition layout by restoring your backup to that unallocated space.


Quote:

In the past, it was necessary to edit boot.ini to "fix up" the boot process so it works.  Now Ghost 12 took care of everything automatically.

Yes, for WinXP--but now Vista no longer has the *boot.ini* file--but glad to see Ghost 12 handled the restore of Vista without a hitch!

Dan, thanks for your extensive comments!  

NightOwl --

Quote:

Quote: 1. I deleted the partitions in XP, so it was empty. Well, that space on the HDD was converted to *unallocated* space, but you later say: Quote: I have another partition on the physical hard drive. So, the HDD has a layout structure, the MBR was present and occupies the absolute sector 0, and the boot region of sectors 0 thru 62 (total of 63) is present on the HDD--so it is not a *virgin* empty HDD.

The HDD was never a boot HDD.  It was used as a data HDD with XP.  I used the XP Disk Manager to delete the partitions, but never wiped the drive etc.  I wanted to see what Ghost would do with an empty (not virgin) XP HDD.


Quote:

Quote: * In fact, I couldn't modify any of the options. Those are probably the needed settings to avoid having a boot failure when restoring a Vista partition!

I think it was my fault I couldn't modify any of the options.  I was using a PS2 keyboard connected to a PS2/serial add-in card on the Dell pc.  I'm guessing that the Ghost 12 Boot CD didn't recognize the keyboard; and thus I couldn't modify the settings.  I haven't retried it yet.


Quote:

Quote: In the past, it was necessary to edit boot.ini to "fix up" the boot process so it works.  Now Ghost 12 took care of everything automatically. Yes, for WinXP--but now Vista no longer has the *boot.ini* file--but glad to see Ghost 12 handled the restore of Vista without a hitch!

It appears that the BCD (or maybe it is Vista) is more intelligent--I took the one Vista boot partition (the third one in order) from a HDD that had four partitions and restored it as the ONLY partition on another HDD and it booted.  Again the other HDD had never been booted before, so I don't know who wrote the boot code on the HDD.  I never told XP in the past to make it bootable.

(It would be nice if Symantec provided some technical details of what Ghost 12 is actually doing in different scenarios; of course that would ruin the fun of users just speculating... )

I'm happy that the Vista restore just worked so easily.

In the True Image forum, Mustang commented on Ghost 12 ...


Quote:

both Norton Ghost 12 and Symantec Backup Exec 7 Desktop Edition are able to handle the Vista 2048 sector partition offset. No repair is needed and the 2048 sector offset is maintained after the restore.

The 2048 sector offset wasn't relevant in Ghost4me's test and Dan explains why we don't need be so concerned with the offset anyway. But not having to do a BCD repair is a big advantage with any imaging software.

In this forum we haven't had many reports on restoring Vista images with Ghost 12. Thanks Ghost4me.

Dan Goodell wrote on Sep 30^th, 2007 at 5:39am:

...As for why an image of the original 2048-offset partition restores as a 63-offset partition, consider the partitioner.  When you restore an image on a blank disk, Ghost must create a partition first, then fill it with the contents of the image.  Ghost is the partitioner.  And it's creating partitions the legacy way.  But, again, it doesn't matter to the OS.

Brian, from the quote above, it seems that all the True Image unbootable problems are NOT Vista related but partitioner-related.  The causes of these seem to be bugs in the way True Image creates or modifies the partitions as part of the Vista restores.

Do you agree with that conclusion?  I know we have both been following several of the long threads in the True Image forums regarding Vista offset and BCD editing and repair issues with TI.

Brian, how does ShadowProtect Desktop 3.0 handle this situation with Windows Vista?

Ghost4me,

I do agree it's a TI problem. If you image a 2048 sector offset Vista partition with True Image 10 and 11 and then restore the images, you get two different results. With TI 10 the offset is changed to 63 and the OS requires a repair to boot (missing winload.exe error). With TI 11 the offset is changed to 63 and the OS boots without a repair.

Pleonasm, I don't have Vista and I haven't read any reports about how ShadowProtect handles a Vista restore.

Ghost4me, do you have any spare time? It looks like you are the only member able to do any testing with Ghost 12 and Vista. I'd be interested to hear if the restore choices are greyed out again. I've done lots of restores with WinXP and the choices are always available. I'd also be interested to hear how Ghost 12 handles restoring a 2048 sector offset image to a zeroed (wiped) HD.

Brian wrote on Oct 1^st, 2007 at 3:43pm:

I'd also be interested to hear how Ghost 12 handles restoring a 2048 sector offset image to a zeroed (wiped) HD.

I plan to retest with usb keyboard and wiped sata drive.  I haven't found a wipe utility yet that comes with a boot cd AND works with SATA drive. I think the Seagate DOS utility will work with SATA on the Dell pc, but haven't tried it yet.  It didn't work on the other pc with SATA.

CopyWipe should work.

http://www.terabyteunlimited.com/copywipe.php

Brian, I too don't yet have Windows Vista.  I did notice, however, that ShadowProtect stores within the image file itself several attributes of the volume that was imaged, including "Number of First Track Sectors".  This suggests that a restore would duplicate the original partition offset, but we won't know for sure until someone is able to test it.

http://forum.storagecraft.com/Community/forums/t/40.aspx

Brian wrote on Oct 2^nd, 2007 at 8:51am:

http://forum.storagecraft.com/Community/forums/t/40.aspx

Brian, what did you mean by your comment,  "I don't have Vista but I'd be interested to hear how SP Desktop handles restoring a 2048 sector offset Vista image to a wiped (zeroed) HD. True Image and Ghost 12 have slight problems."

I'm not aware of any Ghost 12 problems or slight problems with Vista yet.

Ghost4me,
RE:  “I haven't found a wipe utility yet that comes with a boot cd AND works with SATA drive” (Reply #13)

What about using GDisk, executed from a DOS floppy diskette?

* * * * * * * * * *
Brian, thanks for the link to the StorageCraft forums (Reply #16)!

Ghost4me,

I've seen "unofficial" information that suggests the 2048 sector offset is not preserved when restoring a Vista Ghost 12 image to a wiped HD. This needs to be confirmed.

Brian wrote on Oct 2^nd, 2007 at 9:45am:

Ghost4me, I've seen "unofficial" information that suggests the 2048 sector offset is not preserved when restoring a Vista Ghost 12 image to a wiped HD. This needs to be confirmed.

I didn't mean to imply that I think Ghost 12 has NO bugs or problems.  In fact there was a LiveUpdate to Ghost 12, which I assume fixed a few things; but no one can seem to obtain any documentation about what was in it.

Although I have been a vocal denigrator of Symantec's technical support policies, in general their software releases seem to have fewer bugs than the competitors.  And in the field of image backup and restores, that is probably the most important consideration.

(I have completed my usb keyboard and wiped retest.  Details to follow)

Ghost4me,
RE:  “Although I have been a vocal denigrator of Symantec's technical support policies . . .”

Have you looked at the ShadowProtect forums?  I am in awe of the level of responsiveness and helpfulness provided by StorageCraft.

I retested a restore with Ghost 12.  I used a usb keyboard.  Before restoring, I wiped the SATA drive with Seagate SeaTools.

I captured the partition tables with the same two tools I used previously.  See results at the bottom.

I still was NOT able to change the options.  I could navigate with the usb keyboard so I know it was recognized, but I couldn't change the restore options.  Here are the options that Ghost used, which I copied down.  X means it was in effect, and blank, not used:

Options:
X  Verify Recovery Point before Restore
   Check for file system errors after recovery
   Resize restored drive

Advanced Options:
X  Set Drive Active
X  Restore original disk signature
   Restore MBR

Results and conclusions:

With the zeroed/wiped drive, once again, it booted into Vista without any intervention (well, same message at startup that Windows didn't shutdown properly, but otherwise no messages).

I restored the same 3rd partition (the Vista c: drive) into the zeroed/wiped drive as the only partition.  Note that the offset is 63.  My guess is that is because Dell placed the offset at 63, so Ghost 12 didn't relocate it.  Vista didn't complain one bit.

I guess if someone had a Vista system where it is originally at 2048 offset, it would be interesting to see if Ghost 12 would relocate it on restore.

My conclusion again:  Very painless restore and no Ghost 12 or Vista problems twice now.


http://i24.photobucket.com/albums/c5/ghostimage/PQPTEVistaG12restore.jpg


PARTINFW 1.10
Copyright (c) 1996-2006 TeraByte, Inc.  All rights reserved.

Run date: 10/02/2007 9:22

====================================================================
          MBR Partition Information (HD5 - 0xAFFCE7BE)
                        (CHS: 1023/254/63)
+====+====+=============+====+=============+===========+===========+
| 0: |  0 |    0   1  1 |  7 | 1023 254 63 |        63 | 488392002 |
| 1: |  0 |    0   0  0 |  0 |    0   0  0 |         0 |         0 |
| 2: |  0 |    0   0  0 |  0 |    0   0  0 |         0 |         0 |
| 3: |  0 |    0   0  0 |  0 |    0   0  0 |         0 |         0 |
+====+====+=============+====+=============+===========+===========+
                          BOOT SECTOR INFORMATION
-------------------------------------------------------------------------------
File System ID: 0x7   LBA: 63  Total Sectors: 488392002   ID: 0x1
                         Jump: EB 52 90
                     OEM Name: NTFS    
                Bytes Per Sec: 512
                Sec Per Clust: 8
                  Res Sectors: 0
                       Zero 1: 0x0
                       Zero 2: 0x0
                         NA 1: 0x0
                        Media: 0xF8
                       Zero 3: 0x0
                Sec Per Track: 63
                        Heads: 255
                  Hidden Secs: 63
                         NA 2: 0x0
                         NA 3: 0x800080
                Total Sectors: 0x01D1C4541
                      MFT LCN: 0x013682E2
                 MFT Mirr LCN: 0x01D1C454
                Clust Per FRS: 0xF6
             Clust Per IBlock: 0x1
                    Volume SN: 0x4EF801E8F801CEE1
                     Checksum: 0x0
                    Boot Flag: 0xAA55
-------------------------------------------------------------------------------

John, thanks again. That's reassuring.

I gather the problem is with Vista installs that have a 2048 sector offset. They may have problems with restoring the image to a wiped HD.

This is the situation when someone restores a Vista image to a new blank HD.


Quote:

I still was NOT able to change the options.

My "unofficial" information mentioned this too.

Pleonasm wrote on Oct 2^nd, 2007 at 11:55am:

Ghost4me, RE:  “Although I have been a vocal denigrator of Symantec's technical support policies . . .” Have you looked at the ShadowProtect forums?  I am in awe of the level of responsiveness and helpfulness provided by StorageCraft.

Yes.  I think it is a natural phenomenon that newer and/or smaller companies are often more responsive.  I read a newspaper article recently that compared Google vs. Microsoft in the same way that Microsoft muscled in on IBM years ago.  Of course you have to have a good product along with it.  But smaller can be better.

Brian wrote on Oct 2^nd, 2007 at 12:16pm:

I gather the problem is with Vista installs that have a 2048 sector offset. They may have problems with restoring the image to a wiped HD.

Brian, that is what I have been reading also.  However, I don't have a retail Vista DVD so I can't test that theory or possible restore problem with Ghost 12 and Vista.  And again, I haven't read of it happening with Ghost 12 software, just others (primarily TI10 and TI11).

Ghost4me wrote:
"I restored the same 3rd partition (the Vista c: drive) into the zeroed/wiped drive as the only partition.  Note that the offset is 63.  My guess is that is because Dell placed the offset at 63, so Ghost 12 didn't relocate it."

If you're talking about the Vista partition on your original Dell disk, it was on a 2048-aligned partition, not a cylinder-aligned legacy partition.

Dan Goodell wrote on Oct 2^nd, 2007 at 3:02pm:

Ghost4me wrote: "I restored the same 3rd partition (the Vista c: drive) into the zeroed/wiped drive as the only partition.  Note that the offset is 63.  My guess is that is because Dell placed the offset at 63, so Ghost 12 didn't relocate it." If you're talking about the Vista partition on your original Dell disk, it was on a 2048-aligned partition, not a cylinder-aligned legacy partition.

Oops.  You're right (see below) which I copied from post #3.  Thanks!

Brian, now that Dan corrected my error, it appears that Ghost 12 does correctly restore a Vista offset of 2048 and restores it without any boot problem (even though it places it with an offset of 63).


Quote:

File System ID: 0x7   LBA: 343119872  Total Sectors: 282019840                          Jump: EB 52 90                      OEM Name: NTFS                     Bytes Per Sec: 512                 Sec Per Clust: 8                   Res Sectors: 0                        Zero 1: 0x0                        Zero 2: 0x0                          NA 1: 0x0                         Media: 0xF8                        Zero 3: 0x0                 Sec Per Track: 63                         Heads: 255                   Hidden Secs: 2048                          NA 2: 0x0                          NA 3: 0x800080                 Total Sectors: 0x010CF47FF                       MFT LCN: 0x0B34DAA                  MFT Mirr LCN: 0x010CF47F                 Clust Per FRS: 0xF6              Clust Per IBlock: 0x1                     Volume SN: 0xF8D07646D0760B60                      Checksum: 0x0                     Boot Flag: 0xAA55 -------------------------------------------------------------------------------

                   

Ghost4me, this has been a long (but good) thread.  Maybe you could author a “summary post” to consolidate your insights, and add this thread to the FAQs?  I have the feeling that it will become handy in the future.

Thanks!

Dan Goodell wrote on Oct 2^nd, 2007 at 3:02pm:

If you're talking about the Vista partition on your original Dell disk, it was on a 2048-aligned partition, not a cylinder-aligned legacy partition.

Dan, wasn't it the logical volume that had the 2048 sector offset? The partition containing the Vista OS had a 63 sector offset.

"wasn't it the logical volume that had the 2048 sector offset? The partition containing the Vista OS had a 63 sector offset. "


Technically, the logical partition had an offset of 343119872.  That was 2048 after the EPBR (the extended partition table), which itself had an offset of 343117824 from the beginning of the disk.

The Vista OS partition was the third partition, whose offset was 21069824.  When we talk of a 2048 offset, we should really mean a partition aligned on blocks of 2048 sectors.  The offset will be exactly 2048 only if the partition is one block after the partition table--ie, the first partition after the table that references that partition.  If it's not the first partition, the offset won't be exactly 2048, but it will be some multiple of 2048.

21069824 is an exact multiple of 2048, but is not an exact multiple of 16065 (the size of a cylinder).  So the Vista partition on the original Dell disk was aligned on 2048-sector blocks, not on whole cylinders.

The only cylinder-aligned partition on the Dell disk was the first partition (the small Dell Utility partition).  BTW, in case people missed this point, notice that it is permissible to mix cylinder-aligned and 2048-aligned partitions on the same disk.  That's exactly what Dell is doing on all their Vista systems.  (You do end up with a small amount of wasted space, though, at the point where the alignment switches from cylinders to 2048s.  In Ghost4me's disk, the wasted sectors are 96390-98303.)

So, the remaining question is "Why does Ghost 12 relocate the Vista partition restore from offset of 2048 to one of 63?" (even though it appears to cause no harm).

Ghost4me


Quote:

So, the remaining question is "Why does Ghost 12 relocate the Vista partition restore from offset of 2048 to one of 63?"

I'm going to bet it's because Ghost 12's ability to create a new MBR on a HDD that is either brand new (virgin), or wiped to re-create the *virgin* state, by design, is to create the old style MBR with the 63 boot region--and is not programed like the new Vista partitioning tool that has abandoned the old 63 sectors, and now uses the 2048 sector offset.

Quote:

When we talk of a 2048 offset, we should really mean a partition aligned on blocks of 2048 sectors.  The offset will be exactly 2048 only if the partition is one block after the partition table--ie, the first partition after the table that references that partition.  If it's not the first partition, the offset won't be exactly 2048, but it will be some multiple of 2048.

Well I cocked that up. I think I now understand what the offset means.

"I think I now understand what the offset means."

I hope I wasn't misleading anyone into thinking I was defining the term.  Offset is just as it sounds: the relative difference from some reference point to the beginning of the partition, as measured in sectors.  A 2048-sector offset would literally mean a partition that is 2048 sectors after the partition table.

But that only describes a very narrow group--specifically, the first partition and only the first.  But of course, the operating system partition need not be the first partition.  The broader matter we're discussing is the difference between a partition, first or otherwise, that is aligned on cylinder boundaries versus a partition, first or otherwise, that is aligned on blocks of sectors, where those blocks contain 2048 sectors each.  It could be the first partition, with an offset of 2048, or it could be a subsequent partition, whose offset is not 2048 but is some multiple of 2048 (because it can be defined by some number of full blocks).

That's what I meant by, "When we talk of a 2048 offset, we should really mean a partition aligned on blocks of 2048 sectors."  That's not the definition of a 2048 offset, which would literally be only the first partition.  Yet, the first partition is no different from the second, or third--they're all aligned on full blocks, where the block size is 2048 sectors.  The issue being discussed isn't restricted to just the first partition, but any partition that is aligned on blocks of 2048 sectors.  That's what I'm calling 2048-aligned.  Others may call these Vista partitions, but I think that's misleading because Vista doesn't require 2048-aligned partitions, and because it confuses whether we're talking only about the Vista OS partition or mean to include non-OS partitions, as well.

The same goes for references to "63 offset" partitions.  Again, a 63 offset would literally be only the first partition, but what's really being discussed is partitions aligned along cylinder boundaries, first or otherwise.  I choose to call these cylinder-aligned, or simply legacy partitions.

With his experiments, Ghost4me was seeking to explore the conversion from one type of partition alignment, 2048-aligned vs cylinder-aligned, to the other.  The issue wasn't converting from some specific offset xxx to offset yyy.  That, I'm sure, is already familiar territory to everyone.  We all know you can Ghost from one partition to another--from a partition at offset xxx to a partition at offset yyy--so there's no mystery as far as that goes.

Dan, I feel I could lecture on the topic now.


John, you have convincingly shown that a Ghost 12 restored Vista image doesn't need a BCD repair. That's good because you mentioned that you didn't have a retail Vista DVD. I gather recovery discs can't do the repair.

This BartPE plugin claims to work.

http://www.wilderssecurity.com/showthread.php?p=1005755#post1005755

Brian wrote on Oct 4^th, 2007 at 12:19am:

John, you have convincingly shown that a Ghost 12 restored Vista image doesn't need a BCD repair. That's good because you mentioned that you didn't have a retail Vista DVD.

Brian, I don't have a retail Vista DVD.  However, Dell does provide a DVD with their Vista pc's.  On the front it says, "Reinstallation DVD, Windows Vista Home Premium 32bit" and also says "for distribution only with a new Dell PC".  I didn't use it (or need to use it), and I assume it is customized for Dell pc's.

You can also obtain an official Microsoft Vista DVD for $5 from CompUSA according to this True Image thread (reply #5).  I ordered one but haven't received it yet.

Fix Vista so a Repair is not needed after a restore or clone

CompUSA Windows Anytime Upgrade Disc, NAmerica, English, 32 bit by Microsoft  (PC)