This topic is a new start on "Norton Ghost 2003, PC-DOS, mark drives" and is addressed primarily to Nigel Bree, though I'll be pleased to receive advice also from others. I need some help in getting my Ghost 2003 to fully recognse all of my drives/partitions. Let me fill you in on the background.

I bought Ghost 2003 in 2004 and it's worked very well on my dual-boot PC of Win2K and WinXP. Together with the one 80GB parallel ATA hard drive (partitioned four ways) and an external USB hard drive, it all worked fine. I did regfular LiveUpdates and ended up with Build 793. From the start, I opted to mark the drives. I would run Ghost only in Win2K and would only use PC-DOS via a Bootdisk, rather than running from Windows. I was able to make images of both my Win2K and WinXP partitions, putting the majority of them on the external USB drive.

More recently, though, I ran out of space on my system partition, so knowing that I could clone my existing hard drive to another (I'd made some clones of the 80GB drive, over the years, as backups), I bought and fitted a bigger hard drive - a parallel 250GB, same manufacturer. I successfully cloned from the 80GB drive to that drive, expanding the sizes of the original partitions. The new hard drive and its contents ran fine but when it came to imaging and running in PC-DOS, Ghost would simply not recognise the source partitions on the new drive. It recognised the drive, since again I opted to mark the drives, but Ghost would only see the ext USB drive's partitions, not the new main drive's partitions. I tried all sorts of remedies but none worked. Imaging to the ext drive was simply no longer possible.

Actually, I also have been wanting to eliminate Win2K from my PC and to run just WinXP (since Microsoft's support for Win2K is virtually zero these days), but realised that because Win2K was the System partition, removing Win2K would have caused problems with WinXP (resulting driveletter recognition problem in the Windows Registry). So, at that stage, I became resigned to having to reformat the new hard drive and to later reinstall just WinXP on it, plus all my apps, from complete scratch. I did that last week. It took me six solid days of work.

It gave me the opportunity to use my Ghost CD to reinstall the program from scratch. Along the way, I made some images, putting them into a reserved partition on the new main drive - but, again, specifically using a Bootdisk (a new one I made). I realised Ghost from the CD wouldn't be the latest build, but I'd found the service1.symantec.com webpage with the procedure on it for obtaining the up-to-date LiveUpdate and for ultimately updating to build 793. I did that and so now have Build 793.

In case the former problem was something to do with agreeing to having the drives marked, this time I've opted to proceed without marking the drives. Nothing seems to have changed, though, as I still can't access the ext USB drive from Ghost, to image to it. If I leave the ext USB drive powered off, Ghost sees the individual partitions of the new main hard drive (and presumably I can therefore still make images and do restores to/from the reserved partition on that drive). But, if I power the ext USB drive on, Ghost will only see the partitions of that and not any of the partitions of the main drive. Okay, I've not yet marked the new drive but I'm loath to do that because, before, that hadn't enabled every drive to be recognised.

What am I doing wrong, if anything? Will the system now not work because Ghost originally marked the USB drive as well and it's still marked that way and is interpreted by Ghost as being incompatible with the new main drive?

As I see it, I've stuck to Symantec's User's Agreement, in that I'm only using Ghost on one machine. Indeed, the machine has only changed in respect of me changing the main hard drive to a bigger one. After all, the whole point of having an app like Ghost is to be able to clone a drive for backup or change to a bigger drive if and when the need arises. The few images I've made so far on the new hard drive are meant only as interim images. I need to put the main bulk of my images from hereon on to the ext USB drive. But currently Ghost isn't allowing that.

Got any ideas for solving this problem? I'm using just WinXP now, with SP3. Chipset drivers are the latest ones and the USB drive is accessible with Windows Explorer and other apps.

To repeat yet again: the only function of drive marking (other than the presence of the prompt itself, which has a side-effect of reminding people Ghost is licensed) is to correlate the drive letter assignments in Windows and DOS - IT DOES NOTHING ELSE. While the belief to the contrary is clearly very persistent, it's not true. Whether you choose to mark drives or not has no impact on what drives Ghost displays, and never has, and never will.


Quote:

What am I doing wrong, if anything?

You aren't necessarily doing anything wrong; these kinds of things are usually problems in the machine, either hardware (or more commonly, BIOS firmware).

In your case the very first thing you need to verify is the IDE cable termination; the master/slave relationship between drives is actually very important, because the "master" drives provide resistive termination for the cable to stop signal reflection. You need to confirm that the new drive is set to be a master and connected to the end of the ribbon cable, not the "slave" connector in the middle; if this isn't done, the electrical signals to the drive will be very marginal, because of the lack of cable termination. Improperly terminated cables cause all kinds of problems, including inconsistencies in detecting the drive presence. Ghost's built-in IDE drivers are almost certainly not as robust as dealing with this kind of problem as Windows and some BIOSes.

Beyond that I don't have a lot of suggestions, at least the ancient Ghost 2003; as with most of these kinds of faults, they are easy to diagnose if you have the machine in front of you but it's almost impossible from halfway around the world; if you're running build 793, you can try employing the switches to disable Ghost's built-in IDE drivers (-fni) to see if that makes a difference.

Nigel,

The new IDE drive is definitely installed as a master and in precisely the way that you suggest. There are no mistakes or half-fitted cables in that area. I'm a retired hardware specialist and I'm absolutely meticulous about such things. Incidentally, by "dual-boot", I mean that Win2K and WinXP were installed in their own partitions on the one physical drive, not on more than one physical drive. Just wanted to make that clear. Currently, the PC works perfectly in every respect, except for this aspect of Ghost 2003.

Let me summarise the previous and current situation:-

Original PC setup was a dual-boot of 2K/XP on an 80GB parallel ATA drive, plus an ext USB parallel drive. Both drives were partitioned. The ext drive was used for images of the 2K/XP partitions and for storing backups of photo and audio files. Generally, I would image 2K and XP partitions to a reserved partition on the ext drive. Both drives were marked. The Ghost program was installed only into the Win2K partition on the 80GB drive. Imaging and cloning was always done with a Bootdisk. No problems were ever encountered - imaging and restores were always successful.

Recent new tryout was to clone the 80GB contents to a 250GB parallel ATA drive and to use the latter in place of the 80GB. Absolutely no other hardware changes were made. With the ext drive powered on, the partitions of the new main drive were not displayed by PC-DOS. The tryout therefore had to be abandoned.

A couple of weeks ago, I low-level formatted the 250GB drive, then embarked on a complete manual reinstall of just WinXP this time, plus all my apps. This included a virgin reinstall of the Ghost app, for which I later installed the updated build to 793. The ext drive remains as original, and still includes two images on it from the very original dual-boot setup. These two images were made with the Win2K Ghost app and in due course I'll probably delete them. I assume that the ext drive was originally also marked by Ghost and so is still marked. Again, PC-DOS does not display the new 250GB drive and its partitions if the ext drive is also powered on; it only displays the ext drive's partitions. The converse is true if the ext drive is off. At present, I've not opted to mark the new drive, since doing that made no difference before.

I'm wondering whether this problem is simply due to the fact that the ext drive is marked and is referred to Win2K but the new main drive is unmarked and Win2K no longer exists. Remember also that the current Ghost app is completely new and knows nothing of went beforehand.

I'm also wondering whether the assigning of driveletters in Ghost might have some bearing on this behaviour. At present no driveletters are used. However, that was also the case in the original dual-boot setup and that setup worked perfectly fine.

In theory, would removing the marking of the ext drive solve this? That is, would formatting the ext drive fix it, even a low-level format? That would then presumably return both physical drives to unmarked status and I could then proceed from there.

Once again, no changes were made to the hardware of the PC, except for swapping the one main hard drive for the bigger one, albeit that the partitions on it are now different. But then the current Ghost app on it doesn't know about a past existence.

An afterthought: The capacity of the ext drive is also 250GB. Could that be confusing PC-DOS, especially as I'm not opting for driveletters in PC-DOS?

Hello again,

ghost 2003 retail does sometimes change settings in Bios (READ/Write)
so check your Bios setting .
................................
here I googled some info which might be useful to you
=================
problems with Norton ghost2003 and SATA drives

Run Norton Ghost with the -NOIDE switch from a floppy. It only works
with Ghost 7 or later as far as I remember.
or
Change you HD from SATA to PATA in Bios Setup and try to Ghost your
hard drive, After you finish you can change it back.


Question
but can't ghost from IDE to SATA and back then??
answer:
Yeah you can use both but you need to use the -fni
if you have SATA hard disk use ghost with -nfi switch. it worked with
ghost 7.0 ver.
Working on a Dell SX 280 I was able to change the BIOS settings for the
SATA controller to Combination. The default is normal. This worked. I
am ussing Ghost 7.5 enterprise
If you boot with a boot disk, switch to the floppy with the ghost.exe
on it and type ghost /noide , that should do it
thx guys
ghost /FNI saved my life..
thanks a lot. The -NOIDE switch it works perfectly
well here i my FIX to this problem

My main HD is a ide 120gb disk and i got a 160 sata as a d drive -- i
just unplugt my SATA disk and PC dos worket 1th time and i am burning
image NOW so drop the SATA disk wile backing up and replug it after
works for me

apply the -fni switch to gosth it will solve the problem for version 7
and up. save the day
wanted to say thanks to that /FNI switch command. That works great
Cannot start Windows after starting a Ghost 2003 task from Windows
http://service1.symantec.com/SUPPORT/ghost.nsf/8f7dc138830563c888256c2200662ecd/dfb4b017218165c088256c3f00622fae?OpenDocument&sone=ghost_2003_tasks.html&stg=3%E2%88%8F=Norton+Ghost&ver=2003+for+Windows+2000/NT/Me/98/XP&base=http%3A//www.symantec.com/techsupp/ghost/&next=ghost_2003_contact_tscs_other.html&src=sg&pcode=ghost&svy=


Just letting you know, Ghost 2003 does support Serial ATA if you run the latest Live Update on it.
Alternatively if you use the -FNI switch after the ghost exe command it will force ghost to use the BIOS to gain access to the IDE drive(s).

How to use GhReboot
===============================
Ghost 14 or Acronis true image 11 will solve your problem
and Acronis is really good and much cheaper than Ghost.
and there is a Bart plugin for it.
http://ubcd4win.com/forum/index.php?showtopic=10471&hl=acronis


Regards Ben
:)

voximan wrote on Sep 14^th, 2008 at 5:36am:

I'm a retired hardware specialist

Then you'll understand the importance of being systematic in working through the likely causes.

If the drive is correctly mounted on the IDE cable, the next likely cause of the problem you are observing is due to IRQ conflicts between the USB host adapter and the IDE controller. Remember that DOS-based Ghost is running in a non-ACPI environment and due to the need to use third-party drivers is not able to switch the machine into ACPI mode and use the APIC interrupt handling scheme where the PCI interrupt lines can be "shared".

The same resolution applies; use one of the switches that disables Ghost's built-in IDE driver. By forcing the hard disk access through BIOS drivers which operate in a polled mode rather than an interrupt-driven one, it should prevent problems caused by devices trying to share a single IRQ line when the legacy PIC mode is active.

Try the -FNI or -NOIDE switches and see if those make a difference.


voximan wrote on Sep 14^th, 2008 at 5:36am:

An afterthought: The capacity of the ext drive is also 250GB

While that isn't a likely factor with the external drive (USB mass storage uses a SCSI-type command set), it's possibly a factor for the internal drive. The most significant thing about the  this is that it's a capacity which crosses the 137Gb size limit of the original 28-bit IDE interface and is in the category of drives where you need 48-bit LBA support.

Ghost's decisions about which of the many code paths it can try and use to access the disk is a complex mixture of many, many things based on probing the capabilities of the disks and of the BIOS (even just at the BIOS level there are three different systems for describing the disk capacities that it tries in sequence).

I can't say for certain given just how old Ghost 2003 is now - remembering that we've made 5 releases since, and we are always doing all our testing and dogfooding on the latest releases - but it may well be that since it was one of the first releases after we added 48-bit LBA support to it that it's more strongly wanting to use its own built-in IDE driver code. This will be especially true if something leads it to decide that the system BIOS likely isn't capable of actually supporting access to the disk sectors past the 137Gb range.

This is why something like IRQ conflicting might be an issue here; the original drive might have been completely BIOS-accessible and thus been able to be accessed that way while the USB drivers were active, but if the drive requires a 48-bit-aware BIOS and Ghost thinks it isn't it's hard. Unfortunately it's not simple diagnosing Ghost's choices.

Of course, if the need for 48-bit LBA is a contributing factor, and the BIOS support for it isn't 100%, then using the BIOS won't necessarily be a great idea either. In that case you'd be best running Ghost on Windows PE.


voximan wrote on Sep 14^th, 2008 at 5:36am:

I'm wondering whether this problem is simply due to the fact that the ext drive is marked

No. Let me re-iterate, marking doesn't affect Ghost's selection of drives and partitions to display to you.

The drive marks are used in one and only one way; a clone operation initiated from the Ghost 2003 Windows wizard creates a special command line for Ghost in the Virtual Partition. This identifies the source or target partitions specially, using the (random) GUID written out by the marking procedure, so that it is absolutely impossible for Ghost to clone over the wrong partition. It's a safety feature, and only actively used when the GUID form of identifier is placed on the command line.

That, and the lack of a mark bringing up a screen which requires interactive input (to make the consumer product harder to use in an automated way by pirates) is the sum total of what the drive marking code does.

Nigel,

I built this PC myself and know it like the back of my hand. There are no IRQ conflicts. As I keep stating, Ghost worked perfectly until I changed the 80GB main hard drive for the 250GB main hard drive. The PC does support drives greater than 138GB, as does the OS; I checked that out thoroughly before I even bought the new drive. The PC works perfectly in all other respects. I'm using it right now; I have only one PC. I keep records of every setting in my System BIOS and, at present, all of those settings are correct.

Apart from the size of the new main hard drive, the only difference between the former setup and the setup now is that the external drive is now pre-marked by a version of the Ghost application that formerly ran under Win2K. That said, I don't think that the OS has anything to do with the problem, because the 'cloned drive tryout', awhile back, also gave this problem.

At the time of that 'tryout', I also tried a number of the switches available. I found you could do this within PC-DOS itself, using the tabs in Options. It didn't change anything.

What I can't quite fathom, Nigel, is that you're on the one hand saying that marking the drives assists in the distinction of drives or partitions from one another but, on the other hand, would play no part in the kind of problem I've got. I'm afraid you've lost me there. Surely, the very problem that I have is that PC-DOS fails to recognise the main drive and the external drive concurrently? Oddly, it recognises just the one in one situation, and just the other in the other situation (if you see what I mean).

One thing I'd like to know is whether a drive or partition can be marked a second time. For example, I currently have the situation where the 250GB main hard drive is unmarked but the external drive is already marked (from the former setup). If I now allow Ghost to mark the main hard drive, will an ID code also be written to the external drive (provided I have it powered on, of course), overwriting the ID code that already exists on that drive? Is the ID code always written to exactly the same location on the drive?

Getting back to the problem in hand, I don't know whether this is significant but, if I switch the external drive on and then open the Ghost application, the Windows environment of Ghost definitely sees all the drives and all their partitions. That is, if I start to run the Backup wizard, it displays the tree structure of ALL the drives. Note, however, that in the Windows environment, the marking of any unmarked drives that are there is NOT optional. Beyond selecting the source drive or partition, you cannot proceed any further with the wizard until you agree to a Disk Identification notice that pops up. Therefore, one can only conclude from that that marking the drives is ultra-important, at least in the Windows environment. In the PC-DOS environment, marking IS optional and backing-up can proceed but, in my current situation, not all of the drives/partitions can be seen at one time. Depending on whether the external drive is on or not, PC-DOS may or may not see the main drive and its partitions. Either way, I can't image any partitions to the external drive. It's as if Ghost gets confused because there happens to be two virtually-identical hard drives in the setup. Perhaps, in a case like this, it's necessary to allow PC-DOS to assign driveletters?

voximan,

Nigel has stated in several posts that disk marking is not causing your problem. If you aren't convinced why don't you remove the marking. It should be easy to do from Windows with Roadkil's Sector Editor. I gather the marking can be in any sector of the First Track but several posts in this forum mention LBA-62.

http://www.roadkil.net/listing.php?Category=2

Brian,

I'm not at all contesting what Nigel has stated, so I apologise if you and others have perhaps got the wrong impression. I've merely described the symptoms of my problem.

It IS the case, though, that marking is NOT optional in the Windows environment, or at least that's what I'm finding in MY edition of the application. That seems to fit with what Nigel stated, in fact, that Ghost requires some sort of cross-correlation of the drives/partitions, between the Windows environment and the PC-DOS environment, in order to ensure that the correct drives/partitions are backed up/restored, when chosen. Obviously, any doubt in that area could result in disaster. It's clear to me now that the designers of Ghost 2003 achieved that assurance by using marking. So, marking is mandatory in the Windows environment but not in the PC-DOS environment.

It would be useful to know whether drives/partitions can be RE-MARKED and whether the designers took that into account. If they can, then I'll try marking my drives in the Windows environment and trust that the existing marking of the ext USB drive gets overwritten. You see, that ext drive was marked when I ran the Ghost application in Win2K, whereas now it runs in WinXP. I don't normally run Ghost from the Windows environment, though, I normally boot into PC-DOS from a Bootdisk.

Some time ago, I found some legacy articles at the Symantec website on failure of Ghost 2003 to recognise ext USB drives. One of them, of course, recommended the special LU update. If that didn't do the trick, then it was suggested that a Bootdisk with modified config.sys file be made. I did both of those and obviously neither of them cured the problem. In fact, in my case, it's not that Ghost doesn't recognise the ext USB drive, it's that it doesn't (in the PC-DOS environment) display both my main hard drive AND that ext drive in the same session. So, I can't at present back up or restore to/from the ext drive. PC-DOS mistakes the ext drive for the source drive and then doesn't find the main drive. If I turn off the ext drive, though, it DOES see the main drive.

voximan wrote on Sep 16^th, 2008 at 6:23am:

It would be useful to know whether drives/partitions can be RE-MARKED

You can unmark and then re-mark the drives.

Brian,

I meant 'by using Ghost'.

Concerning that Roadkil editor, have you yourself successfully used it?

voximan wrote on Sep 16^th, 2008 at 7:01am:

I meant 'by using Ghost'.

voximan, I don't think it's possible.


Quote:

Concerning that Roadkil editor, have you yourself successfully used it?

I used it last night to unmark and re-mark drives on my test computer.

My last post was ambiguous. I was using Roadkil to unmark drives.

Roadkil's Sector Editor was introduced to this forum by Dan Goodell, a few years ago. Some people were having trouble seeing their external hard drives from the PE recovery environment of Ghost 10. Using Roadkil to zero the DiskID of the external HD was one way to fix that issue.

I've no reason to not believe him, but Nigel Bree insists that Disk IDs have nothing whatsoever to do with one drive or another not being accessible by Ghost. You seem to be saying that people have used Roadkil to clear the ID on external drives when those drives have become inaccessible by Ghost. Mind you, you're talking about Ghost 10. My situation is with Ghost 2003.

The DiskID was just a comment about one use of Roadkil. It has nothing to do with Ghost 2003.

I'm using Ghost 2003 (793) from a set of floppies. I have a mobile rack and hard disks (all IDE/PATA) are swapped in and out. On one occasion, a new hard disk was in the rack. Since it was not mine but borrowed, I choose to not let Ghost 2003 mark it and it did not show up in the list of available disks. Restarting Ghost 2003 and letting it have its way (marking the hard disk) made it available.

This was the first time that I chose to not let Ghost 2003 mark the hard disk which means that my statistical foundation is somewhat limited ... ;) ... !

Christer

That's interesting, Christer. As you may have read, at present my ext USB is marked but my new IDE/PATA 250GB drive isn't, and depending on whether the USB drive is on or not, I can/cannot see the PATA drive when I use a Bootdisk to boot into PC-DOS. I've been wondering whether to try marking the new PATA drive, either by letting PC-DOS do it or by doing it in the Windows environment, but Nigel Bree is emphatic that doing so will not cure my problem and will not miraculously make both my drives visible to Ghost.

Some time ago, when I installed the new drive and cloned it to the smaller one, that new drive would have automatically been marked (since it was a clone). The ext USB drive was also marked. And yet, as now, I couldn't see either the new drive's or ext drive's partitions, depending on whether the ext drive was switched on or not. So, on the face of it, marking the new drive now wouldn't make a scrap of difference. Under the original Win2k/WinXP dual-boot arrangement I ran, though, both the 80GB main (PATA) drive and the ext drive WERE marked and WERE both visible. So, for me, it's a matter of finding out what's changed that now prevents both being visible. Other than me running Ghost 2003 in WinXP now, rather than in Win2K, the only change I've made from the dual-bbot setup is replacing the 80GB drive by a 250GB version. My machine and BIOS do support large-size drives. The USB 2.0 drivers on my machine are exactly the same as before and are the latest.

Pure and simple logic suggests to me that marking might still be an influence in this. Possibly, the 'law of unintended consequences' applies. In my case, the ext drive's marking was performed originally by Ghost working under Win2K and essentially remains as that. But the current setup functions under WinXP, so one naturally asks the question 'Is there any reason why the current Ghost 2003 should know this?'. Put another way, the original parent Ghost program which marked the ext drive no longer exists. Maybe this leaves the ext drive out on a limb?

Christer, have you or have you not allowed both the main Ghost 2003 program and the Bootdisk to themselves assign driveletters? Conceivably, that's a factor in this problem.
 

Quote:

Christer, have you or have you not allowed both the main Ghost 2003 program and the Bootdisk to themselves assign driveletters? Conceivably, that's a factor in this problem.

All my partitions are NTFS and they are not given drive letters in Ghost but numbers, such as 1:1, 1:2 for drive #1 (#0 in DOS) and 2:1, 2:2 for drive #2 (#1 in DOS).

Note that I always run Ghost from a set of floppies, created from within the installed Ghost (which I only use to create the floppies and for Ghost Explorer).

Christer

Hello again,
you did not use ubcd4win or Acronis 11 in previous link
so you love ghost so here is another free tip and link.


ghost 2003 is basically rubbish as it marks the drives  the corporate version of same software
ghost 7.5 and ghost 8 do not do that.
so get the corporate version of ghost 8 read the tips in link below how to get it



http://www.911cd.net/forums//index.php?showtopic=14127

read by 96,642

the conclusion: is that to make a bootable ghost floppy or bootable ghost CD  for  recovery you need to have the ghost.exe on the floppy or the bootable CD.
therefore the reverse is also true , that is if you got a ghost bootable recovery cd or floppy eg E-machine recovery CD


or Advent recovery CDS (that use ghost to recover the image) then you a can extract the ghost.exe from it.let it load then press Escape key then using simple DOS commands like DIR and copy *.* C:\temp
assuming your c:drive is fat32.
you get the complete files on the original bottale floppy including the ghost.exe

or simply use winimage or isobuster to extract the boot image including ghost.exe
 
as i said before if you have an e-machine or Advent machine that uses ghost on the recovery CD
you can extract the image with Winimage from the CD including Ghost.exe
or boot with the CD and when you get to the menu were it tells you do you want to
recover the operating system ?? say NO or press ESC key you get A: prompt or a flashing dash
then do a DIR and you will see ghost.exe and all other bootable files.
then put a new floppy in floppy drive
and type
COPY ghost.exe B:
and press enter this is because your RAM drive is A: and floppy becomes B:
so you get your Ghost .exe floppy
this ghost.exe is much better than the personal ones as it is enterprise version(more capabilities)

Ben
:)

Christer wrote on Sep 17^th, 2008 at 6:02am:

I choose to not let Ghost 2003 mark it and it did not show up in the list of available disks

That's a different situation that what the original poster seems to be describing; if you get the prompt to mark the disk from the DOS-based Ghost, then the drive has been detected fine - if you choose not to mark it, it does drop the drive from the selection box. That's because you're choosing, in effect, not to agree to the EULA (there's simply no other reason not to mark the drives, after all - it's perfectly safe and harmless).

That's a different situation from one where you don't get such a prompt from the DOS-based code, and one or other disks just doesn't show up at all (which is what the original poster is describing). In that case, the problem lies much much deeper, and in the older editions from the 7.x series in particular (or with network adapters in the corporate edition, since those are the only external drivers which don't tend to understand IRQ sharing) it's most often an IRQ conflict.

In the 2.0 and above GSS we have a tool explicitly for this; https://forums.symantec.com/syment/board/message?board.id=109&message.id=370 and in more recent editions that summary has proven so useful is a standard part of what we put into the GHOSTERR.TXT dump data. Note from the dump the customer supplied that the GX270 in particular has both a USB host controller *and* a NIC on the same legacy IRQ as the storage adapters.

Dealing with these IRQ issues is a problem because these BIOS assignments are temporary; when an ACPI-aware OS takes over, it reassigns all these (as with all the other PCI configuration resources) because it can use the additional IRQ lines numbered 16 and up from the IO-APIC. So, the IRQ assignments you see in Windows don't bear any relationship to the ones in effect in DOS, and without a tool to show you how the BIOS has actually laid out the PCI configuration (there's an ACPI data table for this) it's hard to know where things have ended up.

For USB in particular it's extremely complex because for instance when you have a BIOS that supports booting from USB, then the INT13 provider for it typically will be running in a polled mode, so whether or not you boot from a USB device can affect this too. And if you're using Ghost's built-in drivers entirely, then you're usually OK as well, because they use a convention for shared legacy IRQ handling defined by IBM originally for the Micro Channel bus in the PS/2. Conflicts are thus mainly a problem with third-party drivers; NIC drivers in the corporate edition or, in the case of Ghost 2003 before 793, the Iomega USB drivers.

".............. if you get the prompt to mark the disk from the DOS-based Ghost, then the drive has been detected fine - if you choose not to mark it, it does drop the drive from the selection box. That's because you're choosing, in effect, not to agree to the EULA (there's simply no other reason not to mark the drives, after all - it's perfectly safe and harmless)".

Nigel,

That does, at least, put a different light on it. The warning message/buttons that you get when you first boot into PC-DOS, though, give the impression, rightly or wrongly, that agreeing to the marking is optional; the message includes a statement that non-marking is, in effect, acceptable for 'forensic-standard' imaging or recovery.

I bow to your superior knowledge of IRQs and how they might affect this situation. However, as I keep stating, before I changed the hard drive for a bigger one, there were no problems with Ghost. I'd been imaging and restoring and cloning (to keep as backup drive) literally for years. There is some sharing of IRQs on my PC but I've never, in all the years that I've had this machine (it's one I built myself, so I know it extremely well), had a single problem with IRQs or with any clashes.

The 'tryout' situation I had was when I simply cloned the original 80GB hard drive and its contents to the bigger 250GB drive, surplanting the former. Absolutely nothing else changed. I ran the tryout, it being dual-boot of Win2K and WinXP, for about a week and everything worked fine, EXCEPT that PC-DOS would refuse to show both drives. As now, it was 'either one or the other but not both'. In theory, there was no need to mark or re-mark that cloned drive, because presumably the original marking got automatically copied across during the cloning process. The ext USB drive, of course, remained completely unchanged. When I ran PC-DOS in that setup, I don't recall being invited to mark the drives, but I can't swear to that. If I was, then I would have agreed to it. However, the net result was still that one of the drives, either the main drive or the ext USB drive, was always inaccessible in PC-DOS.

I could find absolutely no other reason for the problem, so my only recourse was to re-install the 80GB drive. However, I did also want to dispense with my Win2K partition, which unfortunately was on the C partition, so I resigned to low-level formatting the 250GB drive and then re-installing my WinXP and all my apps manually, from absolute scratch. That included Ghost 2003 of course and, as I've earlier described, I managed eventually to update it to 793, the version I'd had before. This is the current setup, and there's no change in the problem - PC-DOS is still refusing to see BOTH the 250GB drive and the ext USB drive. However, I have yet to agree, in PC-DOS, to having the drives marked. Why? Well, simply because (a) the 'tryout' hadn't worked with marking, and (b) because, earlier in these postings, you gave me and others the impression that marking would have no impact at all on this recognition problem.

Nigel,

I thought I'd bite the bullet and, in my current setup, finally allow my 250GB drive to be marked, and then see if that made any difference to this drive recognition problem. It didn't, but I have uncovered a clue, so perhaps you can help. The following is what I did.

I decided to try to make a backup as before, to the ext USB drive, but to first mark the main drive in the Windows environment, and then run the backup from that Windows environment. After marking Disk 1, Ghost allowed me to proceed to the subsequent steps. I made sure my options in Ghost were as required (including NOT allowing Ghost to assign driveletters) and the final step was reached where Ghost said it was about to boot to PC-DOS. However, at that point, Ghost flagged the following message:

"Unable to find a free MBR slot in the Virtual Partition DLL. This is usually due to there being no free primary partition slots left on the boot disk".

Of course, Ghost did not then proceed any further.

Having marked the drives (I'm not sure if Ghost will have overwritten or not the original ID on the ext USB drive), I thought it was worth trying to image in PC-DOS so, as normal, I booted into PC-DOS. It no longer asked me if I wished to mark the drives - fine. However, in PC-DOS, it's still not possible to see both drives - it's a case of either one drive or the other, but not both.

Now, I'm not sure what exactly Ghost means, in the context of virtual partitions, by "no free primary partition slots". In trying to do a backup, I was attempting to backup my root partition, on the main hard drive, to a reserved partition on the ext USB hard drive. My main hard drive is partitioned into four, all being Primary partitions. As far as I'm aware, that's not breaking any rules, as you're allowed up to four Primaries.

So, yes, it's true that there's currently no room for any more Primary partitions on my main hard drive. The ext USB drive has three primary partitions, BTW.

I do have around 500MB of unpartitioned space left on the main drive.

Can you tell me if I've broken a fundamental rule, here, and whether that might be the reason why I've had this drive recognition problem?

Despite it currently holding data, I could, if necessary, delete one of the Primary partitions on the main drive and re-form it into an Extended/Logical partition. That'd then mean that I'd have just three Primary partitions on that drive.

Incidentally, will I need to make a new Bootdisk?

voximan wrote on Sep 18^th, 2008 at 9:50am:

As far as I'm aware, that's not breaking any rules, as you're allowed up to four Primaries.

Except that sometimes other things need them, as in this case, and then you've got no room as Ghost is telling you. Four primary partitions is legal, but since they are a scarce resource using all four of them is not a good idea.

Moreover, when creating an extended partition table, that extended partition table (a secondary copy of the MBR further down the disk) needs a primary partition slot to describe it. So, if you have any extended partitions, you are consuming one slot for that. That means a sensible partitioning arrangement needs to only use two classic primary partitions, and the rest in a linked chain of extended partitions.

The Ghost 2003 variation on the virtual partition system creates a temporary partition within the existing MBR on the boot drive, and that means it needs one of primary partition entries for that. More recent editions of Ghost (GSS2.5, specifically) temporarily replace the original MBR completely while entering the temporary cloning environment and so aren't subject to that limitation any more (however, replacing the MBR code in the drive was not a small step and not without its own attendant difficulties - like most of these things, it's not as easy as end users imagine).


voximan wrote on Sep 18^th, 2008 at 9:50am:

Incidentally, will I need to make a new Bootdisk?

If your existing boot disk isn't using build 793, then that would be useful. The most productive thing you can do (other than try using the -noide and -fni switches as suggested earlier) is use an edition that doesn't employ the Iomega guest drivers, but rather uses Ghost's built-in code. In that case you won't have anything on the USB disk appear as a drive letter in PC-DOS, but Ghost's built-in USB drivers will still allow Ghost to work with the disk; if the root source of the problems is an IRQ conflict, this may well help.

Yes, you're right - I looked through my Ghost 2003 user's manual and at the bottom of p13 it says:

"One primary partition slot must be available in the MBR for the Virtual Partition".

It's been so many years since I had to consider that that I totally missed that point. In my original dual-boot setup (and actually also in the cloned 'tryout'), there were two Primaries (one each for Win2K and WinXP) and two Logicals. When I reinstalled WinXP from scratch, I changed that to four Primaries. It looks like I'll have to now change a couple of them to Extended/Logicals. I hope, however, that that won't mean that Ghost will then no longer recognise that the drive, as a whole, is marked.

This primary partition count is clearly a major cause of Ghost not functioning properly at the moment but I do suspect that, even when I correct that, I'll still have the ongoing problem. In the 'tryout', Ghost failed to recognise both the drives concurrently. All I can do is make the changes to the partition types and then keep my fingers crossed.

I do have a Bootdisk that I made on the original dual-boot setup, which was made in Ghost on Win2K (Build 793). That Bootdisk worked fine and always installed the Iomega drivers (as shown on the screen in the boot sequence). I also have a Build 775 Bootdisk, made under WinXP. I think that also includes Iomega drivers. And finally, I have a Build 789 Bootdisk made with WinXP, which unfortunately got effectively updated just recently when I tried using it on the Build 793 Ghost (in the boot sequence, it stopped and I had to write-enable the Bootdisk, to allow Ghost to write a further entry on it; I'm not sure what that was; maybe it was just a revised mouse driver that it was adding; I guess that that Bootdisk is now a Build 793 Bootdisk).

Since my first experience with a PC (a self-built IBM XT-Clone) and MS-Dos 2.0, I've come up with a conclusion that's served me well, all these 28 years.
On any computer there are things that CAN be done, within the limitations of the hardware, but probably shouldn't be done.  That's where experience takes over from youthful exuberance. ;)

Sure, you can partition a HD into four partitions, buy why would you really need to?  The value of even just one extra partition is to have a place (like a closet) to store your "Stuff", away from your OS partition.

 MS gave us a perfect way to further segregate files of different types within a partition.....it's called "Folders".
What a perfectly marvelous invention! :)

For many years I've been building PC's, and NEVER have I EVER set up a new hard drive without creating (just one) an extra partition, for Storage.
Within that second partition, you can set up folders to house files of different types.  
With just one HD, it's a great place to put Ghost Images of C:.
My own Partition #2 is indeed a very busy place. ;)

I keep seeing references to PC-DOS.  Wasn't that IBM's version of a DOS?
It never caught on, for, I'm sure, some very valid reasons.

When I got my first version of Ghost, it installed on my hard drive.
(sound familiar?)  Then it made for me, my first Ghost boot floppy.
Once I had used that floppy, I couldn't understand why or earth I'd ever want to run Ghost form within Windows, since it had to shell out to DOS anyway.  
I promptly removed the installed Ghost files from my HD, thus freeing up some valuable HD space.

I wanted to add some DOS programs to my Ghost boot disk and kept getting "Incorrect Dos Version" messages that just drove me crazy, till I realized that indeed, I was using the "Incorrect Dos Version" for my boot disk.  After some trial and error, and error, and error, I finally settled on a Windows ME boot disk as my home for Ghost.exe.

To overcome the 1.44meg space limitation of the standard floppy disk, I've moved everything to a 64meg flash drive.  With all the extra space, I've been able to add many helpful utilities, like NTFS4DOS and all the Windows ME Utilities, like FDISK, Format and Scandisk.
With "Nero 8" I can easily burn the contents of the flash drive to a CD, thus creating my own Custom Ghost Boot CD, complete with Ansi-Color Menu.  

Of course, to use a Flash Drive for this exercise, you need a motherboard modern enough to be able to boot from a Flash Drive. ::)
(NOT a minor detail!)  ::)
If not.....the Ghost Boot CD works just fine.

For compatibility with Windows Vista, I've recently changed to Ghost 11.5 on my boot disk.  Ghost 2003 was just getting too old.
It just gets betterer and betterer! ;D ;D

Long live Ghost and those really great guys who wrote it!

Cheers Mates!
The Shadow  8-)

Nigel,

I changed two of the Primary partitions back to Logical partitions. Although it now allows the Windows environment of Ghost to boot from Windows into PC-DOS, the latter hangs before presenting the usual PC-DOS menus. The switchout from Windows to PC-DOS is so rapid that I've not been able to read everything in the DOS script that comes up on screen. However, I HAVE been able to see that, in the first line, it says "Couldn't find drive with specified disk identification". Both the main drive and the ext USB drive are actually on, of course.

I made a brand new Bootdisk from this revised arrangement and tried booting from that. It detected the ext drive and installed the mouse driver but the next bit in the sequence, "Loading..", simply stopped. I then tried instead the 793 Bootdisk I made before. That booted me fully into PC-DOS but, there, I found exactly the same problem as I've had all along, these last few weeks - it sees one hard drive or the other but not both.

Can't see where I can go, from here. There's no feature in Ghost itself to RE-mark both hard drives, once they're marked; at present, Ghost in one way is indicating that both drives are marked, and yet, in that DOS preamble, it said "Couldn't find drive with specified disk identification". Am not sure to WHICH drive it's referring.

My gut feeling is that this problem has come about by the ext drive having been marked under Win2K, whereas the main hard drive has been marked under WinXP, or possibly that Ghost simply gets confused by the fact that the main hard drive is identical to the ext USB drive (though their partitioning is quite different) and, for some unknown reason, decides to just display in PC-DOS the ext USB drive (when it's on).

An earlier posting from someone suggested that I use that Roadkil utility to remove the drive IDs, if need be, but there are clearly distinct dangers in using a third-party uitility that modifies one of the boot sectors. If it failed to do the job, I could end up with losing absolutely everything.

BTW, I now see a 26MB VIRTPART.DAT folder in the WinXP root partition.  

voximan wrote on Sep 19^th, 2008 at 10:40am:

Can't see where I can go, from here

The most important thing to try is to see when happens when you start Ghost (either from your boot disk or via the Windows interface) using the -fni switch, to direct Ghost to prefer using the system BIOS over its built-in IDE drivers. This was the first thing suggested in this thread, and it's still the most important thing.


voximan wrote on Sep 19^th, 2008 at 10:40am:

in that DOS preamble, it said "Couldn't find drive with specified disk identification"

That's because the drive marking is relevant only to discriminate which drive is targeted by an operation initiated from the Windows interface, and what I've been saying all along is that the failure is elsewhere.

Ghost is structured much as any student of the art/science of software construction would expect it to be, in the same layered manner as an operating system:
- At the bottom there is a device layer, which deals with things like Firewire and USB and IDE and such (and a fallback to the system BIOS).
- Above that is a layer which interprets disks and disk partitioning schemes (MBR, GPT, Dynamic Disk, EFI) into volumes.
- Above that is a layer which interprets the contents of those volumes as filesystems (FAT, NTFS, ext2/3, etc.)
- Above that is a layer which looks at the contents of files in those filesystems, such as BOOT.INI or the files making up the Windows registry.

All the above occupies the vast bulk of the code; above that is the thin veneer of user interface, the GUI and the textual processing for the command-line control. The code to look for the disk GUID you select in the Windows user interface is a tiny part of that outer veneer, not any part of the core "operating system" in Ghost, and the failures to detect your disks exist in the behaviour of the low-level layers.

The -fni (or -noide) and related switches are what matters rather than the drive marks because they are the things that direct the initialization behaviour of the low-level disk layers - those lower layers of Ghost aren't finding your disk at all, and that's making things go wrong long before the drive marking comes into play (and what are stopping that code finding a disk with the indicated mark, as the error you now have is saying).

Point taken, Nigel, but I just find it strange that Ghost (Windows) sees both drives, before jumping into PC-DOS and then PC-DOS hanging. It's also mighty odd, I'm sure you'll agree, that when I now use a Bootdisk to get into PC-DOS, the latter always recognises the ext drive and not the main drive also, but if I switch off the ext drive, PC-DOS DOES see the main drive. The two drives are identical, as far as overall capacity is concerned. They otherwise differ principally in that one's an internal IDE PATA, but the other is a USB-connected PATA drive.

Since last posting, I've deleted all partitions on the ext drive and then reconstructed them but that's not made a scrap of difference. I've also tried setting the Extended Int13h switch in PC-DOS, in case that's how my BIOS now treats the main drive, but again that made no difference.

I'll try, if I can, the fni or noide switch but I can't see that there's any changed aspect of the new setup of mine that would warrant it. The only set option in PC-DOS in the very original setup of mine was Autoname, and even that was set by default. The major thing that's now different to the original setup is that the capacity of the main drive is bigger (OK, I'm using WinXP now, instead of Win2K, but the evidence suggests that the OS is not a factor in this problem).

Nigel,

I've now specifically tried the fni switch, doing it within PC-DOS Options. This is with both main drive on and ext drive on. This time, the main drive showed, ie. the source drive and its partitions. However, when I passed to the next step, 'File Name to Copy To', only that main drive's partitions were displayed, not the ext drive's partitions. By 'displayed', I mean 'available in the dropdown menu'. So, it's still a case of 'one or the other but not both'.

I've a log file, taken from Ghost, of the attempts I made earlier today to get it all to work and will post it here later. Maybe you'll be able to spot something in it that'll give a clue as to what's wrong.

All the most important log information is in the GHOSTERR.TXT file written by Ghost; if you start Ghost and hit control-C when it's running, that's the easiest way to force it to generate such a file. Do that with -fni, save it, and generate another one without it, so it's possible to compare the two.

During normal operation of Windows, access to the main hard drive is IDE, of course. So, what's the default access in Ghost, then? There's no mention of another access mode, in the manual's description of the switches - it's either IDE access on or IDE access off. The only other hard drive access I know of is PIO, ie. via the CPU.

BTW, when you advise to hit Cntrl C after startup of Ghost, do you mean Windows environment of Ghost or PC-DOS version of Ghost? I can't get anywhere at all with running from the Windows environment, in as much as as soon as PC-DOS starts, it hangs. It's different if I boot straight into PC-DOS, in that I can at least then use its menus.

voximan wrote on Sep 22^nd, 2008 at 4:29pm:

So, what's the default access in Ghost, then?

There isn't really a default as such at all; like Windows when it starts up, Ghost runs through an incredibly complex set of rules to try and figure out what's connected to the machine, and what is the right way to access it, using a large range of methods. As time goes on this has been subject to constant tuning as new API sets or new standards are created, and we discover bugs in implementations (the list of defects we encounter in system firmware is huge and every-expanding as more and more system manufacturers pretty much only test that their firmware is capable of booting Windows).

[ For instance PC-DOS hangs tends to be caused by a couple of common faults in the internal disk code in the system BIOS, which typically overwrite CPU registers they are not supposed to touch (there are two particular bugs we've seen increasingly spread throughout the market as various faulty BIOS code is licensed by various manufacturers). In GSS2.5 it's got to the point where the custom MBR we use to boot with now installs workarounds to prevent these bugs killing PC-DOS, since we don't have a license from IBM to modify it. MS-DOS editions aware of XINT13 contain their own workarounds for these bugs, but alas we cannot license that - Microsoft will not permit it. ]

For instance, there have been at least four different sets of extensions to the various PC BIOS APIs over the years as hard disk capacities have grown; the most common nowadays is a 64-bit LBA-mode one defined by IBM, but this is the code path that also tends to have the faults above as it really only became widely supported in BIOSes after DOS-type operating systems were on the decline.


voximan wrote on Sep 22^nd, 2008 at 4:29pm:

The only other hard drive access I know of is PIO, ie. via the CPU

What you are thinking of here is PIO versus UDMA, which are not opposed to each other, but merely two transfer sub-modes of IDE (more properly called ATA, from the T13 technical committee). In the context of Ghost, "IDE" refers specifically for Ghost's own built-in internal drivers for disk controllers using the ATA standards.

If you disable Ghost's built-in IDE, then it's likely to end up using one of the system BIOS APIs; if it exists, Ghost tries to use the IBM Extended Int13, although due to crippling bugs in many BIOSes there are additional switches to control that too (e.g., -FNX). But Ghost also tries lots of other things, such as the ASPI API set (for SCSI devices and provided by external USB drivers).


voximan wrote on Sep 22^nd, 2008 at 4:29pm:

do you mean Windows environment of Ghost or PC-DOS version of Ghost?

Anytime anyone who works on the product says "Ghost", we mean the cloning executable Ghost.exe (or Ghost32, Ghost64, or the linux version as appropriate). The Windows UI employed in the 'Norton Ghost 2002' and 'Norton Ghost 2003' products is called GhostStart.

Nigel,

Been thinking more and more intensely about this problem and have been reading the users manual extremely carefully. Overnight, I've developed a theory that goes back to something I summised earlier but which could possibly explain the problem I'm getting. That's to say, I think that Ghost, for whatever reason (and maybe it's something to do with the limitations of my BIOS rather than Ghost itself), is only ever detecting one drive.

Now, I suggest that this is happening because my two current drives are, at the lowest physical level, identical. I simply never had this problem when I was using an 80GB drive for the main drive and a 250GB drive for the ext USB drive. Thus, when I now boot into PC-DOS and start the Local>Partition>Image procedure, Ghost only ever displays one drive (and then, in the next screen, its partitions), that drive being the ext USB drive. Thus I'm prevented from going any further because, in this instance, it gives me access only to my destination drive. The converse is true if I switch the ext drive off; then, the source drive and its partitions are provided, but of course, because the ext drive is off, I can't then make an image to the ext drive.

Now, reading the user's manual carefully, it seems to say that the 'preference' for drive access is non-IDE. So, if Ghost is misinterpreting my two drives and seeing only one, the likelihood is that it sees the ext USB-connected one, in preference to the main one. And this is precisely what's happening.

The manual states that there's a command-line switch for telling Ghost the number of hard drives present. It says that this may help if the BIOS doesn't report the number of drives correctly. That switch is -dl=number, where number is 1,2,3 etc.

I think that that switch is worth trying. However, I'm not sure as to exactly how to input a switch specifically from a command line, and what the exact syntax would be as, so far, I've only ever set or unset switches in PC-DOS's Options. In its Options menu, Ghost PC-DOS allows you to set a limited number of options, including those that I've already tried, but the options there are 'tick-a-box' types and unfortunately the option for the detection of the number of drives isn't included.

So, how exactly do I go about setting this particular command line switch? There's a box for adding switches in Advanced Settings in the Windows environment but I've no idea as to the correct and full syntax. In any event, in my case, Windows doesn't fully drop out into PC-DOS; as soon as PC-DOS is entered, it hangs. Thus, it doesn't seem appropriate for me to attempt adding switches in the Windows environment.

Presumably, I can add the switch instead into the DOS line, ie. boot into PC-DOS with my Bootdisk, then select Quit, which would give me:

A:\GHOST>

So, what would I then need to type and do? And how would I then get straight back into the graphical representation of PC-DOS, to see if two drives are then listed and to proceed with the imaging? Would I have to, in fact, reboot for the switch to take effect? The manual says it's crucial to get the syntax correct, as failure to do so could leave the system unusable.

Incidentally, in "-dl= number", I assume that the third character is the lowercase letter 'l', and not the number '1'. Because of the particular font that's used in the manual, it's difficult to distinguish between those two characters.  

voximan

Interesting problem you're having--I doubt it has anything to do with Ghost's *marking* of your HDD's--I doubt it has to do with the two drives being *identical* (I have used *identical* drives both internally and in external USB kits along with the internal HDD's--never an issue.

I think you have been hitting the nail on the head repeatedly--but not actually proceeding to test the problem!!!  The only change you made was adding an internal HDD that went from 80 GB to 250 GB.  

1.  How old is your system?  I know you have stated previously that your system supports large HDD's--but, that may apply more to Windows compatibility than DOS!!!  Manufacturers have been putting less time into making their systems work *well* in DOS vs the Windows environment.

2.  Can you re-install your 80 GB HDD and boot with your floppy Ghost boot disk and see both HDD's as before?

You need to test with a 120 GB HDD and then a 160 GB HDD in place of your 250 GB internal system HDD to see if either of those work.  I suspect the 120 will and the 160 will not!!!

3.  Ghost 2003's Iomega USB DOS driver is *okay*, but has poor broad compatibility.  It's possible that a different USB DOS driver would solve a compatibility problem that introducing a 250 GB HDD has somehow brought on:  A Better USB 2.0 DOS Driver for Ghost + More!

4.  I strongly doubt there is a problem with the Ghost *marking* of the drives--there was one forum member who did have a problem--but it was not seeing his HDD's in the Windows Ghost GUI--and deleting the Ghost *marking* in absolute sector 62 of the Master Boot Record on both drives, and letting Ghost re-*mark* the drives did solve his problem.  I have never had a problem zeroing out that sector 62 and letting Ghost re-*mark* my drives--as Brian has mentioned he has also done as well.

Nigel has mentioned that Ghost's signature marking is not always in sector 62--but for most systems and users, it probably is.  Just make one letter change in the middle of the Ghost signature and it will no longer match its internal check-sum and Ghost will request to re-mark the HDD's.  Couldn't hurt to see if it helps!

If you need a *good read*--here's a long thread about Ghost's marking of the HDD's:  Ghost 2003 build 793 Broken options (NOPtions)




Quote:

Presumably, I can add the switch instead into the DOS line, ie. boot into PC-DOS with my Bootdisk, then select Quit, which would give me: A:\GHOST> So, what would I then need to type and do? And how would I then get straight back into the graphical representation of PC-DOS, to see if two drives are then listed and to proceed with the imaging? Would I have to, in fact, reboot for the switch to take effect?

Yes, select *Quit*--just type the command line at the A:\Ghost> prompt--but, I suspect that switch is for how many internal HDD's you have hooked up--your BIOS probably doesn't even know the external HDD exists--unless your BIOS has built-in USB support--in which case you would have problems if you are also loading a DOS driver in addition to the built-in USB support!  But the command line would be:

Ghost -dl=2    , and then press enter

(That's *Ghost* + a space + -dl=2)


Quote:

Incidentally, in "-dl= number", I assume that the third character is the lowercase letter 'l', and not the number '1'.

I'm pretty sure it's the letter *L*--lower case.

Nightowl,

Many thanks for your advice. You clearly have more knowledge in this area than I do.

My motherboard dates back to 2002. The BIOS it uses is the all-but-one latest, issued in 2003. The very latest differed only in an update to a DOS utility that I've never used. The BIOS DOES support both USB1 and USB2 and is configured accordingly.

When I was using the 80GB HDD as my main drive, Ghost happily booted into PC-DOS and there was never a problem with PC-DOS recognising both drives - the 80GB and the 250GB. Further, at present, PC-DOS recognises the 250GB main drive, but only if the ext USB 250GB drive is off, so I think you'll agree that it's not a problem of DOS itself recognising that size of HDD on my system. That's to say, at present I can make partition images to a reserved partition on the 250GB main drive. What I CAN'T do any longer is to make partition images to the ext 250GB drive.

Unfortunately, I can't test with a 120GB or 160GB main drive, as I don't have to hand any spare HDDs of that kind of size. I've been wondering whether to get another 250GB, to later use as a cloned backup, but PATA HDDs are quite difficult to get now and I keep thinking that it might be a waste of good money. I've been retired some years now and have to watch my spending.

In response to your second question, I can't say for certain (with the very latest changes) whether swapping back to the 80GB drive would make things work but I suspect that it would. I think so, because my cloned-drive 'tryout' that I've mentioned earlier also failed to work in this regard and so I re-fitted my 80GB drive (with the dual-boot of Win2K/WinXP and apps on it) and used that for a month or so, before constructing this latest setup. That physically-restored 80GB arrangement worked. Well, why shouldn't it? If you're suggesting instead that I re-fit the 80GB HDD as a BARE drive, well that'd be a whole new ballgame and would involve some work to get it to a state where it could be legitimately recognised by Ghost. Also, at this stage, I'm not inclined to wipe my 80GB drive, just in case I'm forced in the end to return to using my original dual-boot setup.

I think the thing that should be borne in mind about the oddity of my problem is that, quite clearly, PC-DOS continues to recognise the ext 250GB drive and it also recognises the 250GB main drive, but not when BOTH of them are on. So, it does kinda point to Ghost being the source of the problem, rather than my BIOS or anything else.

It's interesting what you say about the Iomega driver and the USB driver. The Iomega driver definitely gets installed, because I see the relevant onscreen statement in the DOS preamble, as PC-DOS boots. That particular driver has ALWAYS installed. Are you suggesting that, if that's so, NO USB drivers should be selected in Ghost? At present, and I think in the past, I've simply had 'USB1.1' selected in Ghost's "External storage driver settings". All my ports/devices are USB2, except for a USB-connected printer of mine which is USB1 (the printer remains switched off during the imaging process). I've tried the setup on the USB2 setting but that made no difference to the current problem.

Thanks for what you've mentioned of the -dl command line. I need to be absolutely certain of doing that right, so should the line look like this:

A:\GHOST>Ghost -dl=2

or simply:

A:\GHOST> -dl=2

voximan

Firstly--my links in my previous post were for the previous version of this forum--so they did not work--I have fixed those--I've been *offline* for the last 4-5 months and my forum skills are rusty!


Quote:

My motherboard dates back to 2002. The BIOS it uses is the all-but-one latest, issued in 2003. The very latest differed only in an update to a DOS utility that I've never used. The BIOS DOES support both USB1 and USB2 and is configured accordingly.

I suspect we are talking *apples--oranges* here--when I say the BIOS supports USB--I'm referring the newer motherboards that allow you to simply hook up the USB external HDD and boot from it, or access it if booted to DOS and no DOS drivers loaded to have that access!

You can use your USB 1.x and 2.x in Windows--but I'll bet you have no access in DOS unless you load that Iomega driver.  I don't think native BIOS support for USB in DOS was available in 2002!


Quote:

so I think you'll agree that it's not a problem of DOS itself recognising that size of HDD on my system.

Ah, but that's not my point--it's some weird compatibility issue--where when you put PC-DOS, 250 GB internal HDD and external 250 GB HDD, the Iomega USB DOS driver and Ghost all together that you are having a problem.  If you don't test for the possible incompatibilities, you wont get off the dime and find the problem/solution!

Try MS-DOS instead of PC-DOS.  Try the Panasonic USB DOS driver instead of the Iomega driver.  Try removing the Ghost *marking* and let Ghost re-*mark* the HDD's


Quote:

Unfortunately, I can't test with a 120GB or 160GB main drive, as I don't have to hand any spare HDDs of that kind of size.

Talk to friends, neighbors, and/or relatives--beg, borrow, *steal* what you need to do the testing--and then give it back--join a local computer club--someone will help you out--do some social networking!!!


Quote:

That physically-restored 80GB arrangement worked. Well, why shouldn't it?

In deed!  Isn't that the problem we're trying to solve!


Quote:

At present, and I think in the past, I've simply had 'USB1.1' selected in Ghost's "External storage driver settings". All my ports/devices are USB2, except for a USB-connected printer of mine which is USB1 (the printer remains switched off during the imaging process).

USB 2.0 will be 4 to 5 times faster than USB 1.x--so you should use it if you can.  You only have to use USB 1.x if you have other *storage devices* (not printers) attached to the system and powered up that are not USB 2.0.

Also, you mentioned something about electing to not assigning drive letters to external USB devices when creating your boot disks--I think you should have DOS letters assigned!  Maybe this has something to do with it--don't know!

I'm not absolutely sure of this but I seem to recall that, going back some years, when I assigned DOS driveletters, it caused so much confusion (by altering the driveletters from those that existed in Windows) that I ended up wiping out my boot partition when the restore failed. As long as there's any prospect of Ghost assigning different driveletters to those in Windows, I'll not touch that particular option with a bargepole. I've too much to lose!

Going back to something you said earlier, is it completely wrong to see Ghost using an Iomega driver in PC-DOS but having set a USB1 or USB2 driver in the configuring for external USB devices? Or are they one in the same driver?

BTW, you didn't reply to my slightly-more-detailed question about the command line, Nightowl.

The Iomega driver that gets loaded is Iomega ASPI USB-EHCI driver 1.0 v.13, dated 9th May 2003.

I've now tried 'No USB drivers', 'USB 1.1', and 'USB 2.0', but none of them makes any difference to this particular problem. I've also re-tried the setting for Extended Int13eh in PC-DOS's Options (each change requires that I leave the bootdisk in write-enable mode).

By using Options in PC-DOS, I've also tried the -fnx switch (Disable Ext Int13 support).

I'll do another run and then post the log file here.

Here's a logfile of an attempt I've just made to get into PC-DOs via the Windows environment. As far as I can see, you only get a log file produced when you start from the Windows environment.

This is with USB2.0 drivers selected, and with nothing additional added to the command line.

Things have changed slightly. Well, with all the things I've been trying of late, I'm not surprised!

Here, Windows dropped out toward PC-DOS but never made it. The conventional DOS preamble showed, namely that the External drive was installed successfully. But the preamble then simply stopped, with it giving me the choice of either proceeding to PC-DOS or to returning to Windows. However, whichever choice I then made, it responded with 'Bad or missing Command Interpreter'. Thereafter, I could only get back to Windows by doing Cntrl Alt Del.


BackupOperation 0

-- GHOST\GSCRIPT.TXT ----------------------------------------------------------

[BackupOperation]
AlreadyProcessedFile = YES
DestFingerprintParam = c98b6031-aea3-407d-bd12-7787656ebec1
DestPartitionOffsetParam = 63
ExecutionStateParam = ExecutionNotStarted
FileIdParam = 744765
PathParam = \25Sept08.gho
SourceFingerprintParam = 95589659-6a6f-4c70-871e-2f36e49803c8
SourcePartitionOffsetParam = 63
UseImageDescriptionParam = YES
UseLFOParam = YES
WindowsPathParam = G:\25Sept08.gho

[ImageCheckOperation]
AlreadyProcessedFile = YES
DestFingerprintParam = c98b6031-aea3-407d-bd12-7787656ebec1
DestPartitionOffsetParam = 63
ExecutionStateParam = ExecutionNotStarted
FileIdParam = 744765
PathParam = \25Sept08.gho
UseLFOParam = YES
WindowsPathParam = G:\25Sept08.gho

-- AUTOEXEC.BAT ---------------------------------------------------------------

@echo off
SET PATH=C:\GHOST;C:\
SET PROMPT=To return to Windows, type ghreboot and press Enter.$_$p$g
SET TZ=GHO+00:00
if "%CONFIG%" == "WINDOWS" goto WINDOWS
MOUSE.COM
CD \GHOST
GHWRAP.EXE
goto EOF

:WINDOWS
\GHOST\GHREBOOT.EXE

:EOF
-- CONFIG.SYS -----------------------------------------------------------------

[MENU]
menuitem=GHOST,Run Norton Ghost Dos Operation
menuitem=WINDOWS,Return to Windows without running Norton Ghost
menudefault=GHOST,3

[GHOST]
LASTDRIVE=Z
DEVICE = \USB\ASPIEHCI.SYS /int /all

[WINDOWS]

And I've just tried this again, but hitting Cntrl C when the program is opened. Earlier, Nigel suggested trying that. But there's no sign whatever of a Ghosterr.txt file on my hard drive as a result. You'll see that the above file is GScript.txt. Unless I've misunderstood Nigel, the only logfile accessible is the one that the Windows environment produces.

voximan


Quote:

BTW, you didn't reply to my slightly-more-detailed question about the command line, Nightowl.

You type exactly what I indicated after the dos prompt:  so like this  A:\GHOST>Ghost -dl=2

But, you did see this comment?:


Quote:

but, I suspect that switch is for how many internal HDD's you have hooked up--your BIOS probably doesn't even know the external HDD exists

Quote:

I'm not absolutely sure of this but I seem to recall that, going back some years, when I assigned DOS driveletters, it caused so much confusion (by altering the driveletters from those that existed in Windows) that I ended up wiping out my boot partition when the restore failed.

Well, as with any *powerful* program that has the ability to make HDD altering, permanent changes (just like a disk editor, etc.), you need to understand what you are doing and understand the interface--DOS letter assignments can and often will be different than Windows because you can change the drive letters in the newer NT based OS's and they are remembered in the OS's registry--which DOS is totally unaware of!


Quote:

is it completely wrong to see Ghost using an Iomega driver in PC-DOS but having set a USB1 or USB2 driver in the configuring for external USB devices? Or are they one in the same driver?

One and the same--if I understand your question correctly.


Quote:

The Iomega driver that gets loaded is Iomega ASPI USB-EHCI driver 1.0 v.13, dated 9th May 2003

That would be the USB 2.0 DOS driver--the *E* in *EHCI* is for *enhanced* which is the buzz word for USB 2.0.


Quote:

I've also re-tried the setting for Extended Int13eh in PC-DOS's Options (each change requires that I leave the bootdisk in write-enable mode). By using Options in PC-DOS, I've also tried the -fnx switch (Disable Ext Int13 support).

I'm unfamiliar with what you are referring to here--help me out--where do you set PC-DOS Options--and how are you also setting the *-fnx* switch in the *Options in PC-DOS*?


Quote:

And I've just tried this again, but hitting Cntrl C when the program is opened. Earlier, Nigel suggested trying that. But there's no sign whatever of a Ghosterr.txt file on my hard drive as a result. You'll see that the above file is GScript.txt. Unless I've misunderstood Nigel, the only logfile accessible is the one that the Windows environment produces.

You're mixing the two different Ghost GUI's--the Windows vs the DOS version!  The Windows version creates the log file you have posted.  The DOS version will create an error file saved to the directory location that *ghost.exe* is loaded from--so if you run *ghost.exe* from a floppy disk, it will be saved to the directory on the floppy disk that has *ghost.exe* on it.


Quote:

Here, Windows dropped out toward PC-DOS but never made it. The conventional DOS preamble showed, namely that the External drive was installed successfully. But the preamble then simply stopped, with it giving me the choice of either proceeding to PC-DOS or to returning to Windows. However, whichever choice I then made, it responded with 'Bad or missing Command Interpreter'. Thereafter, I could only get back to Windows by doing Cntrl Alt Del.

You got lucky!!!  Many folks get *trapped* in the Ghost *virtual partition* when an incompatibility occurs when switching from Windows to the DOS interface to complete the task set up in Windows!  You can recover from being *trapped*, but you have to use a recovery utility, or if that doesn't work, then edit the Master Boot Record's Partition Table to recover in that case!  Using a DOS floppy boot disk avoids using the Ghost *virtual partition* and the problem can be avoided completely.


Quote:

As long as there's any prospect of Ghost assigning different driveletters to those in Windows, I'll not touch that particular option with a bargepole. I've too much to lose!

Okay--but you don't have to perform any actual procedure with Ghost to test if assigning a drive letter solves your problem--create a new floppy boot disk with the Ghost Boot Wizard, add USB 2.0 support and allow a drive letter to be assigned.  Shut down system, turn on the USB HDD, boot from the floppy--can you see both HDD's now either as source or destination HDD's in the DOS Ghost interface (don't use the Windows Ghost GUI)?

Nightowl,

I'm not trying to be pedantic or awkward but are you absolutely sure you've got the syntax correct for me configuring for two drives? I've been looking through my Ghost 2003 manual and, although there are no directions in it for the general syntax when using command line switches, what I seem to have gleaned is that the syntax should be:

ghost.exe -dl=2

And this assumes you're already in the Ghost directory.

Re the setting of various additional commands via the Options in PC-DOS, here's how to see and change them:

Use the Bootdisk to boot into PC-DOS. At the initial menu in PC-DOS, click on Options (just above Quit, I think). This will open a set of tabbed options in PC-DOS, where for the mostpart you can set/unset the equivalent command-line switches. Of course, it's possible that you might not see anything like this if you're not using Ghost 2003.

Re the error log, yes it dawned on me later that, for PC-DOS, the error log was probably recorded on the bootdisk. I'll have a look for it. The Windows error log remains as is.

Going back to the vageries of my BIOS, my motherboard handbook says that, as well as CHS and LBA mode, it can automatically handle Large mode (more than 1024 cylinders). In Large mode it tricks the BIOS (or other OS) by dividing the no. of cylinders by 2 but, at the same time, multiplying the no. of heads by 2. A reverse transformation is then made inside Int13h in order to access the correct HDD address.

It goes on to state that, if using Auto detect - which is how I'm using it - the BIOS will automatically detect the IDE hard disk mode and set it to one of the three modes.

Further, it says that, to support LBA or Large mode, there's software included in the Award HDD Service Routine (Int13h), but this may fail to access a HDD in Large mode if you're running under an operating system that replaces the whole of Int13h. Well, whether this is the case here, I don't know.

Right, I've made yet another new Bootdisk and have been comparing its contents (in as far as that's possible in much depth) with that of a Win2K bootdisk that I used quite successfully on my original 80GB main/250GB ext setup.

Each bootdisk contains:

GHOST (GHOST.EXE and GHOST.INI)
USB (containing aspiehci.sys)
AUTOEXEC.BAT
COMMAND.COM
CONFIG.SYS
IBMBIO.COM
IBMDOS.COM
MOUSE.COM
MOUSE.INI

Both Ghost.ini's appear to be the same but the Ghost.exe's do differ (I'm judging only from the file sizes). This might be simply because one's made under Win2K, the other under WinXP.

AUTOEXEC.BAT is:

@echo off
SET TZ = GHO+00:00
MOUSE.COM
echo loading ....
CD GHOST
GHOST.EXE

CONFIG.SYS is:

DEVICE = usb\aspiehci.sys /int /all
LASTDRIVE = Z

I managed to get a Notepad output of the contents of Ghost.ini on the new bootdisk:

span(Spanning)                      = N
autoname(AutoName)                  = Y
cns(Old Style Span Extensions)      = N
crcignore(CRC Ignore)               = N
fcr(Create CRC32)                   = N
f32(FAT32 Conversion)               = N
f64(64K FAT Clusters)               = N
fatlimit(FAT Limit)                 = N
sure(Sure)                          = N
fro(Force Cloning)                  = N
rb(Reboot)                          = N
fx(Exit to DOS)                     = N
defaultImg(Default)                 = Y
ia(Image All)                       = N
ib(Image Boot)                      = N
id(Image Disk)                      = N
defaultTape(Default)                = Y
tapesafe(Tape Safe)                 = N
tapebuffered(Tape Buffered)         = N
tapeunbuffered(Tape Unbuffered)     = N
tapeeject(Tape Eject)               = N
ffx(UseExtINT13)                    = N
fnx(DisableExtINT13)                = N
ffi(DirectIDE)                      = N
fni(DisableDirectIDE)               = N
ffs(DirectASPI/SCSI)                = N
fns(DisableDirectASPI/SCSI)         = N
pwd(Prompt for password)            = N
locktype-none(No BIOS lock)         = Y
locktype-M(Manufacturer)            = N
locktype-P(ProductName)             = N
locktype-V(Version)                 = N
locktype-S(SerialNo)                = N
locktype-U(UUID)                    = N
locktype-C(ManProduct)              = N
locktype-I(P3ID)                    = N

I used the newly-made dootdisk to get into PC-DOS and started the procedure for making a Partition-to-Image. At the point where just the one drive then appeared for selection as the source drive (the problem being that PC-DOS should be showing two drives), I pressed Cntrl C. Sure enough, Ghost asked me if I wanted to generate a txt error log. I did so, then quitted Ghost. I've subsequently opened the txt error file and now include it in my next posting (too long to be accommodated in this one).

@ voximan

In DOS, you can drop the *.exe* part of an executable program name--but no harm including it--I assume that's what your concerned about?!

Try it--boot with your boot floppy, quit Ghost, and then type *ghost.exe* and the program should load again.  Then quit again and now type *ghost*--should get the same results.


Quote:

Re the setting of various additional commands via the Options in PC-DOS, here's how to see and change them: Use the Bootdisk to boot into PC-DOS. At the initial menu in PC-DOS, click on Options (just above Quit, I think). This will open a set of tabbed options in PC-DOS, where for the mostpart you can set/unset the equivalent command-line switches. Of course, it's possible that you might not see anything like this if you're not using Ghost 2003.

Ah--okay!  You're talking about the Ghost floppy boot disk that *automatically* executes the DOS Ghost program as part of the loading process!

PC-DOS is an *operating system--a competitor to Microsoft's MS-DOS.  You boot into an operating system which then allows you to *run* programs.  *Ghost.exe* is a program that runs under a DOS operating system--either PC-DOS or MS-DOS or Free-DOS, etc.

I know I'm talking *semantics*, but as you well know, computers are not very forgiving at being *almost correct*!

So, you are not *at the initial menu in PC-DOS*--you are at the *main screen* of the Ghost GUI (Graphical User Interface), or Ghost program, if you will.

And clicking on Options does not *open a set of tabbed options in PC-DOS*--it opens a set of tabbed options for the Ghost program.

You can set options for PC-DOS (and MS-DOS, etc.), but those are separate issues from setting options for a program that's run under the OS environment, such as Ghost.

I think you have inadvertently substituted *PC-DOS* for *DOS based Ghost Program*--which is not accurate and looking back has made understanding what you are referencing difficult to follow!

Enough said on that!


Quote:

Going back to the vageries of my BIOS, my motherboard handbook says that, as well as CHS and LBA mode, it can automatically handle Large mode (more than 1024 cylinders). In Large mode it tricks the BIOS (or other OS) by dividing the no. of cylinders by 2 but, at the same time, multiplying the no. of heads by 2. A reverse transformation is then made inside Int13h in order to access the correct HDD address.

I'm not questioning that your system's BIOS supports large HDD's--what I said is there appears to be an incompatibility on your system when you combine a 250 GB internal HDD, a DOS based driver program (Iomega) to make a Windows based storage system (USB HDD) able to be seen in a DOS OS with a large 250 GB capacity HDD, while running a DOS based program in a DOS OS.  So far, the main variable that changed is the size of the internal HDD!!!!!  

Where the incompatibility lies is undetermined until other testing is done.

Here's the error log. Of course, this may or may not show any problem - because PC-DOS certainly doesn't think there's a problem!

*********************************
Date   : Fri Sep 26 14:56:40 2008
Error Number: (36002)
Message: User Abort
Version: 2003.793 (Dec 17 2003, Build=793)
Command line arguments:
Active Switches :
      AutoName
ProgMode            : PROG_LOCAL
PathName            :
DumpFile            :
DumpPos             : 0
File64 buffersize   : 0
FlagImplode         : 0
FlagExplode         : 0

Operation Details :
 Total size.........0
 MB copied..........0
 MB remaining.......0
 Percent complete...0%
 Speed..............0MB/min
 Time elapsed.......0:00  
 Time remaining.....0:00  

Program Call Stack
Generic_Abort
userInterrupt
PaintDisplayDriveData
CopyPartToFile
CopyMainline
AttemptOperation
sub_main
main

Call Stack
 0x0023f3c7
 0x0006b29f
 0x0006a54c
 0x0006a3c1
 0x0006bae3
 0x000079bd
 0x0005c03a
 0x00007a40
 0x0001d752
 0x0002bca8
 0x000022ec
 0x000023f3
 0x00004426
 0x0000370b
 0x0024cac8
End Call Stack


Start heap available: 1067909120
Cur   heap available: 1067646976
Total Memory:         1072627712

Conventional Memory
Inital Conventional Memory Size = 404464
Current Conventional Memory Size = 330512
Allocated
  1024 DpmiDjgpp.cpp:59
 33504 ghost.cpp:913
  2048 IdeDmaServerPci.cpp:132
   528 IdeDmaServerPci.cpp:132
  2048 AspiAdapterDos.cpp:87
   176 AspiAdapterDos.cpp:88
    32 DiskDriveAccessExInt13.cpp:107
Free
    16 MsdosFile.cpp:92
    80 AspiServerDos.cpp:103
   512 DiskDriveAccessInt13.cpp:181
  1024 AspiAdapterDos.cpp:323
 32768 AspiAdapterDos.cpp:323

Fat details:

NTFS details:
----------------

NTFS Global Flags:
----------------
      contiguousWrite=1 forceDiskClusterMapping=0
      inhibitCHKDSK=1 ignoreBadLog=0 ignoreCHKDSKBit=0
      enable_cache=0 xfrbuflen=0
      last_attr_type = 0
      loadExact = 0
----------------

Disk Info :
 remote.............0
 drive..............0
 sectors_used.......487476297
 estimated_used.....29889664
 pemax..............3
 Version............0

# Ord Boot Id Ext First    Num      Last     Used     NTFS
0   0    0 7  No  00000063 125949537 125949600 00135912 Yes
1   1    0 7  No  125949600 315805770 441755370 23553824 Yes
2   2    0 7  No  441755370 45720990 487476360 06199928 Yes

Disk Info :
 remote.............0
 drive..............0
 sectors_used.......0
 estimated_used.....0
 pemax..............0
 Version............0

# Ord Boot Id Ext First    Num      Last     Used     NTFS

Drive 128 Seagate External Drive

Int 13h
Total Sectors     16434495
Bytes per Sector  512
MB                8024
Cylinders         1023
Heads             255
Sectors per Track 63

Extended Int 13h
Total Sectors     488397168
Bytes per Sector  512
MB                238475

ASPI (Active)
Total Sectors     488397168
Bytes per Sector  512
MB                238475

Remote Drives
AsyncIo : 0
Image Devices

Key      A:
Path     A:
Desc    
Type     Floppy

Key      @LFO1:1
Path     1:1
Desc     [BKDP IMAGES]
Type     NTFS
Disk     0
Offset   63

Key      @LFO1:2
Path     1:2
Desc     [BKDP AUDVIS]
Type     NTFS
Disk     0
Offset   125949600

Key      @LFO1:3
Path     1:3
Desc     [BKDP FILES]
Type     NTFS
Disk     0
Offset   441755370

Key      @CD-R1
Path     @CD-R1
Desc     TOSHIBA DVD-ROM SD-M1612
Type     CD

Key      @CD-R2
Path     @CD-R2
Desc     _NEC    DVD_RW ND-3550A
Type     DVD


*********************************

Nightowl,

Apologies for some wrong assumptions of mine, regarding the nature of PC-DOS and the actual ghost.exe. I don't profess to be an expert in that area, so a miscomprehension on my part obviously got the wires crossed a bit. Clearly, you do now understand what I was pointing out.

Just one small but important point. You seem to think that the problem is basically that Ghost doesn't see my EXT drive. Well, that's not the case. As I've been constantly stating, the opposite is true - when wishing to do a Partition-to-Image (main drive partition, to a partition on the ext drive), Ghost displays only the EXT drive for selection! Nevertheless Ghost can, and does, at other times recognise and display the main hard drive of the PC (the one I need to choose as the source drive), but only if the ext drive is off! That's to say, Ghost is refusing at all times to display BOTH drives for choosing; it only ever displays one drive. Thus, either way, I can't make a partition image from my main hard drive to the ext drive. Do understand that I can make a partition image from my boot partition to another partition on the main drive - which kinda suggests that essentially the main drive isn't posing a problem for Ghost in respect of large disk size.

I'm not sure if this helps at all but here's one for Nigel. My BIOS gives the 250GB PATA main drive as:

Capacity              250GB

Cylinder               65535
Head                    16
Precomp               0
Landing Zone        65534
Sector                  255

@ voximan

Looking at your Ghost error log--am I correct that you had the 250 GB internal HDD in the system, and you had the external USB HDD hooked up and turned on--and the only HDD listed in that error text is the external USB HDD?

Is the USB HDD a 128 (?) GB HDD--the error text lists it as *Drive 128 Seagate External Drive*?

Is it partitioned into three partitions?

Are all partitions NTFS?

@ voximan


Quote:

Just one small but important point. You seem to think that the problem is basically that Ghost doesn't see my EXT drive. Well, that's not the case.

What gives you the idea that I think Ghost does not see your EXT drive?  I have understood your description from the beginning--if both drives are hooked up and powered on--only one drive shows up in the DOS Ghost interface!

Actually, it's the *Internal* HDD that is not showing up--if you have the EXT HDD hooked up and powered on--if I understand your descriptions correctly--it's not the EXT HDD that is not showing up!

I quote:


Quote:

what I said is there appears to be an incompatibility on your system when you combine a 250 GB internal HDD, a DOS based driver program (Iomega) to make a Windows based storage system (USB HDD) able to be seen in a DOS OS with a large 250 GB capacity HDD, while running a DOS based program in a DOS OS

Well, to answer that, Nightowl, is difficult, because I've absolutely no idea what all that guff up to "Drive 128 Seagate External Drive" is. But yes, BOTH the main (internal IDE) drive and the ext drive were on at the time of me doing an error dump, though as I've explained, Ghost doesn't realise that it's actually in error at the time. When you go to choose the source drive, it simply displays only the ext drive (and then, in the next step, the ext drive's partitions).

The Seagate drive to which you refer is indeed the ext drive. I happen to use a Seagate drive also as the internal IDE one, so they're all but identical, except for the fact that the external one incorporates a USB interface. The internal one has one more partition and its partition names are different to those of the ext drive.

So, yes, I guess "Drive 128 Seagate External Drive" is referring to the ext drive, though I've no idea what "128" refers to. (We shouldn't jump to conclusions). Pretty much everything following that, in the error log, is to do with the ext drive's partitions, of which there are three (1:1, 1:2, 1:3). All partitions are NTFS, whether on the PC or ext to it. You'll see the names of the ext partitions there, that I've given them when I created them (Desc). The last two main entries refer to my two IDE CD/DVD drives.

@ voximan


Quote:

The Seagate drive to which you refer is indeed the ext drive. I happen to use a Seagate drive also as the internal IDE one, so they're all but identical, except for the fact that the external one incorporates a USB interface

So.....how big is the Seagate HDD in the external USB unit?

250GB, the same size as the HDD I'm using as my main drive.

What about the VIRTPART.DAT folder that's in my root partition? I've determined that it's around 26MB in size, but is it possible to see its contents? Does VIRTPART.DAT get overwritten each time an image is made or attempted?

@ voximan

VIRTPART.DAT=*virtual partition data*--it's the set up info when you run Ghost from the Windows Ghost GUI.

You can not *read* anything in that file--it's computer code gibberish--you can delete it and it will be re-created next time you do a Windows based set up of a Ghost procedure--or it will be over-written when you do a new Windows based Ghost set up.

@ voximan

Okay, we have a Ghost DOS error text for when you have the 250 GB internal HDD hooked up and the external HDD hooked up and powered on--and the internal HDD is not detected properly.

Let's get some test results with the setup that does work:

Power down.  Remove the 250 GB internal HDD and replace it with your 80 GB HDD on the primary IDE cable as Master.

Hook up your USB HDD and power it on.  Boot with your Ghost floppy boot disk.  (Do not boot from the 80 GB HDD to Windows--just boot to DOS!)

Make sure you can see both the 80 GB HDD and the external USB HDD in DOS Ghost as either source or destination for a Ghost procedure.

Then do the *ctrl-c* to generate a new error text that will have the info about how Ghost is handling the internal and external HDD correctly!

Post the error text results here.

Replace the 80 GB HDD with the 250 GB HDD and reboot to Windows.

After these results, I'll suggest the next possible one or two tests.

Just tried the -dl=2 switch. It made no difference.

Running with the 80GB HDD is going to require some dismantling of the PC and, for various reasons, that'll take me a bit of time. A fair amount of work will be involved, as the PC is installed under a desk and will need to be changed in situ.

In the meantime, I thought it was worth seeing if Ghost would generate an error log for the situation where the two 250GB HDDs were in use but where the ext one was switched off. Well, you never know what clues you might pick up! I made a fresh bootdisk and booted into Ghost. Sure enough, the correct drive was shown, together with its partitions. But not unexpectedly, Cntrl C didn't cause a log to be generated under these conditions. Instead, I simply got User Abort, and was returned to the Ghost directory in the DOS line. What this does at least show is that, in the previous test, where both drives were on, Ghost definitely acknowledged the fact that it found only the ext drive and thus generated a log when I pressed Cntrl C. The trouble is that it showed no measured parameters for the missing drive, so provided us with no clues!

I've no expertise in interpreting much of what's in the error logs, but in the one that I've generated so far, it looks to me like the ext drive is being accessed via Extended Int13h. Right? If that's the case, then the question is Why doesn't Ghost succeed in simultaneously accessing the main (internal) drive? After all, the two drives are, at the lowest hardware level, all but identical.

I'm a little concerned that swapping to the 80GB/250GB arrangement will not get us anywhere, because it rather looks as though Ghost will deem everything as fine (which it will be) and therefore not (as above) generate an error log when I press Cntrl C.

Still with the two 250GB HDDs, I've just tried 'Assign Driveletters', during the setting up of a new bootdisk. When I ran the bootdisk, the ext drive was successfully detected as usual, but the next two DOS lines said:

Finding a drive letter for your Iomega drive.
No drive letters were added.

The preamble went on to its usual conclusion. No driveletters were shown in the subsequent graphics and, again, only the ext drive was made available.

@ voximan


Quote:

Running with the 80GB HDD is going to require some dismantling of the PC and, for various reasons, that'll take me a bit of time. A fair amount of work will be involved, as the PC is installed under a desk and will need to be changed in situ.

Well....for testing purposes, I would temporarily set up some sort of desk or table next to your normal desk that gives you easy access and some extra space next to the open side of the case, place the computer case on that temp desk, route the cables to your monitor, mouse and keyboard.

Next to the open side of the case, I pile up books or small blocks of wood to act as a base to place my bare HDD's on.  I then disconnect the power cords, and communication ribbons from any mounted HDD(s), remove the HDD(s) from the case and place it on the books or boards.  Route the power cord and comm cable from the case and reconnect the power cord and comm ribbon to that HDD(s).  If I'm adding a second HDD to that comm ribbon, I place a thin, narrow board on top of the first HDD so air can still circulate around some of the HDD's top, and then stack the second HDD on top--connecting the power cords and comm cables as needed.  Now I can reconfigure the HDD arrangement at will and quickly--changing from master to slave positions--adding and removing components as needed.

Just be careful not to bump the running HDDs--always make cord changes when the system is shut down--if you move the HDDs when running, that could cause the heads to potentially contact the platters if the torque is too much and cause damage--but I've done this for years without a mishap--but your comfort level may vary!

@ voximan


Quote:

Still with the two 250GB HDDs, I've just tried 'Assign Driveletters', during the setting up of a new bootdisk. When I ran the bootdisk, the ext drive was successfully detected as usual, but the next two DOS lines said: Finding a drive letter for your Iomega drive. No drive letters were added.

Because you have only NTFS partitions, you will never get a DOS drive letter assigned--DOS is not NTFS aware, and will ignore those partitions.  But DOS Ghost2003 is NTFS aware and able to see those partitions in the Ghost interface--they will be listed by a drive number and partition number--not a DOS drive letter--so like this:  1:1, 1:2, 2:1, 2:2, 2:3, etc.

@ voximan

Back to your previous post:


Quote:

In the meantime, I thought it was worth seeing if Ghost would generate an error log for the situation where the two 250GB HDDs were in use but where the ext one was switched off. Well, you never know what clues you might pick up!

Indeed!!!  I really can't tell you why Ghost has failed to generate an appropriate error log text--maybe you have to delete the previous one if you didn't already--but you said you were using a *fresh boot disk*--so I presume there was no previous log anyway.

And, I can not explain why the internal 250 GB shows up in the Ghost interface, but then Ghost can not report how it's communicating with that 250 GB HDD--but, my gut feeling is that the 250 GB HDD connected to your system is not completely compatible--so, yes it's seen--but there are compatibility issues--and that's causing weird results.  In part, that's why I'm suggesting we go back to the 80 GB HDD to see what does work correctly!

Here's another suggestion--how are you setting the Master/Slave setting on your HDD--are you using the manual pin selection method--or are you using *Cable Select*.  Regardless, try the other way to see if that makes a difference!  If using *Cable Select*, the end connector on the comm ribbon should be the Master position, and the middle connector should be the Slave position--you need to use the Master connector to the boot drive on most older systems.

@ voximan


Quote:

I've no expertise in interpreting much of what's in the error logs, but in the one that I've generated so far, it looks to me like the ext drive is being accessed via Extended Int13h. Right?

I don't know--I don't have that level of understanding regarding HDD access!


Quote:

If that's the case, then the question is Why doesn't Ghost succeed in simultaneously accessing the main (internal) drive? After all, the two drives are, at the lowest hardware level, all but identical.

The HDDs might be *all but identical*--but the communication level between HDD and the motherboard is very different!  The external HDD is first being translated by the internal circuits of the external USB enclosure.  It is then being transferred to the USB controller on the motherboard that adds its translations.  And then the DOS Iomega driver is interpreting the USB controller and passing it onto the Ghost program!!!  So much different pathway than your IDE controller on the motherboard with the motherboard BIOS doing the controlling!

@ voximan

Regarding my comment in my reply #59,


Quote:

Here's another suggestion--how are you setting the Master/Slave setting on your HDD--are you using the manual pin selection method--or are you using *Cable Select*.  Regardless, try the other way to see if that makes a difference!  If using *Cable Select*, the end connector on the comm ribbon should be the Master position, and the middle connector should be the Slave position--you need to use the Master connector to the boot drive on most older systems.

something I forgot to include:  Over the last couple years, several forum posters have indicated that using *cable select* solved several problems they had accessing their HDDs--don't know if that will have any bearing on your problem.

Finally, one of the reasons I suggested setting up your system so you could easily add and remove components while testing is that I was going to suggest you put both your 80 GB HDD and your 250 GB HDD on the primary IDE comm cable, boot to DOS Ghost and see if they both show up correctly, or not--to see if it is the USB external HDD that is causing the problem vs is it the presence of the 250 GB HDD that makes thing go haywire.  I was going to suggest you try both configurations where the 80 GB is master and the 250 GB is slave--and then flip it around so the 250 GB is master and the 80 GB is slave!

Right, I've been busy! Swapping back to the 80GB/250GB arrangement didn't help in the slightest, I'm afraid. Ghost simply didn't produce an error log. As I mentioned earlier, it seems that Ghost will only produce an error log if it deems there's a genuine error and, of course, in the case of the 80GB/250Gb arrangement, or where the 250GB main IDE drive is being used on its own, there's no error - because it works. It was worth a try, anyway. I'm now back with the 250GB/250GB arrangement.

Incidentally, I double-checked everything concerning the IDE cable and the jumpers. Being a hardware person, I'm usually meticulous about such things. Cable Select made no difference, either.

In the GHost user's manual, I also found a reference to a "full diagnostic statistics dump". Apparently, this includes the detected HDD's geometry details and other Ghost statistics. This particular dump is the file Ghststat.txt and, in the exe you can direct the dump to a specified location. I tried the very example it gave, namely:

ghost.exe -dd -dfile=c:\diagnose\log.txt

but it didn't work. As soon as it ran, Ghost produced "Error opening c:\diagnose\log.txt. Stats not dumped". Maybe this is meant only for the Windows environment; it didn't make that clear.

It rather looks as though Ghost will only ever produce an error log of any kind if an actual error condition is flagged by Ghost - which I suppose is logical. The non-production of a log seems to be the case whether there's actually no genuine error there, or where an error condition does exist but, for whatever reason, Ghost ignores it. You can't actually force Ghost to produce a log, irrespective of what goes on.

I've also played around further with the Ghost options - the IDE/no IDE access and Use ExtInt13h/don't use ExtiInt13h - using various permutations but, again, to no avail.

It's not that Ghost is not acknowledging the 250GB IDE drive per se, because (if I turn off the ext drive) I can make a partition image entirely within the 250GB IDE drive (From C: to, say, partition F:). So, Ghost must be accessing the 250GB IDE drive quite automatically and comfortably in that situation. The problem arises if I try to do the same thing, or similar, with the ext drive on. So, it appears to be some weird cancelling effect that's going on, between the ext drive and the internal drive. And yes, I well appreciate the different interfaces, and therefore paths, through which the USB access and IDE access respectively pass.

I'm resigned to having to do without imaging to my ext drive, as I think we've chased this one about as far as it'll go. This will be a great shame and will make things awkward for me, as far as failsafe, or near-failsafe, backup goes. I'll have to contend with just imaging within the internal drive. Unfortunately, that won't safeguard me in the event that the drive eventually catastrophically malfunctions (unlikely, but it's worth planning for that event). That being so, I'm seriously considering buying a second 250GB IDE drive, to use for cloning. The only snag with that, though, is that I've no idea whether it'll work, whether I'll have a similar access problem. It could be £50 down the drain. With my original 80GB/80GB disk cloning, I had no problem.

Oh, thanks for informing me about Ghost's assigning of driveletters. Makes sense now.

Over the last couple years, several forum posters have indicated that using *cable select* solved several problems they had accessing their HDDs--don't know if that will have any bearing on your problem

I'd be interested to know in which context those forum posters were having problems. Was it just that access to their HDD was barred per se, or did it only happen when they were using Ghost and trying to select it as one of two or more drives?

I have tried Cable Select but it made no difference. Interestingly, the inscriptions on my 80GB Seagate IDE drives advise to use Cable Select when using an Ultra ATA cable. And it says to also set the BIOS to LBA (probably okay for 80GB but not for 250GB). I do use an Ultra ATA cable, a high-quality rounded one, actually. And I am using the HDD on the master (black connector) end. There's no Slave HDD in use on the Primary IDE channel.

I'll see if I can get in touch with Seagate, to see what they have to say about this access problem in Ghost.

Nightowl,

I think you might have raised an important point, namely the jumpering of the HDD. Using Cable Select, in preference to Master, on the old 80GB drive made no difference to the operation of the PC as a whole or to Ghost - everything worked fine. So, hitherto I've been using the main IDE drive (be it the 80GB drive or the 250GB drive) with it jumpered to Master, the traditional way in which I've always jumpered my boot drive.

However, I've now been digging deep on the Seagate website and have discovered that, for this 250GB IDE drive, Master is NOT recommended when an Ultra DMA cable is in use and when the DMA rate is above 33MB/s. Instead, Cable Select is most definitely recommended.

I've not yet tried Cable Select on the 250GB drive, so later today I'll make the change and give it a go. I've a feeling that this might do the trick.

Have now tried the 250GB drive on Cable Select. Unfortunately, it DIDN'T do the trick. I've tried it with all permutations of -ffi, -ffx, -fni, etc.

Ah well, you can't win 'em all.

I have two Enhanced USB Controllers in my system, one an Embedded controller, the other being part of a USB add-on PCI card. The ext USB drive is connected into the port of the Embedded one.

The USB 2.0 driver files associated with these are driver v.5.1.2600, dated 1/6/2002. These were installed automatically by Service Pack 3 for WinXP. Can someone confirm that these are indeed the most up-to-date USB 2.0 drivers?

@ voximan


Quote:

Ghost simply didn't produce an error log. As I mentioned earlier, it seems that Ghost will only produce an error log if it deems there's a genuine error and, of course, in the case of the 80GB/250Gb arrangement, or where the 250GB main IDE drive is being used on its own, there's no error - because it works.

So, I booted to DOS and ran Ghost.exe on my system that works fine--I do get a *GHOSTERR.TXT*, but there was no useful information--not sure what that's all about!  Note--in your situation with the 250/250 GB arrangement--you are having an *error* as far as you are concerned--the HDD goes missing--but, Ghost is not reporting an actual error--just doesn't appear to *see* the missing HDD--so I'm not sure if Ghost thinks there's any *error* at all!


Quote:

In the GHost user's manual, I also found a reference to a "full diagnostic statistics dump". Apparently, this includes the detected HDD's geometry details and other Ghost statistics. This particular dump is the file Ghststat.txt and, in the exe you can direct the dump to a specified location. I tried the very example it gave, namely: ghost.exe -dd -dfile=c:\diagnose\log.txt but it didn't work. As soon as it ran, Ghost produced "Error opening c:\diagnose\log.txt. Stats not dumped". Maybe this is meant only for the Windows environment; it didn't make that clear.

Not a Windows error report--it is for DOS!  But, remember, you are using NTFS partitions and a *C* partition does not exist on your system--so, although Ghost 2003 can see NTFS partitions, and actually read and write Ghost image from/to them--Ghost is programed only to write its error logs to DOS file systems.

So, change:

ghost.exe -dd -dfile=c:\diagnose\log.txt

to:

ghost.exe -dd -dfile=A:\log.txt

If you want to put the log in the sub-directory *diagnose*--then you would have to create that sub-directory on the floppy disk before you boot to DOS so it exists and Ghost finds it!

It could turn out that the log file might be too large to fit on the boot floppy disk with all the other files on there!--and I don't know exactly when that file is created in the process--you might have to have a blank formatted floppy available and when the time comes--remove the Ghost boot disk and put in the empty floppy to receive the log file--but Ghost might need the *ghost.exe* file available to perform this operation--so might want to put on a spare floppy the sub-directory *ghost* and put *ghost.exe* in that sub-directory--but leave all the other boot files off the floppy so there's room for the log file--boot to DOS with the standard Ghost boot disk, quit Ghost and restart it by typing the above command ghost.exe -dd -dfile=A:\log.txt--but before pressing *Enter*, pop out the boot disk and place the spare floppy in the A: drive--now hit enter and see what happens.

@ voximan


Quote:

With my original 80GB/80GB disk cloning, I had no problem.

Is this a *typo*?!  Or do you have an 80GB USB external HDD also?


Quote:

I'm resigned to having to do without imaging to my ext drive, as I think we've chased this one about as far as it'll go. This will be a great shame and will make things awkward for me, as far as failsafe, or near-failsafe, backup goes. I'll have to contend with just imaging within the internal drive. Unfortunately, that won't safeguard me in the event that the drive eventually catastrophically malfunctions (unlikely, but it's worth planning for that event). That being so, I'm seriously considering buying a second 250GB IDE drive, to use for cloning.

Actually, most folks find it much faster to do there Ghost procedures between internal HDDs rather than to an external USB HDD.  What I have are two internal HDD's--the first is for my Windows OS, and other files.  And the second is for my Ghost backup images.  If the first one fails, I replace it and restore the image from the backup HDD to the new replacement.  If the second fails, I've only lost the backup files--I simply replace it and create a new backup!

And, I occasionally copy a backup image file to an external HDD for safe keeping should a major system melt down occurs where both internal HDDs are fried!

On my system, creating a ghost image backup is between 2-3 times faster than to an external USB HDD!


Quote:

I have two Enhanced USB Controllers in my system, one an Embedded controller, the other being part of a USB add-on PCI card. The ext USB drive is connected into the port of the Embedded one.

Yikes!!!  The devil is always in the details!!!  The Ghost Iomega DOS USB driver is not widely compatible with a large number of USB peripherals--if it works--great, but often times it doesn't--especially with newer USB components--might work fine with an integrated USB controller--but might not with an add on controller!!

Try removing that add-on PCI USB controller from the system and see if that makes a difference!


Quote:

The USB 2.0 driver files associated with these are driver v.5.1.2600, dated 1/6/2002. These were installed automatically by Service Pack 3 for WinXP. Can someone confirm that these are indeed the most up-to-date USB 2.0 drivers?

The Windows USB drivers have nothing to do with what happens in DOS using Ghost--it's only the Iomega DOS USB drivers that are at work--or some other DOS USB driver such as the Panasonic DOS USB driver I mentioned previously--which seems to be the *best*, most universally compatible DOS USB driver!--there are a couple others--but in general they have not worked well for me.

First of all, I'm not going to delete any of my USB Controllers. I'm not aiming to deliberately screw up my system, especially as I've got no backup of it at present.

The reason I have two Enhanced USB Controllers is simply because there's, on the one hand, an Embedded Bus of the PC (giving me just two USB ports) and, on the other hand, a further five USB ports furnished by way of a PCI USB card. There's nothing odd about that. It's just two separate hubs, if you like. I've been using it for years, especially with the former 80GB/250GB dual-boot setup.

Just to clarify something. When I mentioned '80GB/80GB cloning', I meant precisely that - cloning the contents of an 80GB internal drive to a second 80GB HDD, the latter which was then kept aside as a longstop backup. Get me? No, I've never had an 80GB ext USB drive.

I might, when I've time, try dumping that error log to the floppy(s), as you've described. I also intend setting up a dummy HDD cloning session, using one of my former 80GB HDDs as the destination drive, just to see if Ghost then shows both HDDs. On my caddy setup, I can do that fairly readily. In other words, there'll be two HDDs on the Primary IDE interface. Not sure if Ghost will object to it, though, as clearly the 80GB will be of smaller capacity than the source drive. And no, after all the chopping-and-changing of drives I've already done, I'm not going to swap drives around as sources/destinations yet again! Actually, I'm all but ready to abandon ever finding a solution to this problem, as the narrowing evidence suggests that it's caused by a strange driver issue, about which I can do nothing, it seems. I don't think the problem's my BIOS, because if I switch off the ext USB drive, Ghost sees my internal IDE one. It's as if Symantec has engineered an exclusive-or of my two drives!

 

@ voximan


Quote:

I'm all but ready to abandon ever finding a solution to this problem

Hey--your system!  Your choices!

I wish you well!

From some further observations I've made today, I'm pretty convinced that the problem's caused by that Iomega driver. By trying non-embedded USB slots on the PC, I've discovered that it's possible to have the ext drive on and running, the Iomega driver apparently installed, but the ext drive NOT detected. When I then attempt a Partition-to-Image, the main IDE drive IS shown (and its partitions). But, of course, this time, the ext drive isn't shown.

Thus, as long as the ext drive is (for whatever reason) NOT detected by Ghost, the main drive WILL show in Ghost. But if the ext drive IS detected by Ghost, the main drive will NOT show.

Understandably, it sounds a bit like an IRQ problem. However, the IRQs of the main drive and USB connections are miles apart in their allocated numbers, and therefore don't share.

When one program won't work.....Try another!

I have an old PC, with an Asrock mobo and two SATA1 HD's (internal).
Ghost 11.5 absolutely does NOT want to read (access) those drives.
However, Ghost 2003 works just fine.  Go Figure!

Read the forum on NON Ghost Backup Programs.

There's always an alternative, to almost everything. ;)

Just like Divorce is a great alternative to a bad marriage! ;) ;D ;D ;D

Cheers Maties!
The Shadow  8-)

TheShadow,

I have to admit I've almost reached the point where I can do no more, as regards Ghost 2003. This is a pity, since Ghost 2003 has previously worked fine on this machine. The difference now is that the main IDE HDD I'm using is a bigger capacity one and, instead of a dual-boot of 2K and XP (where I ran Ghost 2003 from the 2K partition), I'm now using just XP. The Ghost 2003 application is installed from the very same CD as before but the full update of this new incarnation, to Build 793, has come about via the Archived Symantec Server and so there's no way of knowing whether all the Ghost files, etc are exactly the same as they were some years ago.

As for alternative applications, well, there might be one or two little-known ones out there that'd prove suitable. However, as far as the big names like Acronis and the like are concerned, none of those offer partition-to-partition imaging, they give you only full disk cloning/imaging.

(where I ran Ghost 2003 from the 2K partition),

Now, that bothers me......
With the 121,693 words that I've personally written about ONLY booting Ghost 2003 from a removable media, there's still people out there in the hinterlands that insist on running Ghost 2003 from their hard drive?
It boggles my mind to comprehend............ :(

Make your Ghost 2003 boot disk, either a floppy disk or CD and then DELETE Ghost off of your Hard drive, forever.
Then you can even Ghost a HD that won't boot, or even a data disk with no OS on it at all.  Do you see my point?  
Ghost on a hard drive is next to worthless.

Later,
8-)

PS:  I hate it when I've nothing to do.....I wind up re-reading old threads.
I noticed a discussion on PCI-USB, working or not working with Ghost.
  I personally like to run ghost with my mouse.  But.....my USB mouse would not work on my PCI-USB2.0 card, but works fine if I plug it directly into my motherboard USB port.  I just remembered that the PCI card depends on drivers in Windows to operate at all.  NOT in DOS!
So I just plug my USB mouse into the motherboard USB port and VOILA, it works in DOS with Ghost 2003.  I've not tried it yet, but I suspect that my powered USB hub will work equally well when plugged directly into the motherboard and not the PCI-USB card.

I further suspect, that any external USB drive, plugged into a PCI-USB card may not be seen by Ghost, running in DOS.  Most of those cards were designed to only run in Windows and NOT in DOS.
Most new printers will likewise only run under Windows.

Just a thought!

OK, I shamed myself into it.............Now, I feel like a parent that's just done his kids homework for him. ;) ;D ;D ;D

I decided to verify my hypothesis, from my last post.
I broke out my two external hard drives....
# one a 40 gig laptop drive in an unpowered "AirLink 101" external enclosure and....
# two, a 40 gig IDE Desktop drive in a Powered "AirLink 101" External Enclosure.

I've used both drives for backups in the past so I was sure that they both worked OK.

I first tried the laptop drive in a PCI-USB card port and Ghost 2003 never even saw it.  I then plugged it into a motherboard USB port and Ghost saw it and wrote to it with NO problems and NO special drivers or switches being used.  (I never use them)

Then, I did a similar test using the desktop drive in a Powered External Enclosure and got the same results.  It DID NOT work from the PCI-USB port and worked just fine from the motherboard USB port.

I did notice a huge speed difference between the two drives.
The laptop drive was accepting data at about 25MB/min and the desktop drive started off at 80MB/min and dropped some as the backup proceeded.

I hope this will help someone who's been trying to get Ghost to backup to a USB External HD, using a PCI-USB add-on card. (Forgetaboutit!!! )
Those cards have to be Driven by Windows and are virtually dead to DOS.

There, homework done!  I hope I get a good grade. ::)
An Apple for the teacher? ;)

Cheers Mates and Happy Computing!
The Old Shadow  8-)

I've just done a dummy Local>Disk>Disk, using my Bootdisk. That is, using my main 250GB IDE HDD and my old 80GB IDE HDD as destination disk, with the 250GB ext USB HDD switched off. Both IDE internal drives were detected and displayed by Ghost in PC-DOS. I checked also that, under these circumstances, their respective partitions were displayed. They were.

Conclusion:

There is NO problem of my BIOS recognising my drives, or of Ghost recognising my drives per se.

My problem all along MUST be being caused by the Iomega driver that's automatically loaded by Ghost, when Ghost detects that the ext USB drive is on. Somehow, that Iomega driver is not then allowing Ghost to display the main internal IDE HDD.