Ghost has... given up the ghost.

November 14, 2006 6:44 PM

Copied hard drive won't let me log on!

Here's the situation: I used Norton Ghost to do a direct hard drive copy to move all of my data to a bigger hard drive (2 partitions). After doing this, I shut down the computer, put the new hard drive on the old drive's IDE position, and reboot. Windows XP gets all the way past the boot screen, and stops at the XP splash screen - XP logo, but no logon options.

I've found numerous forums online about this, but none of the solutions seem to work! I've copied the primary partition without giving the new partition a drive letter, hoping the master boot record would do it for me. I've used Windows recovery tools to run fixmbr and fixboot. Nothing seems to work.

Any suggestions?

posted by backseatpilot to Computers & Internet (16 answers total)

Yarg. This exact same problem happened to me in my then-vain attempts to repair some computers at school. I actually talked to Norton about this and they attributed it to a problem with drivers not being directed correctly. They also didn't have a solution for it (nor have I come up with one).

My only solution at the time was making sure the important data was copied on an extra HD, reformat the original one, and start from scratch.
posted by jmd82 at 7:22 PM on November 14, 2006

First thing to find out: does your computer still boot if you remove your new big drive and put everything back the way it was with your original drive?

If it does, I'll take you through the steps for using a Linux live-CD to build up your new drive in a way that's pretty much guaranteed to work.
posted by flabdablet at 7:35 PM on November 14, 2006

This is related but doesn't answer/fix your problem since you cant get to the logon screen unfortunately. I'm sorry I dont know the answer to your question directly.
------------
I used Norton Ghost at work, not only did it disable ALL the logon ID's for the PC, it also would no longer connect to the network. I ended up using a hack tool to reset the Administrator password to get on, it was a major pain in the butt. But I did learn something, I will NEVER Ghost a PC again.

the hack tool I used was hard to use, crashed a few times and required a floppy drive. but I got it to work once, that's all I needed.
http://home.eunet.no/~pnordahl/ntpasswd/
posted by BillsR100 at 7:38 PM on November 14, 2006

Response by poster: Luckily, my computer does still work if I replace the old drive. I used the drive copy feature of Ghost, instead of making an image.

I found a potential fix that involves going into the registry and editing the mounteddevices\dosdrives keys, but I'm a bit leery of screwing with that... If I mess up, then the old hard drive won't work anymore, either.
posted by backseatpilot at 7:42 PM on November 14, 2006

If you're going to change drives like that, you may want to look into the use of Microsoft's Sysprep tool. It can put Windows into a state where it will redetect all your hardware on reboot, installing drivers as needed. I use this at work to build hardware independent images that we can use on all our various configurations, but it's just as useful for single system "moves" like this.

Basically you'd just execute it, check that you want it to run mini setup on reboot and let it shut down when it's done. Then proceed with Ghost. When you boot up it should run through hardware detection and set everything up relatively automatically.

The latest version of Sysprep (I presume you're running SP2) can be downloaded here. A Google search will turn up more information on moving a drive using Sysprep than you could possibly imagine.

Alternatively (on preview, as odinsdream is pointing out) you could boot from a Windows CD and do a repair installation, but in my experience this usually necessitates reinstallation of a lot of your software since Windows just sort of brute forces itself back into working order. Sysprep should leave all your applications and settings intact.
posted by JaredSeth at 8:50 PM on November 14, 2006

Bills: I have a better password hacker than that which boots from floppy and have used successfully numerous times in similar situations, but it's at work. I will try & remember to post it tomorrow.
posted by jmd82 at 8:51 PM on November 14, 2006

You don't need any new drivers just for a new IDE disk drive. If you make a block-for-block copy of your old IDE drive on your new IDE drive, and then replace your old IDE drive with your new IDE drive (making sure all the jumpers are set the same on your new drive as they were on the old drive) then Windows will boot just fine. It will then detect your new drive as new hardware and tell you that you have to reboot; but that's just Windows being overzealous.

You don't need to fix anything or reinstall anything or change anything or sysprep anything. You just need to make a block-for-block copy of your old drive onto your new one.

The most likely reason Ghost hasn't done this for you is because Ghost has tried to be clever. If you cable up both drives, then boot a Linux live CD, then use the dd command to copy all blocks from your old drive to your new one, all will be well.

This will probably take far less time than fartarsing around with sysprep and/or a repair install, too.
posted by flabdablet at 9:06 PM on November 14, 2006

Flabdablet, I'd be interested in your method of using a Linux Live CD to rebuild a drive.

I currently use an Acronis solution, but I'd love to have an open-source option.

I've had this problem with Ghost in the past as well, and many others. That's why I'm not using Ghost anymore.
posted by SlyBevel at 9:10 PM on November 14, 2006

Oh, was that just it? Grrrr....Beat me by 4 minutes.
posted by SlyBevel at 9:52 PM on November 14, 2006

The most likely reason Ghost hasn't done this for you is because Ghost has tried to be clever. If you cable up both drives, then boot a Linux live CD, then use the dd command to copy all blocks from your old drive to your new one, all will be well.

That’s my experience too. You need to be extra extra super sure that the dd command you hit enter to is the dd command you want to call though. Getting the arguments the wrong way round will overwrite the original drive with the broken one, which would be bad.
posted by Aidan Kehoe at 12:37 AM on November 15, 2006

Response by poster: Considering the drive seems to have copied just fine (well, except for the no logon bit), is it possible to boot from a CD and just change the drive letters? The new drive has two partitions, F and H. Would it work to boot a Knoppix CD with only the new drive installed and change the drive letters to C and D?
posted by backseatpilot at 6:26 AM on November 15, 2006

@aidan Kehoe
is absolutely right about DD, be careful. Have you checked boot.ini?
posted by bloodniece at 9:20 AM on November 15, 2006

To use Linux to do drive imaging and copying, you need to understand how Linux names disk devices, and you need to understand a little about how disks are generally laid out.

The primary master IDE drive is /dev/hda; primary slave is /dev/hdb; secondary master is /dev/hdc; secondary slave is /dev/hdd.

If you've got SCSI, SATA or USB drives, these will generally be named /dev/sda, /dev/sdb etc. It's a bit of a toss-up which drive gets which name, so you need to be sure you know which is which. I'll explain a method for doing that later on.

Each partition on a hard drive also gets its own device name, formed by appending the partition number to the disk device name. So the first partition on /dev/hda would be /dev/hda1, the third partition on /dev/sdb would be /dev/sdb3, and so on.

The usual way to define disk partitions is with a partition table on block 0 of the disk, called the Master Boot Record or MBR. This is eventually going to get superseded by the GPT scheme. I've never had to deal with GPT yet and don't know much about it, so this explanation will assume MBR.

Disk partitions, by convention, start on a track boundary and end on a cylinder boundary. To work out where those are, you need to know the sectors-per-track and tracks-per-cylinder ("number of heads") values assumed by the partition table's creator. Modern disk drives don't have a fixed number of blocks per track or cylinder, so these values get picked pretty much arbitrarily. Sectors per track is usually 63. Tracks per cylinder is usually 255 (if the partition table was created by DOS, Windows or Linux kernels 2.4 and earlier) or 16; I have seen 240 on occasion.

The first block on a track boundary after the MBR, and hence the first block that can be part of the first partition, is generally block 63. The 62 blocks between the MBR and the first partition are often used to hold boot loader code. Windows NT does this, as does GRUB. If you're copying partitions onto a new drive and you fail to copy the 62 "spare" blocks as well, you won't be able to boot off the new disk.

The main tools I use for imaging and copying disks are sfdisk, dd, partimage and ntfsclone.

Some recipes:

To find out what hard disk devices are present and what, if anything, is in their partition tables:

sfdisk --dump

On my laptop, which currently has a hard disk, a DVD reader and a USB stick plugged in, this produces the following output:

# partition table of /dev/hda
unit: sectors

/dev/hda1 : start= 63, size= 2097585, Id=82
/dev/hda2 : start= 2097648, size= 76042512, Id=83
/dev/hda3 : start= 0, size= 0, Id= 0
/dev/hda4 : start= 0, size= 0, Id= 0
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start= 32, size= 984032, Id= 6, bootable
/dev/sda2 : start= 0, size= 0, Id= 0
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0

Checking the partition sizes reassures me that my main hard disk is /dev/hda and my thumb drive is /dev/sda.

To back up the first 63 blocks of my main hard disk (which includes the MBR and boot loader code) to a file:

dd if=/dev/hda of=/path/to/backup/file bs=512 count=63

To restore those blocks to a new hard drive connected as the IDE primary slave:

dd if=/path/to/backup/file of=/dev/hdb
sfdisk --re-read /dev/hdb

This form of sfdisk makes Linux re-read the partition table that's just been copied to /dev/hdb. In most modern distros, the new /dev/hdbX partition devices will be created as needed.

To copy the entirety of the primary master IDE drive, including the MBR, boot loader and all partitions, to the primary slave:

dd if=/dev/hda of=/dev/hdb bs=1M

To make and restore compressed images of any disk partition:

partimage

and follow the screen prompts. You need to know what all your device names are before you start, and if you're restoring images, the target drive must already have a suitable partition table.

To make a compressed image of the primary master disk, assuming it's formatted with a single NTFS partition for Windows XP:

disk=/dev/hda
part=/dev/hda1
image=/path/to/image/file
{
dd if="$disk" bs=512 count=63
ntfsclone --save-image --output - "$part"
} | gzip -9 >"$image"

This makes a single image file that consists of a verbatim copy of the first 63 blocks of the disk drive immediately followed by an ntfsclone image of its first partition, all compressed with gzip.

To restore an image made as above onto a totally fresh disk connected as the secondary master:

disk=/dev/hdc
part=/dev/hdc1
image=/path/to/image/file
zcat "$image" | {
dd of="$disk" bs=512 count=63
sfdisk --re-read "$disk"
ntfsclone --restore-image --overwrite "$part" -
}

Because I do a fair bit of Windows disk imaging, and I don't want to type all that crap every time, I keep the last two recipes (along with a bit of prompting for sanity checks) as scripts: snapshot makes an image, and revert applies an image to a disk.

The distro I generally use for all this stuff is the Trinity Rescue Kit, which includes all of the above tools plus support for mounting CIFS shares so I can put my image files on a Windows network server. So to re-image a machine whose image I'd saved on the server, I'd boot the TRK CD on the target machine, and enter the following commands:

mount -t cifs -o user=Administrator //curricserver/images /mnt0
/mnt0/revert /dev/hda /mnt0/image.saved.previously

where "revert" is a script based on the last recipe above.

I like using this stuff a hell of a lot more than I like using Ghost, because

* I understand exactly what it's doing
* I can mess with all the bits to make them do pretty much anything I want
* It's all free (as in speech and beer) software
* It works on machines without a boot floppy
* It works on networks without PXE support
* It only screws my disks up if I tell it to :-)

I'd be happy to help anybody who wants more info. Email's in my profile.
posted by flabdablet at 2:03 PM on November 15, 2006 [2 favorites]

Aidan Kehoe: the nice thing about dd's rather peculiar if= and of= argument syntax is that it makes getting things the wrong way round a bit harder. That said, I agree: you really do need to know which device is which before you start. That's why sfdisk --dump is handy.

To be extra super duper sure, you could cable up just the new drive, leaving the old working one disconnected, then boot your live CD and wipe out the MBR on the new drive with

dd if=/dev/zero of=/dev/hda bs=512 count=1

then shut down, cable up both drives, reboot and do

sfdisk --dump

which would show you a zeroed partition table for the new drive and some defined partitions on the old one.

backseatpilot: assignment of drive letters to partitions is something Windows does, not something inherent in the partitions themselves. If Windows is calling your new partitions F and H, it seems likely to me that this is because you've booted Windows off the old drive at least once with the new drive also cabled in, and Windows has recognized the new drive and assigned drive letters to a couple of its partitions. This happens in the registry - there will be an entry under HKLM\System\CurrentControlSet\enum\pci\ide (don't take that as gospel, I'm working from memory) for the new hard drive that defines what drive letters are assigned to it.

This might actually bollix things up if you do as I've suggested and boot off a block-for-block clone of the old drive. Windows might recognize the new drive by vendor ID and part number partway through booting, decide that what it thought was C: should now be F:, and suddenly become unable to find anything. In fact, this might even be what's messing up your booting at present.

Editing the registry is not for the faint-hearted, and that goes double for editing it with Linux-based tools.

If I were in your position, I would proceed as follows:

1. Make sure you can still boot if the old drive is the only one connected.

2. Make a block-for-block copy of the old drive onto the new one using dd, as I described above.

3. Try booting the machine with only the new drive connected. If this works, hooray! If it doesn't, come back here and we'll talk registry-munging.
posted by flabdablet at 2:22 PM on November 15, 2006

Something quick to try, though, before you start climbing any kind of Linux learning curve: make sure the only drive in your machine is the busted Ghosted one, then try method 5 from this Microsoft KB article.
posted by flabdablet at 5:18 PM on November 15, 2006

Response by poster: Fixed! I am now running off of a new 250 gig hard drive, without having to use a Linux CD.

The problem seems to be with Norton Ghost. It doesn't really like making bootable partitions. The solution? Arconis True Image.

The configuration was a breeze; after setting some things (like the fact I wanted a bootable drive), it went and did its thing - rebooted the machine (instead of trying to copy the drive from Windows, like Ghost), ran for about 30 minutes, and told me at the end to swap the hard drives. Everything automagically worked.

Best part - 15 day free, unrestricted trial.

Thanks for all the suggestions. They may come in handy later if I screw up my machine again.
posted by backseatpilot at 6:26 PM on November 15, 2006