lightminute

Quote:


Well....it's probably not Ghost--but WinXP and the fact that the second drive was on the system already.  It probably has to do with WinXP having identified the HDD's previously and is 'remembering' their respective positions and where the boot files were located.  Unlike Win9x, WinMe and DOS,--- WinXP allows you to assign drive letters that are 'sticky'--it does not re-assign letters based on changing the 'position' of the hard drives on various controllers.

If I'm right, these references should help:

http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=10949...

http://www.goodells.net/multiboot/notes.htm#04

http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=10956...

Quote:

Since I am a nut about Partition Magic 8.0, I am able to interpret this statement a minimum of four ways:
1)  the second HDD had available space for a partition upfront, but the partition had yet to be formally created (the only way that it could truly be blank or vacant);

2)  the second HDD was formatted NTFS across the board with a primary active partition upfront without evident content, and an extended partition trailing with three logical drives therein;

3)  the second HDD had a primary active partition upfront formatted NTFS lacking evident content, and an extended partition trailing with three logical drives therein with a mix of NTFS and FAT32 file system formats; and

4)  the second HDD had multiple primary active partitions and the first one lacked evident content, with the trailing partitions being a mix of NTFS and FAT32 file system formats.

I could go on and on, but I won't.  However, I am quite intrigued by your project and would like to have more details - along with the final resolution and how you got there.

Pescador, I hope this will clear it up: On this slave drive, I had four partitions. The first partition I left blank for my "emergency boot" purposes. It IS formatted NTFS but I don't think it really matters with Ghost since restoring an image formats accordingly (...I'm pretty sure). In leaving it blank, I just meant I didn't put any files there. When I use the Disk Manager view in the XP console, it is the furthest left partition - simulating the main/first physical drive's "C:" position where the OS resides. Since you've brought this up, I'm wondering if there's fault in this logic. From what you've said, it isn't "truly" blank because it's more than a space, it IS a drive because it has a drive letter and I can put files there. So to answer your question, the "blank space" is the primary active partition, NTFS, assigned a drive letter with no content, followed by an extended partition containing three logical drives, all NTFS. 

Owl, what you summarized in your first paragraph is correct. You make an interesting point regarding the fact that I'm putting an image from the OS on a hard drive with a different partition structure onto a different hard drive with a different structure. I thought that putting that image on the first partition where "C:" would be and then installing that drive as a master would just allow it to boot. Now what you said previsouly about the drive letters being sticky clearly becomes a problem.

As far as what you said about cloning to the replacement drive - there are a couple reasons why I don't do this. One is because, as you said, cloning an entire hard drive will replace the entire hard drive, partitions and all. In the "worse case scenario" I had, my primary OS drive would fail and I would move the slave into the master position, restore the image (stored on that same drive), and be on my way (in a perfect world ). So that's what I meant by my attempts being a "normal" method of restoring Windows.

As I saw it, my primary OS drive kicked the bucket (in theory). My good working image of it resides in one of the latter partitions of my secondary drive. Since the first partition of this second drive is "open", I simply remove the dead drive, move the slave into the master's position, restore the OS image to the first open/active partition and I'm done! In the initial post, however, I did this a little differently because my primary hard drive didn't actually fail. So while everything was up and running fine, I went ahead a restored the OS image to the primary partition of my slave AND THEN switched the slave to the master partition. Now, I can see the error in that with your point about the drive letters. However, in my troubleshooting I didn't do this again. I simply cleared the first partition of the slave drive again, powered off, removed the primary drive containing the OS (simulating it's failure) and put the slave into master's position. Now, obviously the system won't boot because the new primary drive is empty... but the presence of only one drive now (even if it was once the slave) should cause Windows to assign the first partition as "C:", shouldn't it? Then, I should be able to use the Ghost DOS boot to restore the image and be ok. This is where I'm at now with the problems.

Now, the information you put in one of your last paragraphs is LOADED. I'm a fairly certain the answer lies in there. Most significant is how you described the "X,Y, and Z" partitions formerly on the slave HD1 now residing on HD0. Not withstanding what I mentioned earlier about how I thought XP would re-assign "C:" to the "new" drive (slave as master), I don't know how it would react to the additional drive letters. I guess I had originally thought XP would see all the drives/partitions as new (since the slave is now the master) and re-assign all the drive letters accordingly. This may be the problem...   more on my troubleshooting results when I get home later tonight (day 6?)

Yes! I've seen these - at times on the other drives I've formatted in the Disk Management console. The "RECYCLER" I've definitely seen more than the others. "System Volume Information" I haven't seen as much ... but "WUTemp" deals with Windows Updates, doesn't it?

Nevertheless, I usually delete these files  .

Pescador,

I've seen nothing in your comments but the intent to help and maybe learn a little more.

I could have sworn, however, that I was able to delete the Recycler folder everytime I saw it. I hated seeing it because I had just formatted my drive and thought it should be empty. I'll have to see if it was just hidden...

As for my problem, I figured out how to fix it LATE last night. So late I wasn't able to keep my eyes open to post the details. i will do that later tonight. The answer was in the contents of one of the links that NightOwl gave me. Although I had already read them, his posting a link to them caused me to re-read them more thoroughly. Thanks, Owl.

For now, I can tell you it WAS a drive letter problem. You have to use the command "fdisk /mbr" to clear the drive letter memory and all will be ok. More later...

I have to apologize for the great delay. I had a lot busier end of the week than I would have liked.

Anyway, one of the links provided by Owl shows what is called "Kawecki's Trick". Basically, they say that when you clone (not image) to a new hard drive, you should NOT have the old hard drive in with the new one.

Quoting: "The proper way to use these utilities is to install both HDDs, boot from floppy disk, do the copying, remove the original HDD, and boot the new HDD. You don't want to let XP see the new HDD before doing the copy, and you don't want the new XP to see the old XP the first time it boots up. Many people who complain of problems with cloning utilities have made one of these two mistakes."

As a remedy if you have made this mistake, they say to use the command fdisk/mbr. This will clear the memory of the drive letters and clear up the confusion the OS on the new drive/partition is having with the other ones present.

Also, another quote which may be important if you're doing anything along these lines: "Note the "fixmbr" command from the XP recovery console may seem to be similar, but in fact will not invalidate previous drive letter assignments.".

Now, though this worked, it has some important implications (for me, at least). One, is that with my setup (the common 2 hard drive system- OS on C: of the main drive, backup images to a partition on the second drive AND seperate partition of the first drive) you have to be careful of how you restore your OS. On a daily basis, as long as your drives haven't physically failed, you can restore from another partition on either drive with no problem.

Now, if your master drive fails, you can put in a new one and should be able to restore with no problem. One potential one, however, is whether or not you'd need to partition that master drive like the original one that failed. This is because when XP does boot up anew on the new drive, it should look for the other partitions on the master drive it remembers. I don't know if this will lead to boot failure or if it will simply adapt.

Another strange situation would be if your secondary drive failed, leading you to take it out. Intially, there's no problem because you simply remove the drive and XP notices. My question now is if, once that second drive is removed, if you happen to restore the OS (with the image backup on another partition of the master drive), will XP go nutty on bootup because the original image "knows" there should be a second drive with other partitions? Or will it be no different than removing the second hard drive and booting up on a normal day because after the restoration XP is essentially just being rebooted?

Lastly, and I think the most important implication of the whole thread is the scenario in which you primary drive fails and you have no other drive aside from your slave with the backup images of your OS on it and an "empty" partition. This is essentially what I had so much trouble with. You cannot simply remove the master, and install the slave as a master to restore your OS image. You have to use the "fdisk/mbr" command or else the computer will hang because XP is now on a different drive letter and it's looking for "C:".

Thanks for the help! Learned a lot about this... I guess 4-5 days of troubleshooting is good if it makes you prepared for a "worst case scenario".