Ghost 2003 cant see FAT32 partitions?

[Wayne]

IN SOME CASES, Ghost 2003 doesnt see any FAT32 parition (as a
destination for an image file). It seems to depend on the computer. I
have an Asus AV8 motherboard, and Ghost sees NTFS fine, but doesnt see
its FAT32 partitions. I also have an Asus AV7 motherboard, and Ghost
does see its FAT32 fine. A friend has two computers on which Ghost 2003
doesnt see any FAT32 partitions. Internal or USB external, doesnt
matter. Presence of some NTFS, or entirely FAT32 systems, doesnt seem
to matter.

That seems really bizarre. What could cause it? How common is it?

If I boot on the Ghost 2003 CD on this AV8 system, then the IBM Dos boot
system at A: can see all FAT32 partitions fine, and doesnt see NTFS
partitions (as expected from Dos). But then start Ghost from that CD,
and it is the opposite, NTFS is seen, FAT32 is not. But Ghost on my AV7
sees both fine, as expected from Ghost 2003.

Again, problem is referring to selectable Destinations for image files.
As a Source, the FAT32 partition is seen by number, however Ghost shows
its volume label as NO NAME, when it fact has another name seen in XP.

Both disks were fully created by the XP Install disk.

 

[Folkert Rienstra]

Probably ghost being 'holier than the pope' regarding partition table rules
(or percepted partition table rules) or bios settings being different than
recorded in the MBR. Or showing error behaviour triggered by that.

You can use Findpart or Partinfo to see if they find any peculiarities with
the partitions.

 

[Wayne]

Probably ghost being 'holier than the pope' regarding partition table rules
(or percepted partition table rules) or bios settings being different than
recorded in the MBR. Or showing error behaviour triggered by that.

You can use Findpart or Partinfo to see if they find any peculiarities with
the partitions.

Thanks. I obtained FindPart and ran it. The Windows version seemed to hang
on me, wouldnt continue, but the Dos version ran OK under the same Dos boot
that runs Ghost.

Ghost 2003 sees my disk (as source partitions) as:

1 type 7 NTFS 24999MB which is my C:
2 type 7 NTFS 24999MB D:
3 type b FAT32 20002MB E:
4 type 7 NTFS 20002MB F:
5 type 7 NTFS 62620MB G:
- free 2MB

But it will not show the FAT32 partition as a possible destination for an
image file. I have no clue why it might be unacceptable. It sure seems to
work fine in XP and Dos.

I will attach the FindPart output below, but I dont know what it means.

I also ran Norton Disk Doctor from Sy. It reported "no bootable partition
found", but I told it to leave it alone - that cant apply to the Fat
partition. Its tests ran through all five partitions and reported nothing
else wrong.

-------
Findpart, version 4.42.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: DOS 7.10

Disk: 1 Cylinders: 19458 Heads: 255 Sectors: 63 MB: 152633

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 07 63 51199092 24999 0 1 1 3186 254 63 B OK
3187 1 07 63 51199092 24999 3187* 1 1 6373*254 63 OK OK
3187 2 05 51199155 40965750 20002 6374* 0 1 8923*254 63 3187 OK
Fdisk F6 sector 5806 0 1
Fdisk F6 sector 5806 1 1
6374 1 0B 63 40965687 20002 6374* 1 1 8923*254 63 OK OK
6374 2 05 92164905 40965750 20002 8924* 0 1 11473*254 63 3187 OK
6630 1 0E 63 40965687 20002 6630* 1 1 9179*254 63 00 OK
8924 1 07 63 40965687 20002 8924* 1 1 11473*254 63 OK OK
8924 2 05133130655128246895 62620 11474* 0 1 19456*254 63 3187 OK
11474 1 07 63128246832 62620 11474* 1 1 19456*254 63 OK OK
11730 1 0E 63124134192 60612 11730* 1 1 19456*254 63 00 OK

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
47 0 2 Second FAT not found.
3589 0 2 Second FAT not found.
4054 0 33 Second FAT not found.
6336 0 33 Second FAT not found.
6351 1 2 Second FAT not found.
6374 1 39 9997 16 2 9997 0 0 0 05-09-17 2
6413 1 2 Second FAT not found.
8466 1 33 Second FAT not found.
8807 1 33 Second FAT not found.
15030 1 33 Second FAT not found.

Partitions according to partition tables on first harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63 51199092 24999 0 1 1 3186*254 63 OK OK
0 2 0F 51199155261377550127625 3187* 0 1 19456*254 63 OK

3187 1 07 63 51199092 24999 3187* 1 1 6373*254 63 OK OK
3187 2 05 51199155 40965750 20002 6374* 0 1 8923*254 63 OK

6374 1 0B 63 40965687 20002 6374* 1 1 8923*254 63 OK OK
6374 2 05 92164905 40965750 20002 8924* 0 1 11473*254 63 OK

8924 1 07 63 40965687 20002 8924* 1 1 11473*254 63 OK OK
8924 2 05133130655128246895 62620 11474* 0 1 19456*254 63 OK

11474 1 07 63128246832 62620 11474* 1 1 19456*254 63 OK OK

 

[Folkert Rienstra]

You could choose a more meaningful attribution line.

Thanks. I obtained FindPart and ran it.

The Windows version seemed to hang on me,
Hmm.

wouldn't continue, but the Dos version ran OK under the same Dos boot
that runs Ghost.

Ghost 2003 sees my disk (as source partitions) as:

1 type 7 NTFS 24999MB which is my C:
2 type 7 NTFS 24999MB D:
3 type b FAT32 20002MB E:
4 type 7 NTFS 20002MB F:
5 type 7 NTFS 62620MB G:
- free 2MB

But it will not show the FAT32 partition as a possible destination for an
image file. I have no clue why it might be unacceptable. It sure seems to
work fine in XP and Dos.

I will attach the FindPart output below, but I dont know what it means.

The formatting doesn't help it either. Unfortunately the author doesn't care.

I also ran Norton Disk Doctor from Sy. It reported "no bootable partition
found", but I told it to leave it alone - that cant apply to the Fat partition.
Its tests ran through all five partitions and reported nothing else wrong.

-------
Findpart, version 4.42.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: DOS 7.10

Disk: 1 Cylinders: 19458 Heads: 255 Sectors: 63 MB: 152633

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 07 63 51199092 24999 0 1 1 3186 254 63 B OK

3187 1 07 63 51199092 24999 3187* 1 1 6373*254 63 OK OK
3187 2 05 51199155 40965750 20002 6374* 0 1 8923*254 63 3187 OK

6374 1 0B 63 40965687 20002 6374* 1 1 8923*254 63 OK OK
6374 2 05 92164905 40965750 20002 8924* 0 1 11473*254 63 3187 OK

6630 1 0E 63 40965687 20002 6630* 1 1 9179*254 63 00 OK

Apparently an earlier Fat16x remnant.

8924 1 07 63 40965687 20002 8924* 1 1 11473*254 63 OK OK
8924 2 05 133130655 128246895 62620 11474* 0 1 19456*254 63 3187 OK

11474 1 07 63 128246832 62620 11474* 1 1 19456*254 63 OK OK

11730 1 0E 63 124134192 60612 11730* 1 1 19456*254 63 00 OK

Apparently another earlier Fat16x remnant.

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB

6374 1 39 9997 16 2 9997 0 0 0 05-09-17 2

FAT CHS 6374 1 39 is abnormal, I think.
(6374) 1 33 is usually expected.
You could run findpart on the other systems and see whether that FAT CHS is
the problem here or not.

 

[Wayne]

Hmm.

That was the 4.67 version, I didnt try 4.63. But 4.42 worked OK in Dos.

Apparently an earlier Fat16x remnant.

Thanks, I missed the significance. I dont know how that can possibly be, and
does seem a jumbled mess.

I see the F6 sector, and wondered if I might have used FDISK to look at it
once (a year ago). I cant remember that, but it is not impossible. This disk
happens to be a SATA RAID 0 pair, but Dos can see its FAT32 via the BIOS.

A few weeks ago, I used the Windows XP install disk to remove all partitions,
and recreate all (and restored NTFS with Ghost). Is there a better way to
remove all partitions and start over clean, which might flush this "remnant"?
The remnant cant be real. But Ghost is clearly confused with it too. However
GDisk shows it as OK (a Ghost replacement for Fdisk), and Dos has no trouble
with it.

Actually, I have converted to NTFS here, but I put this one partition back to
FAT32 to try to help a friend that has the same problem - His disk is all
FAT32, and Ghost 2003 wont accept any of his FAT32 partitions as a
destination, external or internal disk. Works with NTFS destinations only.
I can duplicate the same problem here on one computer.

I have an older computer (Asus A7V motherboard), with one new 60GB disk
divided roughly into three 20GB FAT32 partitions, and Ghost 2003 works fine
with it, regarding seeing the FAT32 as destinations. I attach that FindPart
here too, the one that does work - an on which Ghost does see FAT32
destinations. It is much cleaner, which must be the desired goal. The middle
FAT CHS section is the most different. The first computers one FAT32 is not in
that middle report.

Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: DOS 7.10

Disk: 1 Cylinders: 7297 Heads: 255 Sectors: 63 MB: 57239

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0C 63 30716208 14998 0 1 1 1911 254 54 B OK
1912 1 0B 63 38909367 18998 1912* 1 1 4333*254 63 NB OK
1912 2 05 38909430 47584530 23234 4334* 0 1 7295*254 63 1912 OK
0 - 0B 30716343 38909360 18998 1912 1 1 4333 254 56 B OK
4334 1 0B 63 47584467 23234 4334* 1 1 7295*254 63 OK OK

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 14984 8 2 14984 0 0 0 000319 4534
1912 1 35 9495 16 2 9495 0 0 0 011029 7774
4334 1 33 11612 16 2 11612 0 0 0 050104 8084

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0C 63 30716217 14998 0 1 1 1911*254 63 NB OK
0 2 0F 30716280 86493960 42233 1912* 0 1 7295*254 63 OK

1912 1 0B 63 38909367 18998 1912* 1 1 4333*254 63 NB OK
1912 2 05 38909430 47584530 23234 4334* 0 1 7295*254 63 OK

4334 1 0B 63 47584467 23234 4334* 1 1 7295*254 63 OK OK

 

[Rod Speed]

That was the 4.67 version, I didnt try 4.63. But 4.42 worked OK in
Dos.



Thanks, I missed the significance. I dont know how that can possibly
be, and does seem a jumbled mess.

I see the F6 sector, and wondered if I might have used FDISK to look
at it once (a year ago). I cant remember that, but it is not
impossible. This disk happens to be a SATA RAID 0 pair, but Dos can
see its FAT32 via the BIOS.

A few weeks ago, I used the Windows XP install disk to remove
all partitions, and recreate all (and restored NTFS with Ghost).
Is there a better way to remove all partitions and start over
clean, which might flush this "remnant"?

Yes, wipe the drive with something like clearhdd which
writes zeros thru all the sectors in the first few hundred
tracks. That gets rid of everything completely.

The remnant cant be real. But Ghost is clearly confused with it too.

Maybe, or it could be having a problem with something else.

The obvious way to prove that is to wipe the drive and start over.

However GDisk shows it as OK (a Ghost replacement
for Fdisk), and Dos has no trouble with it.

Actually, I have converted to NTFS here, but I put this one partition
back to FAT32 to try to help a friend that has the same problem -
His disk is all FAT32, and Ghost 2003 wont accept any of his FAT32
partitions as a destination, external or internal disk. Works with
NTFS destinations only.
I can duplicate the same problem here on one computer.

I have an older computer (Asus A7V motherboard), with one new 60GB
disk divided roughly into three 20GB FAT32 partitions, and Ghost 2003
works fine with it, regarding seeing the FAT32 as destinations. I
attach that FindPart here too, the one that does work - an on which
Ghost does see FAT32 destinations. It is much cleaner, which must be
the desired goal. The middle FAT CHS section is the most different.
The first computers one FAT32 is not in that middle report.

Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: DOS 7.10

Disk: 1 Cylinders: 7297 Heads: 255 Sectors: 63 MB: 57239

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0C 63 30716208 14998 0 1 1 1911 254 54 B OK
1912 1 0B 63 38909367 18998 1912* 1 1 4333*254 63 NB OK
1912 2 05 38909430 47584530 23234 4334* 0 1 7295*254 63 1912 OK
0 - 0B 30716343 38909360 18998 1912 1 1 4333 254 56 B OK
4334 1 0B 63 47584467 23234 4334* 1 1 7295*254 63 OK OK

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 14984 8 2 14984 0 0 0 000319 4534
1912 1 35 9495 16 2 9495 0 0 0 011029 7774
4334 1 33 11612 16 2 11612 0 0 0 050104 8084

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0C 63 30716217 14998 0 1 1 1911*254 63 NB OK
0 2 0F 30716280 86493960 42233 1912* 0 1 7295*254 63 OK

1912 1 0B 63 38909367 18998 1912* 1 1 4333*254 63 NB OK
1912 2 05 38909430 47584530 23234 4334* 0 1 7295*254 63 OK

4334 1 0B 63 47584467 23234 4334* 1 1 7295*254 63 OK OK

Dunno, I am a bit wary of findpart, just used it on a brand new laptop,
just to check if its got any wierd hidden partitions for maintenance or
restores and the findpart report didnt make a lot of sense to me.

Looks rather like its looking for stuff that might left over
from some stuffup in case that is manually patchable,
but that may not be that useful in your situation.

 

[Folkert Rienstra]

Did I mention that you could use a more meaningful attribution line?
You can also loose the Rich Text in the subject if you are responding in plain text.

That was the 4.67 version,

Yes. Worked fine with me (W98) but that says nothing.

I didnt try 4.63.

Maybe you should, to make sure it isn't Findpart instead of your system.

But 4.42 worked OK in Dos.



Thanks, I missed the significance.

It isn't significant since it is not in the MBR.

It was just a comment.
The real important comment was the one with the FAT that you ignored.

I dont know how that can possibly be, and does seem a jumbled mess.

Previous partitioning or resizing or whatever. If these remnants are in spaces
unused by the current partitions then they may be found by apps scanning the
surface for file system structures.
If they are in data areas they usually are overwritten eventually by user data.
Format doesn't initialize all sectors so what was once written stays if it's
not in MBRs, EPBRs, FATs, Directories or what else have you.

I see the F6 sector, and wondered if I might have used FDISK to look at it
once (a year ago). I cant remember that, but it is not impossible.

Don't know but it may not actually have been Fdisk that wrote them, just an app
using Fdisk routines.

This disk happens to be a SATA RAID 0 pair, but Dos can see its FAT32 via
the BIOS.

A few weeks ago, I used the Windows XP install disk to remove all partitions,
and recreate all (and restored NTFS with Ghost). Is there a better way to
remove all partitions and start over clean, which might flush this "remnant"?

The remnant cant be real.

It's not a problem, just leave it alone.

But Ghost is clearly confused with it too.

Oh, how so?

However GDisk shows it as OK (a Ghost replacement for Fdisk),

and Dos has no trouble with it.

Right, it is not a problem.

Actually, I have converted to NTFS here, but I put this one partition back to
FAT32 to try to help a friend that has the same problem - His disk is all
FAT32, and Ghost 2003 wont accept any of his FAT32 partitions as a
destination, external or internal disk. Works with NTFS destinations only.
I can duplicate the same problem here on one computer.

Yes, and we are looking for possible problem disparities or commonalities
as the possible reason for that.

I have an older computer (Asus A7V motherboard), with one new 60GB disk
divided roughly into three 20GB FAT32 partitions, and Ghost 2003 works fine
with it, regarding seeing the FAT32 as destinations.

I attach that FindPart here too, the one that does work -

Are you saying that the windows version fails on that too?

and on which Ghost does see FAT32 destinations. It is much cleaner,

which must be the desired goal.

I wouldn't think so but it surely minimizes points of concern that then don't
need to be chased down.

The middle FAT CHS section is the most different.

The first computers one FAT32 is not in that middle report.

Any reason why it should, since this is an entirely different and much smaller disk?

Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: DOS 7.10

Disk: 1 Cylinders: 7297 Heads: 255 Sectors: 63 MB: 57239

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0C 63 30716208 14998 0 1 1 1911 254 54 B OK
1912 1 0B 63 38909367 18998 1912* 1 1 4333*254 63 NB OK
1912 2 05 38909430 47584530 23234 4334* 0 1 7295*254 63 1912 OK
0 - 0B 30716343 38909360 18998 1912 1 1 4333 254 56 B OK
4334 1 0B 63 47584467 23234 4334* 1 1 7295*254 63 OK OK

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 14984 8 2 14984 0 0 0 000319 4534

1912 1 35 9495 16 2 9495 0 0 0 011029 7774

Still one with sector 35 in stead of 33.
Perhaps this then isn't a problem for Ghost after all.

 

[Wayne]

The real important comment was the one with the FAT that you ignored.

Sorry, but if I knew what it meant, comments would be easier.
If you know, then I'd like to hear it.

Format doesn't initialize all sectors so what was once written stays if it's
not in MBRs, EPBRs, FATs, Directories or what else have you.

Well, it's totally impossible that there have ever been any FAT16
partitions on this disk, so that may be worse than my original problem.
Any previous partitions were 40GB each. When I recently redid it all, I
reduced some to 20GB. FAT16 is what, 4GB maximum? So whatever that is,
it definitely is not real.

But yes, the FindPart report does really look messy there, compared to the
system where Ghost has no problem seeing FAT32 destination partitions.
But Gdisk, Norton Disk Doctor, XP and IBM PC Dos have no issue with that
FAT32 partition. Only Ghost 2003 does, and disallows it as a destination.
I have no clue how that could come about.

Are you saying that the windows version fails on that too?

Not at all, I only tried the Dos version the second time. I am saying
Ghost cannot see FAT32 destination on one computer, and Ghost has no
problem with the second computer. There is some difference.

 

[Wayne]

Yes, wipe the drive with something like clearhdd which
writes zeros thru all the sectors in the first few hundred
tracks. That gets rid of everything completely.

Thanks Rod, that sounds like a very good plan. There has to be some
reason Ghost doesnt allow FAT32 destinations on this disk, and this
should eliminate some things. I downloaded clearhdd, and will try to
get up the gumption this weekend. The BIOS access to the RAID and
SATA may be the whole problem, but Dos seems not to have any trouble
with this disk.

I'm wondering if clearhdd possibly could address my other issue with
this disk too. When I redid all the disk partitions, it was because I
changed from the Promise Raid controller to the VIA Raid controller.
Which was good, and it also seemed to allow changing from the fixed 64KB
stripe size, and I specified 32KB. But after restoring the partitions
with Ghost, it came out 64KB again. I dont know why, it appeared that
Ghost must have done that somehow. I dont know why Ghost would care, and
am wishfully thinking perhaps the value was just stored there someplace,
and this might rewrite that too.

 

[Rod Speed]

Thanks Rod, that sounds like a very good plan. There has to be some
reason Ghost doesnt allow FAT32 destinations on this disk, and this
should eliminate some things. I downloaded clearhdd, and will try to
get up the gumption this weekend. The BIOS access to the RAID and
SATA may be the whole problem, but Dos seems not to have any trouble
with this disk.

I'm wondering if clearhdd possibly could address my other issue with
this disk too. When I redid all the disk partitions, it was because I
changed from the Promise Raid controller to the VIA Raid controller.
Which was good, and it also seemed to allow changing from the fixed
64KB stripe size, and I specified 32KB. But after restoring the
partitions with Ghost, it came out 64KB again. I dont know why, it
appeared that Ghost must have done that somehow. I dont know why
Ghost would care, and am wishfully thinking perhaps the value was
just stored there someplace, and this might rewrite that too.

Yeah, the stripe size has to be stored somewhere. Corse its possible
that where its stored gets restored by Ghost too, particularly if you
restore an entire physical drive rather than just a partition.

 

[Folkert Rienstra]

I don't really have your attention, have I.
If you don't want to work with me, fine, have it your way.

Sorry, but if I knew what it meant, comments would be easier.
If you know, then I'd like to hear it.


Well, it's totally impossible that there have ever been any FAT16
partitions on this disk, so that may be worse than my original problem.
Any previous partitions were 40GB each. When I recently redid it all, I
reduced some to 20GB. FAT16 is what, 4GB maximum? So whatever that is,
it definitely is not real.

Read my lips: IT IS NOT IMPORTANT !
Stop ranting.

 

[Folkert Rienstra]

Clearly not if it only clears 'the first few hundred tracks'.

Thanks Rod, that sounds like a very good plan.
Not.

There has to be some reason Ghost doesnt allow FAT32
destinations on this disk, and this should eliminate some things.
I downloaded clearhdd, and will try to get up the gumption this weekend.

The BIOS access to the RAID and SATA may be the whole problem,

Where did that come from?

but Dos seems not to have any trouble with this disk.

And it's only DOS that is using the BIOS.

I'm wondering if clearhdd possibly could address my other issue with
this disk too. When I redid all the disk partitions, it was because I
changed from the Promise Raid controller to the VIA Raid controller.
Which was good, and it also seemed to allow changing from the fixed
64KB stripe size, and I specified 32KB.

But after restoring the partitions with Ghost, it came out 64KB again.
I dont know why, it appeared that Ghost must have done that somehow.

Doubtful if the backup was from the Promise and restored to the VIA.
It's doubtful that Promise and VIA use the same setup data.

I dont know why Ghost would care,

It shouldn't and almost certainly doesn't.

and am wishfully thinking perhaps the value was just stored there someplace,
and this might rewrite that too.

So you clear that with clearhdd and then Ghost restores it, once again.