Partition Table Problems "Number of sectors in partition is inconsistent."

[Grey Hodge]

I resized a partition with Partition Magic 8 a while ago, and have
spent 5 days recovering from it. First time PM ever gave me problems.
I used to have a Primary, and an Extended with three Logical
partitions in it. All about the same size on my 80GB drive. But PM
completely borked the partition table. I managed to recover almost all
the data, and stick it in the first primary partition. My OS was
WinXP, but I'm running on Win98 installed to a second older 4GB drive
while I try to recover my big drive. Currently, I can resize it with
other utilities, access the data, and utilities seem to say the
partition is in good health, but Partition Magic's PARTINFO utility
(when run under DOS) says this (slightly edited for readability):

============================================================================
Disk 1: 158812 Cylinders, 16 Heads, 63 Sectors/Track.
BiosExtensions: 0x2100 Subsets (0x00000005): Access EDD
The BIOS supports INT 13h extensions for this drive.
============================ Partition Tables
==============================
Partition -----Begin---- ------End----- Start
Num
Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect
Sects
---------- - ---- ---- ---- ---- -- ---- ---- ---- ----------
----------
* 0 0 80 [ 0 1 1] 0C [1023 15 63] 63
76822641
** 0 1 1 10676 15 63

* = Large Drive Placeholders
** = Actual Values

Error #110: Number of sectors in partition is inconsistent.
ucSectors = 76822641
end - begin = 10762353

================================================================================
Disk 1: 78165.3 Megabytes
============================= Partition Information
============================
Volume Partition Partition Start
Total
Letter:Label Type Status Size MB Sector # Sector
Sectors
------------- --------------- -------- -------- ---------- -
---------- --------
D:NO NAME FAT32X Pri,Boot 37511.1 0 0
63 76822641
Unallocated 40654.2 None -
76822704 83259792


Now, I'm not sure how to fix this. I've had a lot of experience over
the years doing lots of different types of repair, but this one stumps
me. I've tried creating a second partition and duplicating the data
there, but those partitions wind up suffereing from the same partition
table errors, since this first one is messed up, so that doesn't fix
anything. Sadly, I don't have a current backup, so that's my own
fault, or I'd just wipe it all.

Now, the tools I have available to me, aside from standard DOS and
Windows 98SE built-in crap, and the WinXP recovery console, is
Knoppix 3.7 (which has QTPartEd which helped me resize the first part
to store recovered data), OnTrack's Easy Recovery Pro 6.0, Ranish
Partition Manager, CG Security's invaluable TestDisk tool, Norton
Utilities 2002 through 2005 (and even the older DiskEdit utility from
2k2), Partition Magic 7 and 8.

Can someone give me some pointers here? If I have to edit values
manually, that's fine, as long as I know what to edit and to what. The
data up there (ucSectors = 76822641, end - begin = 10762353) isn't
clear to me exactly what it's trying to tell me.

 

[Robert Green]

I resized a partition with Partition Magic 8 a while ago, and have
spent 5 days recovering from it. First time PM ever gave me problems.
I used to have a Primary, and an Extended with three Logical
partitions in it. All about the same size on my 80GB drive. But PM
completely borked the partition table. I managed to recover almost all
the data, and stick it in the first primary partition. My OS was
WinXP, but I'm running on Win98 installed to a second older 4GB drive
while I try to recover my big drive. Currently, I can resize it with
other utilities, access the data, and utilities seem to say the
partition is in good health, but Partition Magic's PARTINFO utility
(when run under DOS) says this (slightly edited for readability):

============================================================================
Disk 1: 158812 Cylinders, 16 Heads, 63 Sectors/Track.
BiosExtensions: 0x2100 Subsets (0x00000005): Access EDD
The BIOS supports INT 13h extensions for this drive.
============================ Partition Tables
==============================
Partition -----Begin---- ------End----- Start
Num
Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect
Sects
---------- - ---- ---- ---- ---- -- ---- ---- ---- ----------
----------
* 0 0 80 [ 0 1 1] 0C [1023 15 63] 63
76822641
** 0 1 1 10676 15 63

* = Large Drive Placeholders
** = Actual Values

Looks like a bug in PARTINFO, causing it to miscalculate the actual
end CHS value, which should be 76212 16 63.

The program is using a WORD variable to hold the cylinder count,
when it needs to be using a DWORD.

If you were using LBA translation (255 heads instead of 16) PARTINFO
would have worked correctly.

Error #110: Number of sectors in partition is inconsistent.
ucSectors = 76822641
end - begin = 10762353

================================================================================
Disk 1: 78165.3 Megabytes
============================= Partition Information
============================
Volume Partition Partition Start
Total
Letter:Label Type Status Size MB Sector # Sector
Sectors
------------- --------------- -------- -------- ---------- -
---------- --------
D:NO NAME FAT32X Pri,Boot 37511.1 0 0
63 76822641
Unallocated 40654.2 None -
76822704 83259792


Now, I'm not sure how to fix this. I've had a lot of experience over
the years doing lots of different types of repair, but this one stumps
me. I've tried creating a second partition and duplicating the data
there, but those partitions wind up suffereing from the same partition
table errors, since this first one is messed up, so that doesn't fix
anything. Sadly, I don't have a current backup, so that's my own
fault, or I'd just wipe it all.

There is really nothing to fix here.

Now, the tools I have available to me, aside from standard DOS and
Windows 98SE built-in crap, and the WinXP recovery console, is
Knoppix 3.7 (which has QTPartEd which helped me resize the first part
to store recovered data), OnTrack's Easy Recovery Pro 6.0, Ranish
Partition Manager, CG Security's invaluable TestDisk tool, Norton
Utilities 2002 through 2005 (and even the older DiskEdit utility from
2k2), Partition Magic 7 and 8.

Can someone give me some pointers here? If I have to edit values
manually, that's fine, as long as I know what to edit and to what. The
data up there (ucSectors = 76822641, end - begin = 10762353) isn't
clear to me exactly what it's trying to tell me.

Well, ucSectors would be the total sectors in the partition according
to the boot sector BPB.

end - begin would be the LBA of the last sector in the partition minus
the LBA of the inititial sector of the partition. But PARTINFO
miscalculates the value of the last sector for the reason mentioned
above.

Bob

 

[Grey Hodge]

Looks like a bug in PARTINFO, causing it to miscalculate the actual
end CHS value, which should be 76212 16 63.
The program is using a WORD variable to hold the cylinder count,
when it needs to be using a DWORD.
If you were using LBA translation (255 heads instead of 16) PARTINFO
would have worked correctly.

I think I have discovered the problem. The fact you brought up it's a
bug got me thinking. Especially the word/dword bit. So I installed the
full Win9x version of Partition MAgic 7 and 8. Both PM 7 and 8 in
Windows (aka, the 32bit programs), AND the Win32 versions of PartInfo
show the partition has NO ERRORS. This fits with why nothing else I
was running, such as Linux utilities or ones with DOS extenders were
showing problems. I think you're right, it's the DOS versions barfing
on the data. So, thanks a bunch.

There is really nothing to fix here.

I agree now, thanks for assauging my fears.

Grey Hodge

 

[Folkert Rienstra]

I resized a partition with Partition Magic 8 a while ago, and have
spent 5 days recovering from it. First time PM ever gave me problems.
I used to have a Primary, and an Extended with three Logical
partitions in it. All about the same size on my 80GB drive. But PM
completely borked the partition table. I managed to recover almost all
the data, and stick it in the first primary partition. My OS was
WinXP, but I'm running on Win98 installed to a second older 4GB drive
while I try to recover my big drive. Currently, I can resize it with
other utilities, access the data, and utilities seem to say the
partition is in good health, but Partition Magic's PARTINFO utility
(when run under DOS) says this (slightly edited for readability):

============================================================================
Disk 1: 158812 Cylinders, 16 Heads, 63 Sectors/Track.
BiosExtensions: 0x2100 Subsets (0x00000005): Access EDD
The BIOS supports INT 13h extensions for this drive.
============================ Partition Tables ==============================
Partition -----Begin---- ------End----- Start Num
Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect Sects
---------- - ---- ---- ---- ---- -- ---- ---- ---- ---------- ----------
* 0 0 80 [ 0 1 1] 0C [1023 15 63] 63 76822641
** 0 1 1 10676 15 63

* = Large Drive Placeholders
** = Actual Values

Looks like a bug in PARTINFO, causing it to miscalculate the actual
end CHS value, which should be 76212 16 63.

So what, the value is cosmetic only.
What it is trying to say is that LBA and CHS don't match.
Ofcourse, for drives over 8GB (and partitions over 8GB)
they'll *never* match.

The program is using a WORD variable to hold the cylinder count,
when it needs to be using a DWORD.

If you were using LBA translation

Compared to what? Normal?

(255 heads instead of 16)

Please explain.

PARTINFO would have worked correctly.


There is really nothing to fix here.


Well, ucSectors would be

Would be or *is* ?

 

[Robert Green]

On 8 Feb 2005 15:35:37 -0800, (e-mail address removed) (Grey Hodge) wrote:

============================================================================
Disk 1: 158812 Cylinders, 16 Heads, 63 Sectors/Track.
BiosExtensions: 0x2100 Subsets (0x00000005): Access EDD
The BIOS supports INT 13h extensions for this drive.
============================ Partition Tables ==============================
Partition -----Begin---- ------End----- Start Num
Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect Sects
---------- - ---- ---- ---- ---- -- ---- ---- ---- ---------- ----------
* 0 0 80 [ 0 1 1] 0C [1023 15 63] 63 76822641
** 0 1 1 10676 15 63

* = Large Drive Placeholders
** = Actual Values

Looks like a bug in PARTINFO, causing it to miscalculate the actual
end CHS value, which should be 76212 16 63.

So what, the value is cosmetic only.

Not in this case, since PARTINFO uses the actual cylinder value in the
calculation that leads it to report a non-existent error. And an
exlanation of the error report is what this thread is about.

What it is trying to say is that LBA and CHS don't match.
Ofcourse, for drives over 8GB (and partitions over 8GB)
they'll *never* match.

No, its trying to say exactly what it says.

It uses the "actual" and "placeholder" designations to indicate the
8GB threshold effect, which is not relevant to this discussion.

Compared to what? Normal?


Please explain.

With 255 heads the cylinder count will be small enough to fit in a
WORD, and the error would not occur.

The question is how does PARTINFO get the value 10762353? First, it
converts the end CHS to an LBA, then subtracts the partition start
LBA.

(10677 * 16 * 63) - 63 = 10762353

Using the correct end cylinder value you get:

(76213 * 16 * 63) - 63 = 76822641

No inconsietency.

How do I know that PARTINFO does this? I actually don't. It just that
there is no other way to get that particular value from the data in
this PARTINFO report.

Where did the 10676 mistake come from in the first place? It could
only come from doing a CHS to LBA conversion on the ucSectors value
and storing the result in a WORD.

Would be or *is* ?

*Seems likely*?

Bob

 

[Folkert Rienstra]

On 8 Feb 2005 15:35:37 -0800, (e-mail address removed) (Grey Hodge) wrote:
============================================================================
Disk 1: 158812 Cylinders, 16 Heads, 63 Sectors/Track.
BiosExtensions: 0x2100 Subsets (0x00000005): Access EDD
The BIOS supports INT 13h extensions for this drive.
============================ Partition Tables ==============================
Partition -----Begin---- ------End----- Start Num
Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect Sects
---------- - ---- ---- ---- ---- -- ---- ---- ---- ---------- ----------
* 0 0 80 [ 0 1 1] 0C [1023 15 63] 63 76822641
** 0 1 1 10676 15 63

* = Large Drive Placeholders
** = Actual Values

Looks like a bug in PARTINFO, causing it to miscalculate the actual
end CHS value, which should be 76212 16 63.

So what, the value is cosmetic only.

Not in this case, since PARTINFO uses the actual cylinder value
in the calculation that leads it to report a non-existent error.

Right. It is still cosmetic. 76212 16 63 is a non existent value
calculated from LBA and is displayed only for cosmetic reasons.
It can't be used to check anything as they are both the same value.

The error is that 1023 15 63 isn't really a large drive placeholder
(except maybe for Normal, which isn't exactly "Large").

The OS will ignore it although someOSes apparently may exhibit the
modulo 32GB problem if the large drive placeholders are off (read:
not really large drive place holders).

And an explanation of the error report is what this thread is about.

But the eror is still cosmetic. If it recognizes the values as large
drive place holders then it should not do the checking at all.

Right.
It says they are large drive place holders but then acts as if it weren't.
Next it does mess it up even further.

No, its trying to say exactly what it says.

No, it is inconsistent. It either acts as if it were a drive over 8GB
(ie a Large Drive) and not check or it doesn't.

It uses the "actual" and "placeholder" designations to indicate the
8GB threshold effect, which is not relevant to this discussion.

But that is exactly what is relevant.

Well?


With 255 heads the cylinder count will be small enough to fit in a
WORD, and the error would not occur.

There is no cylinder count other than in that program and that has nothing
whatsoever to do with bios translation. It is a cosmetic value used to vis-
ually check whether a partition starts at an (imaginary) cylinder boundary.

The question is how does PARTINFO get the value 10762353? First, it
converts the end CHS to an LBA, then subtracts the partition start LBA.

Right, but it shouldn't have in the case of Large Drive Place Holders.

(10677 * 16 * 63) - 63 = 10762353

Using the correct end cylinder value you get:

(76213 * 16 * 63) - 63 = 76822641

No inconsietency.

Of course not, since that 76213 was derived from
(63+76822641)/16/63 = 76213 in the first place.

How do I know that PARTINFO does this? I actually don't.
It just that there is no other way to get that particular value from
the data in this PARTINFO report.

Where did the 10676 mistake come from in the first place? It could
only come from doing a CHS to LBA conversion on the ucSectors value
and storing the result in a WORD.

Yup, looks like it. 129B4h=76212, 29B4h= 10676

*Seems likely*?

You're just guessing then.

Well, since end - begin obviously is *not* from the LBA recorded
values it might just be the LBA recorded values, don't you think?

Obviously not.

Right, because it is recalculating the CHS based on H*S and then flunks it.

 

[Grey Hodge]

I found and fixed the problems, and in the process, learned a lot more
about geometry translation and partition tables than I ever knew
before (which wasn't a small amount, or so I thought). Turns out there
WAS an issue with the partition tables, I just wasn't understanding
geometry translation differences enough to see it.

First, I shrank the last logical partition on my 80GB drive, and the
end of the extended partition containing it so I'd have some space at
the end to play with Knoppix (swap space). Partition Magic 8 did this
fine. It turns out PartEd was my problem causer. Due to how I managed
my upgrade a year ago from a 30GB primary disk to this 80B primary
disk, was that the large extended partition was created first, that
data copied over, then _outside_ of Windows, the primary partition was
created and copied (so XP wouldn't bitch about being moved), so the
partition table was "out of order". The EXT was in slot 1, the PRI was
in slot 2. This didn't cause any issues to anything, ever. But when I
created a swap partition at the end, PartEd decided to rewrite the
partition table, and didn't do it right. It recorded the disk data in
terms of 158,811 cylinders and 15 heads, when the BIOS (and DOS and
Windows based Partition Magics, also) looked at it as a disk of 9,964
cylinders with 255 heads. Thus, when the system rebooted, the BIOS
couldn't find the boot sector with the information given.

Now, DOS and Windows and Linux all could read the disk fine, which is
how I was able to save the data, but booting was impossible. Had I
realized this earlier, I could have saved the effort of data
copying/moving etc.

I fixed this boot problem by moving all my data (backed up into a
ghost image) into a partition at the end of the disk, and carefully
recorded it's starting and ending locations in absolute sectors. Then
I wiped sectors 0-63 to erase all partition data and MBRs and backups.
I booted from my XP CD (splistreamed with SP2 a while ago, handy to
have) and used it's recovery console to DISKPART a 30GB partition at
the front of the disk, and formatted it with FAT32, and installed XP
to it.

When that worked, I rebooted into DOS (via a Win98 install on a second
small 4GB disk I had laying around), and used Ranish Partition Manager
to translate the absolute sector values of my backed up data into
terms of 9,964/255/63 CHS values. Now, strictly speaking, these new
values were "invalid" because the backup partition no longer began on
cylinder/head boundaries (0 or 255), but in the middle, 5120/81/1 CHS.
But, that's ok because I just needed to now copy my 28GB of backup
data from that partition to my new primary, correct partition. I did
this, and deleted the old partition, and then I fixed up the
partitions on my disk in Win98 with PM8 as needed, and reconfirmed
WinXP still booted from the disk. Now everything is fine again.

Lesson learned: Always check CHS values of your large disks before
repartitioning, and maybe even keep backups.

 

[Folkert Rienstra]

I found and fixed the problems, and in the process, learned a lot more
about geometry translation and partition tables than I ever knew
before (which wasn't a small amount, or so I thought).

Turns out there WAS an issue with the partition tables, I just wasn't
understanding geometry translation differences enough to see it.

And I think that you still don't.

As long as the number of sectors (S) is 63 (or the same as it was at
initialization time) there isn't a problem for the first partition as
long as it is at the start of the disk.
If it is not at the start of the disk the CHS geometry has to conform to
the LBA start of the partition, for the bootcode to be able to 'reach' to
the partition bootsector. If the distance is larger than 8GB the bootcode
must be able to switch to LBA addressing in order to 'reach' the bootsector.
With 256 heads 'geometry' the CHS 'reachable' distance is (only) 8GB.
With 16 heads 'geometry' the CHS 'reachable' distance is only ~500MB.
So if your primary partition was some 40GB behind your extended it must
have used LBA addressing already.

First, I shrank the last logical partition on my 80GB drive, and the
end of the extended partition containing it so I'd have some space at
the end to play with Knoppix (swap space). Partition Magic 8 did this
fine. It turns out PartEd was my problem causer. Due to how I managed
my upgrade a year ago from a 30GB primary disk to this 80GB primary
disk, was that the large extended partition was created first, that
data copied over, then _outside_ of Windows, the primary partition was
created and copied (so XP wouldn't bitch about being moved), so the
partition table was "out of order".

The EXT was in slot 1, the PRI was in slot 2.

More important is where they physically start on the diskdrive,
not which slot they are in.

This didn't cause any issues to anything, ever. But when I created
a swap partition at the end, PartEd decided to rewrite the partition
table, and didn't do it right.

Yup, it should have written (kept) Large Drive Place Holders where
necessary.

It recorded the disk data in terms of 158,811 cylinders

Nope, noway.
The CHS values in the partition tables can only be 1023/
255(-1)/63 max. due to the number of bits assigned to each
(and the (-1) rule that others may be better able to explain).

and 15 heads,

Right, in terms of 16 heads (0-15) and 63 sectors per track/cylinder.

when the BIOS (and DOS and Windows based Partition Magics,
also) looked at it as a disk of 9,964 cylinders with 255 heads.

Nope, just ignoring them and using the LBA values.

Thus, when the system rebooted, the BIOS couldn't
find the boot sector with the information given.

The bootcode in the MBR, not the BIOS.

Now, DOS and Windows and Linux all could read the disk fine, which is
how I was able to save the data, but booting was impossible.

Had I realized this earlier, I could have saved the effort of data
copying/moving etc.

Actually, just editing the CHS values to Large Drive Place Holder would
have likely fixed it already.

I fixed this boot problem by moving all my data (backed up into a
ghost image) into a partition at the end of the disk, and carefully
recorded it's starting and ending locations in absolute sectors. Then I
wiped sectors 0-63 to erase all partition data and MBRs and backups.
I booted from my XP CD (splistreamed with SP2 a while ago, handy to
have) and used it's recovery console to DISKPART a 30GB partition at
the front of the disk, and formatted it with FAT32, and installed XP to
it.

When that worked, I rebooted into DOS (via a Win98 install on a second
small 4GB disk I had laying around), and used Ranish Partition Manager
to translate the absolute sector values of my backed up data into terms
of 9,964/255/63 CHS values.

Now, strictly speaking, these new values were "invalid"

Only for non-LBA type partitions.

because the backup partition no longer began on cylinder/head
boundaries (0 or > 255), but in the middle, 5120/81/1 CHS.

As you have noticed OSes don't care when these are LBA-type partitions.

But, that's ok because I just needed to now copy my 28GB of backup
data from that partition to my new primary, correct partition.
I did this, and deleted the old partition,
and then I fixed up the partitions on my disk in Win98 with PM8

as needed,

Says who.

and reconfirmed WinXP still booted from the disk. Now everything is
fine again.

Lesson learned:

Always check CHS values of your large disks before repartitioning,

Given the number of utes that doesn't understand CHS and screw-
up when something isn't as they expect it, not such a bad idea.
And even check after first partitioning as some OSes too have a nasty
habit of inducing a bug when the values are not large drive place holders,
even when they don't actually use CHS mode (Modulo 32GB bug).

and maybe even keep backups.

True for booting as some bootcode uses Int13. The rest doesn't care.

 

[wemaole]

I suggest you use partition table doctor.It provides very useful
functions: Backup partition table, Restore partition table, Rebuild
partition table, undelete partition,Fixboot.
see more:http://www.ptdd.com

 

[Joep]

I suggest you use partition table doctor.It provides very useful
functions: Backup partition table, Restore partition table, Rebuild
partition table, undelete partition,Fixboot.
see more:http://www.ptdd.com

I suggest you get lost ...