Sign in with
Sign up | Sign in
Your question

FAT32 partition not visible in DOS

Last response: in Storage
Share
February 8, 2011 11:41:03 PM

Hi, I have a bootable dos(win98 4.10.2222) primary partition on disk 0, a bunch of NTFS logical partitions and 2 - 18gb fat 32 logical partitions to receive images from Ghost. One f32 partition is on the end of disk 0(250gb) and the other is on the end of disk 1(500gb). First one is fine but I want Ghost to send the image to the second drive. The second f32 partition one is not visible in dos. Any suggestions?

I thought this posted 5 min ago but dont see the post, if I sent it in twice my bad.

More about : fat32 partition visible dos

a c 362 G Storage
February 11, 2011 12:42:51 AM

You will not be able to see these partitions with an old DOS, and not because they are FAT32 or anything like that. No older DOS, and no Windows before SP1 of Win XP, knew how to deal with a HDD over 128 GB. In fact, some older DOS's had troubles over 8 or 20 GB. So, even if the DOS can read the Partition Table on the HDD, it still cannot figure out how to access any Partition above 128 GB. That is, of course, if you are really using an older DOS like 6.22 or something, or the DOS built into Win 98. (I'm assuming that, by "DOS", you do not mean merely the Command Prompt Window available in, say, Win XP.)

You probably also have a second problem. You say some of these images are in Logical Partitions. Those types of partitions actually are files in a special type of "master partition", and I would bet that one is set up with an NTFS-style File System. No DOS knows how to use that, so it could not read the special Partition and find its Logical Partition contents.
m
0
l
February 11, 2011 1:46:34 AM

Thanks for your input.
Not that I am any sort of expert but the DOS version installed on my bootable c: partition from my Win98 CD is DOS 7? It is successful already in seeing the 18GB logical FAT32 partition at the end of my 250GB Disk-0 so the 137GB limit is a non-issue no?

But the 500 GB Drive-1 for instance when looked at with FDisk after booting to c: is declared unallocated. I use that drive all the time in XP. It is 100% extended with 2 large NTFS backup partitions then another FAT32 partition at the end.

PARTINFO has been looked at with no issues spotted so far. Mother board forum (MSI) has not stated BIOS has a size limit in the 500GB range....

My only suggested course of action is to try repartitioning, delete logical at end, shrink extended to only contain the 2 NTFS parts and create a FAT32 primary in place of the ex-logical FAT32 at the end of the drive. This plan is a work around to avoid having to move the backup data already in the NTFS areas.
m
0
l
Related resources
a c 362 G Storage
February 11, 2011 6:48:22 PM

I am surprised that your DOS with Win 98 can work at the end of a 250 GB HDD, but apparently it does. So I agree that it also should be able to see the end of the 500 GB HDD - there is no "boundary" I know of between 250 and 500 GB. So I follow your argument that the problem may be in the fact that the invisible Partition is Logical, and hence agree with your proposed plan. Let us know how it works.
m
0
l
February 12, 2011 10:16:22 PM

By bypassing my old BIOSs limited HD ability and using a 'direct' read setting in Terabyte's BootIt Bare Metal beta I was able to see the drive for the first time without XP. Luckily, Terabyte has a whole suite of utilities for working with large HDs and I am able to replace Ghost, DOS and Partition Magic all in one shot. That is, once they release v1.0. For now their IFD utility has helped me with backing up my OS partition.
m
0
l
a c 362 G Storage
February 13, 2011 7:36:14 PM

Just want to clarify the "128 GB limit on HDD size", because I'm guessing the limit you are experiencing is in the OS (Win 98) and not in the BIOS.

At the beginning of PC development, disk access used an addressing system that employed three absolute addresses - Cylinder, Head and Sector - to locate data. By the early '90s a disk accessing system called LBA for Logical Block Addressing replaced it so that "large" HDD's over 500 MB could be used. The LBA address was a single digital number of 28 binary bits that was a simple sequential block number. A processor board on the HDD unit itself combined that with its own knowledge of the HDD's physical layout and translated it into the internal CHS-style co-ordinates necessary to locate the data. Now, all along the common way to arrange the data was in Sectors of 512 bytes. By the late '90's HDD sizes were rising so rapidly it was recognized that they were about to run into another limit. 28 bits means you can generate 2^28 sequential addresses, each holding 512 bytes. That works out to 268,435,456 locations, or 137,438,953,472 bytes. So you can only have a HDD with up to 134,438.... bytes. Or, if you define "GB" to be 1024 x 1024 x 1024 bytes, that is 128 of those "GB".

The solution implemented beginning late in the '90's was to switch the original LBA system to a 48-bit binary address, rather than 28 bits. Still sticking with 512 bytes per sector, this allows addressing 281,474,976,710,656 sectors or 134,217,728 GB! It will be a while until we get HDD's that bit, if ever. (Much more recently, a "sector" is being redefined to be 4096 bytes, 8 times as big as before, so that makes the "limit" even larger.)

To make this work THREE places have to include "48-bit LBA Support". One is in the HDD's on-board controller board, and obviously any HDD maker will include that in any HDD over 128 GB. The second is in the computer mobo's HDD controller which must be able to send a full 48 bits of address number to the HDD, and remember that the HDD controller these days most commonly is actually in the chips on the mobo, and it in turn is controlled by the mobo's BIOS chip. Thus we end up with the concept that the BIOS is key to using "large" HDDs - but it's only one of three keys. To carry this part further, SATA systems were introduced AFTER the 48-bit LBA system was introduced, so ALL SATA systems (drives and controllers) include 48-bit LBA Support. However, not all older IDE systems do. In fact, there were some mobos in the late '90's and even into the early 2000's with either no SATA ports and no 48-bit LBA on their IDE ports, or SATA that supported the new system plus IDE ports that did NOT. Many of those systems could have this problem solved by downloading from the mobo maker an updated BIOS that added 48-bit LBA Support to the IDE port controller portion, and "burning" that into the BIOS chip.

The third place that MUST include 48-bit LBA Support is the Operating System. When it sends info to the controller, and thence to the HDD, about where it wants data from or where to write it, it must be able to generate a full 48-bit binary address. Windows up to the original release of XP did NOT have this. It was added to XP in Service Pack 1, and added to a few earlier Windows versions with other Service Packs. To my knowledge it never was added to Win 98.

So, in your case I expect that Win 98 OS you use cannot access HDD's over 128 GB. But another utility that bypasses Windows' access to the controller and works directly may do it just fine, but ONLY if your mobo's controller chips and BIOS have 48-bit LBA Support. You have not said whether the HDD's you talk about are IDE or SATA. If they are SATA, there is no doubt that feature is there. If they are IDE, the fact that you seem to be successful in using them under Win XP and even under an older DOS with a special utility says VERY likely your hardware has this feature. The limit you are working with is the OS itself.
m
0
l
February 13, 2011 8:09:32 PM

I am glad I found a replacement for DOS 7 to get what I need done for now but really, I have learned so much in this inquiry that I will be redesigning my whole layout and exploring options like freeDOS and Linux in the future. For now time to tidy things up and get ready to continue the learning. Sorry for the lack of details provided initially. By the time your response came through here I was highly involved with a couple other forums. If you want to see some of the in depth stuff that went on this thread was very thorough.

http://radified.com/cgi-bin/yabb2/YaBB.pl?num=129723022...

Thank you for your input.
m
0
l
!