Much info from the two of you, thanks...

I want to start with my new partinfo run today with 3 primary partitions:



PARTINFW 1.11
Copyright (c) 1996-2008 TeraByte, Inc.  All rights reserved.

Run date: 12/01/2010 12:25

====================================================================
           MBR Partition Information (HD0 - 0x47EE47ED)
           (CHS: 1023/254/63) (WCHS: 19457/255/63)
+====+====+=============+====+=============+===========+===========+
| 0: | 80 |    0   1  1 |  7 | 1022 254 63 |        63 |  32772537 |
| 1: |  0 | 1023 254 63 |  7 | 1023 254 63 |  32772600 | 153597465 |
| 2: |  0 | 1023 254 63 |  7 | 1023 254 63 | 186370065 | 126206640 |
| 3: |  0 |    0   0  0 |  0 |    0   0  0 |         0 |         0 |
+====+====+=============+====+=============+===========+===========+
                           BOOT SECTOR INFORMATION
-------------------------------------------------------------------------------
File System ID: 0x7   LBA: 63  Total Sectors: 32772537   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: 0x01F411B8
                       MFT LCN: 0x0C0000
                  MFT Mirr LCN: 0x010
                 Clust Per FRS: 0xF6
              Clust Per IBlock: 0x1
                     Volume SN:
                      Checksum: 0x0
                     Boot Flag: 0xAA55
-------------------------------------------------------------------------------
File System ID: 0x7   LBA: 32772600  Total Sectors: 153597465   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: 32772600
                          NA 2: 0x0
                          NA 3: 0x800080
                 Total Sectors: 0x0927B618
                       MFT LCN: 0x0C0000
                  MFT Mirr LCN: 0x0927B61
                 Clust Per FRS: 0xF6
              Clust Per IBlock: 0x1
                     Volume SN:
                      Checksum: 0x0
                     Boot Flag: 0xAA55
-------------------------------------------------------------------------------
File System ID: 0x7   LBA: 186370065  Total Sectors: 126206640   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: 186370065
                          NA 2: 0x0
                          NA 3: 0x800080
                 Total Sectors: 0x0785C2AF
                       MFT LCN: 0x0C0000
                  MFT Mirr LCN: 0x0785C2A
                 Clust Per FRS: 0xF6
              Clust Per IBlock: 0x1
                     Volume SN:
                      Checksum: 0x0
                     Boot Flag: 0xAA55
-------------------------------------------------------------------------------


From what I understand from Dan's first post, the first line must be suspicious:

| 0: | 80 |    0   1  1 |  7 | 1022 254 63 |        63 |  32772537 |





I have never used any partitioning tool on this machine, BUT, when the machine was new
2 years ago, the first I did was to install Ghost 2003 and start it (from Windows    ).
DISK-image to an SD-card(not bootable ) was the first thing I did on this Asus. I didn't manage to get rid of my EFI partition at that time.

I wanted a fresh image as recovey later, and I wanted to repartition my Disk to get a small C.
So when restoring that DISK-image shortly after I let Gost resize my C to 16002 GB.
Done by DISK from IMAGE in DOS-Ghost, but started from Windows.

After that I made an extended partition with 3 logical partitions from WINDOWS Disk-management
into unallocted space on C. No other partitioning tool.

And all was well for two years. I have only made PARTITION to IMAGE and PARTITION from IMAGE
for my C part to and from D, E and F more than 20 times without a problem.

All this was started from the Windows interface, didn't know better.

But I thought it worked well, but nearly 2 years later I was not capable of seeing
my E and F from Ghost-Windows interface, only D.

An important point here is that I now booted into DOS-Ghost and then I could see
ALL my partitions as in Windows Disk-management, too.

The rest of the story you know.  I could have continued using Ghost-Dos
which worked, but wanted to sort out why Ghost in windows all of a sudden could no longer see what it had seen for nearly 2 years.

Any partitioning tools I can swear have never been used here, but the only things that comes to mind is
testing two imaging tools as mentioned earlier in this thread, and even making a boot-cd from one of them to try.

I feel a bit lost , but if Ghost 2003 cant be used from Windows safely but only from DOS, its bad that this
is not a known fact by the users.

MORE..

xcurious wrote on Dec 1^st, 2010 at 6:29am:

Yes, you're correct.


xcurious wrote on Dec 1^st, 2010 at 8:11am:

You're heading in the right direction, but slightly off-track.  (pun intended)  They should actually be 1023-0-1, 1023-254-63.

My earlier posts were with regard to logical volumes in an extended partition.  Your second and third partitions are primary partitions.  Note where I stated in my Reply #55:

"Partitions were always divided along cylinder boundaries, except when it was preceded by a partition table, in which case the starting point was offset by one track.  Thus, partitions always began on Sector 1 of Head 0 or 1 on a particular Cylinder, and always ended on Sector 63 of Head 254 on some other Cylinder."

Volumes in the extended partition are always preceded by a (secondary) partition table, so the volume itself must begin on Head 1--i.e., one track later.  The first primary partition is preceded by the (primary) partition table, but other primary partitions do not have a separate partition table in front of them.  They are instead defined by descriptors in the primary partition table.  Consequently, while the first primary partition has to be shoved back to Head 1, other primary partitions begin on Head 0.

FTR, note that all of this discussion refers to legacy, cylinder-aligned partition layouts.  Vista and Win7 introduced a new, megabyte-aligned layout that disregards cylinders and heads/tracks, but that's off-topic here.


xcurious wrote on Dec 1^st, 2010 at 8:11am:

In order to answer that, we'd really need to determine what created the problems.  Note that, as you've recognized, your primary partition table also has anomalies.  So simply avoiding extended partitions probably isn't the solution.

It isn't clear what caused your primary partition table anomalies.  Apparantly, you have already run Ghost 2003 from Windows on this setup, so it's possible Ghost's Windows front-end messed things up.

Or, perhaps the anomalies were created by the partitioning tool that originally created the partitions--it may have even come from the factory that way.

It's not clear what tool created the partitions, but it's evident that they were not created by Microsoft tools (such as XP's Diskpart utility).  Microsoft's tools have a habit of leaving a 1-cylinder gap (8 MB) behind each partition, but all your partitions butt up against each other, with no gaps.  This can be seen in the following calculations:




xcurious wrote on Dec 1^st, 2010 at 6:29am:

It's common knowledge amongst techs, but not by the brainwashed masses.  And Symantec, of course, wants you to keep buying new versions, so they're going to tell you only the latest version is safe to use.

My own opinion is that the Windows interface to DOS-Ghost was primarily a marketing move.  Ghost 2002-2003 came out when many self-proclaimed "experts" (with help from Microsoft) were on a mission to convince everyone that, "Windows=good, DOS=bad."  The public was being brainwashed, and to avoid getting hammered by the competition Norton took their reliable, bullet-proof DOS utility, cobbled together a Windows go-between, and crafted a creative process of running it (that wierd, reboot into DOS, reboot back into Windows) that Rube Goldberg would be proud of.

FTR, I still use Ghost 2003, but only from DOS.  I limit it to its intended purpose--imaging and restoring the contents of partitions--and it works fine.  I do not use it to create or resize partitions, only to capture/restore partitions created by proper partitioning tools.  It will even image/restore Win7 OS partitions from DOS.  Like any program, you just need to understand its capabilities and limitations.

@

Thanks to both of you so far.

I will be back in a while with more information (and questions  probably too    ) .

Trying to get 'back on track' to follow Dan's terminology. 

I now deleted Partition D in Windows and made 1 new partition D and free space to accomodate partition E.


Here is what partinfo shows:


PARTINFW 1.11
Copyright (c) 1996-2008 TeraByte, Inc.  All rights reserved.

Run date: 12/02/2010 19:04

====================================================================
           MBR Partition Information (HD0 - 0xFF1AFF1A)
           (CHS: 1023/254/63) (WCHS: 19457/255/63)
+====+====+=============+====+=============+===========+===========+
| 0: | 80 |    0   1  1 |  7 | 1023 254 63 |        63 |  32772537 |
| 1: |  0 | 1023 254 63 |  7 | 1023 254 63 |  32772600 | 143364060 |
| 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: 32772537   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: 0x01F411B8
                       MFT LCN: 0x0C0000
                  MFT Mirr LCN: 0x010
                 Clust Per FRS: 0xF6
              Clust Per IBlock: 0x1
                     Volume SN:
                      Checksum: 0x0
                     Boot Flag: 0xAA55
-------------------------------------------------------------------------------
File System ID: 0x7   LBA: 32772600  Total Sectors: 143364060   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: 32772600
                          NA 2: 0x0
                          NA 3: 0x800080
                 Total Sectors: 0x088B8FDB
                       MFT LCN: 0x0C0000
                  MFT Mirr LCN: 0x088B8FD
                 Clust Per FRS: 0xF6
              Clust Per IBlock: 0x1
                     Volume SN:
                      Checksum: 0x0
                     Boot Flag: 0xAA55
-------------------------------------------------------------------------------

Am I doing something wrong here?

Thanks.   

xcurious wrote on Dec 2^nd, 2010 at 12:08pm:

It's not a big deal, so don't fret too much over it.  Windows (and linux, apparantly) use the LBA numbers in the last two fields and so are pretty tolerant of anomalies in the CHS fields.  As I see it, there are basically three ways you can deal with this:

(1) Use a better partitioning tool, such as BING or Partition Magic, which have a reputation for consistently getting the descriptors right.

(2) Use ptedit32 to manually fix the partition table descriptors.  As I mentioned, the partitions themselves seem to be fine, with only the 16-byte descriptors in the partition table showing any anomalies.  It's easy enough to overwrite them with ptedit32, and it only takes a minute or two to do.

(3) Ignore the anomalies.  Windows doesn't really care.

Dan Goodell wrote on Dec 1^st, 2010 at 5:02am:

Update:  I used VirtualPC to do an experiment, installing Ghost 2003 in a XP virtual machine.  Using Partition Magic on a virtual disk, I created a partition layout modeled after the layout in Reply #12, except that PM inserted all the correct numbers in the descriptors.  That gave me a known-good "control" PartInfo.  After running a whole-disk image/restore from Windows with Ghost 2003, the "after" PartInfo exhibited several of the 1022-vs-1023 anomalies and rollover anomalies, as described in my Reply #55.  I saw no evidence of the overlapping partitions described in Reply #56.

Disclaimer: personally, I've always used "partition-to-image" from a DOS boot, not "disk-to-image".  So my experiment doesn't rule out whether the anomalies are the result of Ghost's "disk-from-image" restore process, or whether it has something to do with the Windows front-end.  (Offhand, the former seems more likely.)

Nevertheless, this quick experiment suggests the anomalies in xcurious' PartInfo in Reply #3 and DL258's PartInfo in Reply #15 may well have been caused by Ghost, but DL258's PartInfo in Reply #12 must have been caused by some other third-party partitioning tool.

Brian

Quote:

Whoooosh!

Did you hear that sound?!  That was concepts flying over my head with little or no understanding of what's going on!!!!

Okay, what I thought I knew: 

I thought the partition tables where created by a partitioning tool and stored on the HDD. 

The BIOS queries the HDDs to see what's connected.  Usually, the BIOS is set to *auto* mode, and detects what the cylinder, heads, and sectors (the CHS) of the HDD are--and on large HDDs, basically ignores that information and uses LBA data instead.  And in by-gone days, if your BIOS could not automatically detect the CHS of your HDD, you had to *manually* enter that data!

In the statement above, the first part seems to validate what I thought I knew:

Quote:

Okay, so PartInfo is reporting what the HDD geometry is--that makes sense!

But,

Quote:

So, this I don't understand!  Is the BIOS telling the partitioning tool what *geometry* is to be used?  And that's how we get the *1022* showing up in the partition tables?

And, it appears that most programs (like Windows Disk Management) seem to simply ignore that aspect of the partition table anyway, and simple use the LBA information to find the boundaries of the partitions.

So, what's the purpose of the:

Quote:

Is this the result of the BIOS telling the partitioning tool what to do?

If this is *common*--then, I have to believe that the original problem of partitions not showing up any longer in the Windows Ghost interface has absolutely nothing to do with the *anomaly* noted in the original *PartInfo* information!

And now:

Quote:

So, what exactly did *BING* do here?!  Did it re-write the partition tables to reflect a different geometry?  Or, did it simply report the existing *1022 254 63* geometry with different internally calculated numbers so now it *reports*  the *1023 254 63* numbers?

So, what exactly *is* the geometry of your HDD?

And Dan has reported:

Quote:

So, who's in charge here--the virtual machine's BIOS, the virtual machines *partition tables* (where do those come from in the virtual machine anyway?), or did the partitioning tool create the partition tables, but the BIOS told it what to do?

I'm lost in all the *variables* that are undefined in all this!  Isn't there a *standard* that all BIOSs and partition tools are supposed to adhere to?

(Note:  this reminds me of the issue of the *laptop* that *uses* a different CHS and that's why it's necessary to have a new HDD be installed on the machine so it creates the correct CHS when attempting to transfer an image to the new HDD--if it's installed on an adaptor of some sort externally, it gets the wrong CHS created (I once again forgot where that thread is on the forum here--do you remember (again) where it is Brian?)

Way back when, I didn't think much about it--at the time I think I thought it had something to do with the HDD controller on the laptop--but, now I think it's relevant to this whole discussion!  Why/how does the BIOS control the *geometry* of the HDD on that brand of laptop--and why does it matter if on large HDDs, it's the LBA info that makes any difference?

Whooosh, whooosh, whooosh...........

@NightOwl: Thanks for your hint, please don't delete my doublepost    including edit coming here: 

 
xcurious wrote on Dec 2^nd, 2010 at 11:53am:




:   Thanks for much useful info in your posts.



Solution # 4 is quoted by me from my earlier post # 65  at the beginning of this post.

It has a correct Partinfo, and it's ok with C and a huge D filling the rest of the disk.
I like to have it correct if I can.

The partinfo you qouted from me in the beginning of your post # 68 is
an experiment done AFTERWARDS to show that deleting D in windows by letting Windows
Disk Management delete the huge D partition and create a (more useful perhaps) smaller
partition D to get room for a planned E partition. The partinfo then screws up a little.
I would believe that's windows fault.

But, as said, I stick with my C and huge D solution that has a correct partinfo as quoted
in the start of this post.

------------------------------------

After thinking and sleeping I can't get to any other conlusion that Ghost 2003 can't be at fault
here.

The correct partinfo from the start of this post with a 'normal' C and a 'huge' D was
created by starting a DISK FROM IMAGE operation in Windows-ghost 2003 interface.
That should be 'against all odds' from some conclusions in this thread.

But it comes out the right way. (as far as I can see).

It's first when Windows own disk-management comes into play (deleting D partition, creating a new and lesser D partition), we get the transformation from:

1: |0 | 1023 01 |7 | 1023 254 63 |

to

1: |0 | 1023 254 63 |7 | 1023 254 63 |

Can we really blame Ghost 2003 for this?


As a side-note, by googling I found statements like ' 1023 254 63 ' is a placeholder to indicate
out of CHS addressing  in both begin CHS and end CHS fields...

Different standards perhaps? Ghost follows the standard cited earlier in this thread,
but not Windows?

My first partinfo posted in this thread was not good, I am just concentrating
now on the 'transformation' above.



Edit to add: This thread is really starting to get confusing. (Understatement intended.)   

xcurious wrote on Dec 6^th, 2010 at 11:24am:

No standards, really, just conventions ... multiple conventions.  I'm not aware of any official industry standard.  Not that it would matter much anyway, since Microsoft is arrogant enough to do whatever they feel like, regardless of standards.  (A relevant case in point is the Vista/Win7 shift to megabyte-alignment instead of the age-old CHS alignment.  There may be some rationale behind it, but it's a unilateral change by Microsoft, not an official standard.)



(in reference to the VirtualPC experiment) ... NightOwl wrote on Dec 6^th, 2010 at 9:35am:

Yes, a virtual machine has a virtual BIOS, and the virtual BIOS "autodetects" the "geometry" of the virtual hard disk.  Just like a physical hard disk, a virtual hard disk has sectors, partitions, a MBR, and a partition table--all virtual.



NightOwl wrote on Dec 6^th, 2010 at 9:35am:

NightOwl, have you ever been on a subway or commuter train, and after you enter a car you walk all the way down the aisle, through the double-doors, and into the adjacent car, looking for a seat?  What you didn't notice is that this thread changed topics--IOW, we've moved to another rail car.  That whooshing is just that distracting noise as you go through the double-doors.   

The early part of this thread was about the numbers actually recorded in the partition table.  The latest posts are about the BIOS and geometry autodetection.  Those are two different topics.

Ideally, you'd want the BIOS and the partition table to agree, but whether that happens or not, the numbers in the partition table are static and don't change just because there's now a different autodetection or the hard disk is moved to another computer.  (What you were thinking of, BTW, is potential geometry mismatches when cloning IBM/Lenovo/HP/Compaq hard disks.)

What could be misleading you is Terabyte's terse response in Reply #67, which I fear readers might think implies the values in the partition table can morph depending on how the BIOS autodetects the geometry.  That's not true.  They are static and once written they remain fixed (at least until some utility is used to specifically change them).

Partition descriptors are written in the partition table when a partition is created.  I believe what Brian was describing in Reply #67 was creating partitions (and thus generating new partition descriptors) two different ways--both with BING, but one way with BING's [Alt CHS] option ticked and the other without.

IOW, the two PartInfo reports in Reply #67 are not different looks at the same partition table, they are different partition tables--one with partitions created one way, and one with partitions created the other way.

When any utility generates a partition table descriptor for a new partition, in theory it should use CHS values that match up with the CHS numbers it gets from the BIOS.  The vast majority of system BIOS's I come across report 1024 cylinders (range: 0-1023) and 63 sectors/track (range: 1-63).  IBM/Lenovo/HP/Compaq laptops report 240 heads or tracks (range: 0-239), while everybody else reports 255 heads (range: 0-254).

While I haven't seen any of these in a long time, some very old BIOS's assumed the last cylinder was a maintenance cylinder, so if the hard disk reported it had 1024 cylinders the BIOS assumed only 1023 of them (range: 0-1022) were usable.  (Old-timers might remember the days of MFM hard disks, when the last cylinder was where the heads were supposed to be parked when powering down.)