So many questions.......

And just one answer:

SET TZ=GHO+00:00 sets your time zone (TZ) to 00.00 which means you're setting on the time line that runs thru England.

If you were in the eastern US, for instance, it should read:
SET TZ=GHO-05:00

That whole line is superfluous to the problem you're having.

I can only suspect it's all going back to your bios, not properly reporting to Ghost what it sees connected to your computer.

'Luck

But...........is it necessary for Ghost 2003 being run from a floppy disk?

I've always left it IN, just for GP.

But I believe I've also taken it out with no problems.

What do you find?

One of the confusions I'm having to endure at present is that, over the years and especially of late, I've acquired several versions of bootdisk that I've made. This has not made my disc recognition problem in the DOS environment of Ghost 2003 easy to investigate. For the more recent bootdisks, made under WinXP, I have also Build 775 and 793 versions. Running all of these last night on my now WinXP system, I discovered that not only does a different Iomega driver load, depending on the version, but also the disk recognition problem sometimes reversed. That is, when trying to image my root partition on the main drive to the ext drive (Partition > Image), in one case the main drive was not recognised, in the other case the ext drive was not recognised - and that was with the ext drive switched on in both cases. This is a new piece of evidence which strongly suggests that recognition of BOTH drives by Ghost in PC-DOS is critically influenced by the version of the Iomega driver. Indeed, Nigel Bree, our Symantec man, has revealed elsewhere in these forums that Symantec played around and changed the Iomega driver some years ago. Also, I can't quite put my finger on it but I've a suspicion that updating to Build 793 using the Symantec Archival Server is not always successful, and may not have been in MY case - yes, the application gets left with the label 'Build 793' but possibly files end up either corrupted or missing and consequently when you make a bootdisk, you end up making a useless one.

This is probably stating the obvious, but the version of aspiehci.sys that one sees (either by way of the onscreen DOS script or by doing a Properties on the file) depends on when the bootdisk was made and which Build of the application is in force. For instance, I have a bootdisk that I used to use on my old dualboot system and which was made under Win2K. With that bootdisk, the Build was 793, having been updated at a time when the standard LiveUpdate server was still operational. It worked perfectly, albeit that, at that time, I was using a smaller capacity main drive than now; there was never a disk recognition problem. On that bootdisk, the 'modified' date of the aspiehci.sys is 28th May 2003 and the size is 52,106 bytes.

I now need to repeat the analysis of my bootdisk files I did last night, so that I can demonstrate to you how this driver changes according to Build, etc. The impression I'm getting is that, rather than my BIOS being at fault, the problem lies in that Iomega driver and possibly also the lack of GUEST.EXE in some instances (though I'm not sure that GUEST.EXE is actually needed because, in PC-DOS, driveletters per se are, by default, not used). Of course, what actually gets transferred to the bootdisk depends on the options you choose when making the bootdisk, ie. whether USB1.1 or USB2.0 support. I assume that aspiehci.sys is the USB2.0 version (enhanced).

 voximan

Quote:

Nope--didn't mean that at all--meant just what I said--I've never excluded it from my boot files.  Reason being--all my USB external HDD's have at least a DOS FAT partition, and usually a NTFS partition as well--so I always want a DOS letter assigned to the DOS partition--and you have to have *guest.exe* (or other similar program) to assign a DOS drive letter if you want access to the USB DOS partition when booting to DOS.

If my USB HDD is off or disconnected, then those DOS boot files simply give an error message that a usable partition was not found--and it proceeds to continue the boot process.

Been thinking about your statement that you see the *guest.exe* on some boot disks and not on others--I played around with the Ghost Boot Wizard--and you can demonstrate why that's happening--it all depends on whether you leave the default check where it says *assign DOS drive letters* when you select which USB DOS driver in the initial setup steps.  If you do, when you get to the last step before creating the floppy disk, you get a summary of what the wizard will be placing on the disk--if you elected to *assign* DOS letters, the wizard includes *guest.exe*, and if you have unchecked that, then *guest.exe* will not be included--try it and you'll see!

I've now made and run that further bootdisk. Although putting guest.exe on it by opting for assignment of driveletters, it made no difference to my particular problem. Only the ext drive was visible.

I disagree, The aspiehci.sys driver I'm using is the same one that's worked with this very same USB drive before and which is the same driver as various people in these forums are successfully using. The problem, in my case, is not the recognition by Ghost of my ext USB, it's the non-recognition of my main IDE drive, so it's not a USB driver that appears to be at fault.