Two partition tables on one hard drive?

[Charles Weppler]

I'm totally baffled by the problems I'm having setting up a second
hard drive (120 GB Maxtor)on my HP Pavilion 8575C with Windows 98SE.
I'm trying to set up one primary partition (D, and two logical
partitions (E: and F, all about 40GB.

If I partition the drive using Partition Magic 8, it seems to be fine
in Windows, but MS-DOS (reboot to MS-DOS mode) says the E: and F:
partitions are invalid. If I wipe the disk, reboot to DOS, and use
fdisk to create the partitions, then format, DOS and Windows Safe Mode
are happy, but regular Windows says E: and F: are using MS-DOS
compatibility mode, and refuses to use them.

I then tried Maxtor Maxblast to wipe the disk and create new
partitions. Windows saw all three partitions OK, but Windows Safe
Mode and MS-DOS complained about E: and F: again.

I tried rebooting to MS-DOS mode and used fdisk again, without
clearing anything. Now MS-DOS says I have D:, E:, and F:, Windows says
I have D:, E:, F:, G:, and H: (with E: and F: invalid), Partition
Magic says I have D:, G:, and H:, and Partinfo says it's D:, E:, and
F:.

Where are all these tools getting different ideas about the partition
table, and why does none of them cross-check the (apparent) different
ways of finding out what the partition table contains? (Perhaps that's
just a philosophical question.) I ran a Norton Antivirus Pro 2004
system scan from the CD, ran Ad-Aware, Spybot search-and-destroy, and
PC-Pitstop's system check, with no serious problems found by any of
them.

Any suggestions which have a reasonable chance of working?

 

[Toshi1873]

I'm totally baffled by the problems I'm having setting up a second
hard drive (120 GB Maxtor)on my HP Pavilion 8575C with Windows 98SE.
I'm trying to set up one primary partition (D, and two logical
partitions (E: and F, all about 40GB.

If I partition the drive using Partition Magic 8, it seems to be fine
in Windows, but MS-DOS (reboot to MS-DOS mode) says the E: and F:
partitions are invalid. If I wipe the disk, reboot to DOS, and use
fdisk to create the partitions, then format, DOS and Windows Safe Mode
are happy, but regular Windows says E: and F: are using MS-DOS
compatibility mode, and refuses to use them.

(puts on stupid-hat)

Er, what's "booting to MS-DOS mode"?

Just kidding... I didn't expect that MS-DOS would even
be able to see a partition larger then 32GB. (Last time
I booted to MS-DOS was back when I was still running
WinNT 4.)

 

[Rod Speed]

(puts on stupid-hat)

Er, what's "booting to MS-DOS mode"?

Just kidding... I didn't expect that MS-DOS would
even be able to see a partition larger then 32GB.

Corse it can.

 

[Steve]

I'm totally baffled by the problems I'm having setting up a second
hard drive (120 GB Maxtor)on my HP Pavilion 8575C with Windows 98SE.
I'm trying to set up one primary partition (D, and two logical
partitions (E: and F, all about 40GB.

If I partition the drive using Partition Magic 8, it seems to be fine
in Windows, but MS-DOS (reboot to MS-DOS mode) says the E: and F:
partitions are invalid. If I wipe the disk, reboot to DOS, and use
fdisk to create the partitions, then format, DOS and Windows Safe Mode
are happy, but regular Windows says E: and F: are using MS-DOS
compatibility mode, and refuses to use them.

I then tried Maxtor Maxblast to wipe the disk and create new
partitions. Windows saw all three partitions OK, but Windows Safe
Mode and MS-DOS complained about E: and F: again.

I tried rebooting to MS-DOS mode and used fdisk again, without
clearing anything. Now MS-DOS says I have D:, E:, and F:, Windows says
I have D:, E:, F:, G:, and H: (with E: and F: invalid), Partition
Magic says I have D:, G:, and H:, and Partinfo says it's D:, E:, and
F:.

Where are all these tools getting different ideas about the partition
table, and why does none of them cross-check the (apparent) different
ways of finding out what the partition table contains? (Perhaps that's
just a philosophical question.) I ran a Norton Antivirus Pro 2004
system scan from the CD, ran Ad-Aware, Spybot search-and-destroy, and
PC-Pitstop's system check, with no serious problems found by any of
them.

Any suggestions which have a reasonable chance of working?

MS produced a revised version of FDISK.EXE for disks larger than 64GB
(and smaller than 137GB).

http://support.microsoft.com/default.aspx?scid=kb;en-us;263044

It's 64460 bytes, dated 18 May 2000. Are you using that under the
MS-DOS startup mode?

 

[Svend Olaf Mikkelsen]

Any suggestions which have a reasonable chance of working?

I did not read all details, but it sounds as the 32 GB problem. Which
is not a BIOS problem, but a Windows or Windows driver problem.

If you are using Via drivers from 1999, then update. Or look at

http://support.microsoft.com/default.aspx?scid=kb;en-us;243450

 

[Bob Willard]

I'm totally baffled by the problems I'm having setting up a second
hard drive (120 GB Maxtor)on my HP Pavilion 8575C with Windows 98SE.
I'm trying to set up one primary partition (D, and two logical
partitions (E: and F, all about 40GB.

If I partition the drive using Partition Magic 8, it seems to be fine
in Windows, but MS-DOS (reboot to MS-DOS mode) says the E: and F:
partitions are invalid. If I wipe the disk, reboot to DOS, and use
fdisk to create the partitions, then format, DOS and Windows Safe Mode
are happy, but regular Windows says E: and F: are using MS-DOS
compatibility mode, and refuses to use them.

I then tried Maxtor Maxblast to wipe the disk and create new
partitions. Windows saw all three partitions OK, but Windows Safe
Mode and MS-DOS complained about E: and F: again.

I tried rebooting to MS-DOS mode and used fdisk again, without
clearing anything. Now MS-DOS says I have D:, E:, and F:, Windows says
I have D:, E:, F:, G:, and H: (with E: and F: invalid), Partition
Magic says I have D:, G:, and H:, and Partinfo says it's D:, E:, and
F:.

Where are all these tools getting different ideas about the partition
table, and why does none of them cross-check the (apparent) different
ways of finding out what the partition table contains? (Perhaps that's
just a philosophical question.) I ran a Norton Antivirus Pro 2004
system scan from the CD, ran Ad-Aware, Spybot search-and-destroy, and
PC-Pitstop's system check, with no serious problems found by any of
them.

Any suggestions which have a reasonable chance of working?

Start by verifying that the BIOS sees the HD as the full 120GB.
If the BIOS gets it wrong, all else is hopeless. If the BIOS gets
it wrong, you may need a BIOS update, or you may have the HD's jumpers
set wrong.

 

[Eric Gisin]

Is the drive type set to AUTO in BIOS? Is the disk geometry C=15xzy H=255
S=63?

 

[Folkert Rienstra]

Is the drive type set to AUTO in BIOS? Is the disk geometry C=15xzy
H=255 S=63?

And what if it is?
It's only a completely ludicrous way of defining a capacity as it will not
have any other function.

 

[Folkert Rienstra]

Start by verifying that the BIOS sees the HD as the full 120GB.

That still doesn't mean it won't have a problem.

If the BIOS gets it wrong, all else is hopeless.

That totally depends on what it gets wrong.

If the BIOS gets it wrong, you may need a BIOS update,

or you may have the HD's jumpers set wrong.

A limited capacity obviously doesn't produce that above result.

 

[Eric Gisin]

And what if it is?
It's only a completely ludicrous way of defining a capacity as it will not
have any other function.

Idiot. I'm just asking if the BIOS is using the conventional geometry.

 

[Folkert Rienstra]

Idiot.

Actually, "Idiot" yourself.

1. That combination is invalid for P-CHS as well as L-CHS.
L-CHS is limited to 1024 cylinders and P-CHS is limited to 16 heads
2. Both are limited to 8 GB so any other use beyond that is for
"a completely ludicrous way of defining (describing) a capacity"

I'm just asking if the BIOS is using

the conventional geometry.

Whatever that is supposed to mean.

 

[Charles Weppler]

Yes.

It is 15881 Cylinders, 240 Heads, 63 Sectors/Track. It is using LBA.

1. That combination is invalid for P-CHS as well as L-CHS.
L-CHS is limited to 1024 cylinders and P-CHS is limited to 16 heads
2. Both are limited to 8 GB so any other use beyond that is for
"a completely ludicrous way of defining (describing) a capacity"



Whatever that is supposed to mean.

I did not read all details, but it sounds as the 32 GB problem. Which
is not a BIOS problem, but a Windows or Windows driver problem.

If you are using Via drivers from 1999, then update. Or look at

http://support.microsoft.com/default.aspx?scid=kb;en-us;243450

The behavior does not match that described in the article. When the
drive has been partitioned in Windows, ScanDisk only complains about
a few clusters on one partition. I do not know if it is using Via
drivers from 1999. How do I find out?

I should have mentioned before that my son has the same model computer
(purchased a month later), and he installed a second drive (Maxtor 60GB)
partitioned as a couple small partitions (about 7GB, to keep cluster
size down) followed by one large partition (over 40GB), and he has no
problems accessing it in Windows 98SE, Windows Safe Mode, or "reboot to
MS-DOS prompt". Unless HP made some change in that month, the BIOS and
drivers should be identical. He's actually been doing the work on this,
and telling me what to post. He's an Electrical Engineer.

 

[Svend Olaf Mikkelsen]

It is 15881 Cylinders, 240 Heads, 63 Sectors/Track. It is using LBA.




The behavior does not match that described in the article. When the
drive has been partitioned in Windows, ScanDisk only complains about
a few clusters on one partition. I do not know if it is using Via
drivers from 1999. How do I find out?

I should have mentioned before that my son has the same model computer
(purchased a month later), and he installed a second drive (Maxtor 60GB)
partitioned as a couple small partitions (about 7GB, to keep cluster
size down) followed by one large partition (over 40GB), and he has no
problems accessing it in Windows 98SE, Windows Safe Mode, or "reboot to
MS-DOS prompt". Unless HP made some change in that month, the BIOS and
drivers should be identical. He's actually been doing the work on this,
and telling me what to post. He's an Electrical Engineer.

It can be the partition table disk geometry that does not match the
BIOS setting. In that case delete all partitions assuming they do not
contain data, reboot and detect the disk i BIOS, and create new
partitions. The previous description however did not quite match that
problem.

If the 32 GB problem is present, the drivers from the Microsoft page
mentioned may solve the problem.

Changing the BIOS geometry to 255 heads (LBA) may solve it too, since
the Microsoft drivers may only apply the 32 GB problem for a 240 heads
setting.

You can examine if the 32 GB problem is present by using my GB32
program in a Windows 98 DOS box. In a very few cases, the same problem
has been seen in pure DOS.

Note that from the description the 32 GB problem can be present on
your sons computer too. It is only seen if data are more than 32 GB
into the disk, in which case it will be written 32 GB lower than it
should be.

If anything else fails, then do in both DOS and Windows:

findpart all fp.txt

and post the output here. Findpart is at my page.

If Via drivers are used, the copyright date can be seen in Control
Panel/System/Device Manger. The drivers are in
\windows\system\iosubsys

 

[Folkert Rienstra]

Nope, it will use LBAssist translation from CHS when addressed in CHS (Int13)
by older programs and the initial boot. The drive may be in CHS mode or in LBA
mode for that. LBA addressing (Int13 extensions) doesn't use CHS at all, obviously.

It can be the partition table disk geometry that does not match the BIOS setting.

How can it ever match the bios setting when "the partition table disk geometry"
is limited to 1023 255 63?

In that case delete all partitions assuming they do not contain data,
reboot and detect the disk in BIOS, and create new partitions.

The previous description however did not quite match that problem.

And what problem is that?

If the 32 GB problem is present, the drivers from the Microsoft page
mentioned may solve the problem.

Changing the BIOS geometry to 255 heads (LBA) may solve it too,

My bios doesn't even allow that. Only 'Normal' and 'Auto' do.

since the Microsoft drivers may only apply the 32 GB problem for a
240 heads setting.

So maybe you should verify that?

You can examine if the 32 GB problem is present by using my GB32
program in a Windows 98 DOS box. In a very few cases, the same
problem has been seen in pure DOS.

So, "Which is not a BIOS problem, but a Windows or Windows driver
problem" isn't quite right then, is it?

 

[Charles Weppler]

On 20 Apr 2004 12:57:16 -0700, (e-mail address removed) (Charles Weppler)
wrote:


It can be the partition table disk geometry that does not match the
BIOS setting. In that case delete all partitions assuming they do not
contain data, reboot and detect the disk i BIOS, and create new
partitions. The previous description however did not quite match that
problem.

If the 32 GB problem is present, the drivers from the Microsoft page
mentioned may solve the problem.

Changing the BIOS geometry to 255 heads (LBA) may solve it too, since
the Microsoft drivers may only apply the 32 GB problem for a 240 heads
setting.

You can examine if the 32 GB problem is present by using my GB32
program in a Windows 98 DOS box. In a very few cases, the same problem
has been seen in pure DOS.

Note that from the description the 32 GB problem can be present on
your sons computer too. It is only seen if data are more than 32 GB
into the disk, in which case it will be written 32 GB lower than it
should be.

If anything else fails, then do in both DOS and Windows:

findpart all fp.txt

and post the output here. Findpart is at my page.

If Via drivers are used, the copyright date can be seen in Control
Panel/System/Device Manger. The drivers are in
\windows\system\iosubsys

Thank you very much, Svend. Your GB32 program told both of us we
had the 32 GB problem in a Win98SE DOS window, and found no problem
in DOS prompt mode. I downloaded the zipped Via drivers, but none
of the files contained in the archives matched files on my system,
so it appears we're not using Via drivers. Therefore, rather than
trying to update those drivers, I downloaded the Microsoft update
you'd mentioned earlier. That took care of the problem, and GB32
now finds no problems. I wish Microsoft had been clearer about
the nature of the problem, since it impacts a lot more than scandisk.

Best regards,
Chuck

 

[Folkert Rienstra]

<snip>
1. That combination is invalid for P-CHS as well as L-CHS.
L-CHS is limited to 1024 cylinders and P-CHS is limited to 16 heads
2. Both are limited to 8 GB so any other use beyond that is for
"a completely ludicrous way of defining (describing) a capacity"

[snip]

It can be the partition table disk geometry that does not match the BIOS setting.

How can it ever match the bios setting when "the partition table disk geometry"
is limited to 1023 255 63?

In that case delete all partitions assuming they do not contain data,
reboot and detect the disk in BIOS, and create new partitions.

The previous description however did not quite match that problem.

And what problem is that?

If the 32 GB problem is present, the drivers from the Microsoft page
mentioned may solve the problem.

Changing the BIOS geometry to 255 heads (LBA) may solve it too,

My bios doesn't even allow that. Only 'Normal' and 'Auto' do.

since the Microsoft drivers may only apply the 32 GB problem for a
240 heads setting.

So maybe you should verify that?

You can examine if the 32 GB problem is present by using my GB32
program in a Windows 98 DOS box. In a very few cases, the same
problem has been seen in pure DOS.

So, "Which is not a BIOS problem, but a Windows or Windows driver
problem" isn't quite right then, is it?

[snip]

I had hoped that something (positive) could be learned here.
Guess not then.

 

[Svend Olaf Mikkelsen]

How can it ever match the bios setting when "the partition table disk geometry"
is limited to 1023 255 63?

It matches when end head in partition tables is one lower than the
number of heads reported by interrupt 13h, function 8h when no
partitions are present, and the end sector is the same as the number
of sectors per track according to the same interrupt.

And what problem is that?

That is previously discussed. The BIOS may not read and write the
addresses expected, when the partition tables do not match the
geometry.

My bios doesn't even allow that. Only 'Normal' and 'Auto' do.

So maybe you should verify that?

Too time consuming. Also I may not have the hardware needed.

So, "Which is not a BIOS problem, but a Windows or Windows driver
problem" isn't quite right then, is it?

Well, I did hear about 1 case in DOS.

 

[Svend Olaf Mikkelsen]

Thank you very much, Svend. Your GB32 program told both of us we
had the 32 GB problem in a Win98SE DOS window, and found no problem
in DOS prompt mode. I downloaded the zipped Via drivers, but none
of the files contained in the archives matched files on my system,
so it appears we're not using Via drivers. Therefore, rather than
trying to update those drivers, I downloaded the Microsoft update
you'd mentioned earlier. That took care of the problem, and GB32
now finds no problems. I wish Microsoft had been clearer about
the nature of the problem, since it impacts a lot more than scandisk.

Best regards,
Chuck

Nice that the problem was solved.

Well, yes, I tend to not comment on Microsoft behavior in partition
relates issues, since English is not my native language.

 

[Folkert Rienstra]

It matches when end head in partition tables is one lower than
the number of heads reported by interrupt 13h, function 8h

Int 13/AH=08h doesn't report the number of heads.

And what does that have to do with "the BIOS setting"?

when no partitions are present,

But they are. And obviously there is no problem as described when
there aren't any partitions.

and the end sector is the same as the number of sectors per track
according to the same interrupt.

But then it would describe a harddrive of less than 8GB (7.5 GB).
Also CHS and LBA values wouldn't match unless it described
a harddrive of less than 8GB which is obviously not desired.

That is previously discussed.

Duh. So remind me.

The BIOS may not read and write the addresses expected, when
the partition tables do not match the geometry.

As I said, the partition tables cannot ever match the geometry so
your point is moot. And didn't you say it wasn't a bios problem?

Well?


Too time consuming. Also I may not have the hardware needed.

Then you'd better refrain from making that type of mindless smalltalk.

Well, I did hear about 1 case in DOS.

Right, so it may be a bios problem too.

 

[Svend Olaf Mikkelsen]

Int 13/AH=08h doesn't report the number of heads.

It does, although one have to interpret the register contents.

And what does that have to do with "the BIOS setting"?

The interrupt reply will vary depending on BIOS settings.

when no partitions are present,

But they are. And obviously there is no problem as described when
there aren't any partitions.

No, but one have to know the clean interrupt 13h reporting to be able
to see if there is a partition table match.

Then copy the MBR to a file on floppy, zero the MBR, reboot, make the
BIOS setting again, run interrupt 13h, write down the numbers on a
piece of paper. Then write back the MBR. How difficult can it be?

But then it would describe a harddrive of less than 8GB (7.5 GB).
Also CHS and LBA values wouldn't match unless it described
a harddrive of less than 8GB which is obviously not desired.

Does not apply.

Duh. So remind me.

Well?

Set it so interrupt 13h function 8h returns 255 heads when no
partitions are present.

Then you'd better refrain from making that type of mindless smalltalk.

There is reason enough for a "may".

Right, so it may be a bios problem too.

Yes.

I would like to explain my interpretation of these matters, but it
seems as our basic understanding of disk geometry is so different,
that it may not be possible.