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.

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?

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

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:

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:

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.

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

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

You can unmark and then re-mark the drives.

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

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

Quote:

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

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.

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