Cloned XP Professional boot partition - and lost the login prompt

[Tim Staddon]

Hi,

Before I go on, I'd like to point out I'm MCSA certified, and I have
deployed Windows 2000 and XP in corporate environments using RIS, Unattended
AND 3rd party imaging tools like Zenworks, Ghost and DriveImage.

I have a Seagate 60GB hard disk which has failed its SMART test and is
rapidly filling up with bad sectors. Thankfully, the 16GB boot partition
(FAT32) is secure enough at the moment to copy across to another drive, and
the other partitions (for data) are backed up. This is a development / test
machine, not networked, and is running XP Professional with the Service Pack
2 pre-release installed.

Like I've done a thousand times before, I booted into DOS, and cloned the
active boot partition to a new hard drive (a Samsung) using Norton Ghost,
and did a bitwise comparison of the partition on both drives. It did copy
OK. I've checked the boot sector - fine.

When I take the old HDD out and set the new one as primary, it boots to the
OS menu okay. DOS sees the same C drive as it did with the old disk - a 16GB
FAT32 partition containing a bunch of apps and a Windows directory for XP
Pro.

XP boots OK, however the user list never appears on the blue GUI screen.
CTRL-ALT-DEL doesn't do anything either.
I get the same thing when I select Last Known Good, Safe Mode, Safe Mode
with Networking, and Safe Mode Command Prompt.

I've cloned the drive a second time, this time using Partition Magic 8, and
AGAIN it's copied fine, verified OK, but still the same problem.

The swapfile is definitely copying over OK - I've hardcoded XP to use a
swapfile of 128MB, it's located on the FAT32 partition.

The ONLY thing that's changed in the system, is the hard drive, so AFAIK
there should be no issue whatsoever in doing a forensic clone of the boot
partition from the old HDD to its replacement.

So, I'm wondering if Device Manager is fixated on the fact that the boot
partition is located on a Seagate disk. Could that be the reason why ONLY XP
seems to have a tough time? In which case, what's the simplest way to force
it to recognise that the boot drive is now a Samsung?

If I'm lucky I can copy it across a couple more times before the Seagate
gives out completely, so any suggestions would be gratefully received.

 

[Tim]

Hi,

First thing I would do is suspect without reason SP2.
Have you checked the SP2 beta newsgroups?

All else you detail seems sensible - except the use of FAT32, but you may
have a good reason for that.

So, try an uninstall of SP2 - I hope you have RC1 in and not a prior
version - then try the clone.
If you follow this path, then you may wish to do a thorough test of the
system before comitting to using it again as the uninstall of SP2 prior to
RC1 was less than perfect. Hopefully RC1 has this fixed.

An alternative would be to do a repair of the failing installation.
Obviously this will put the system back to the SP level of the repair CD
which my be SP none or SP1. If you do this don't forget all the udpates and
critical updates you will have applied.

If none of that works then I suggest you write off your experience to being
a beta tester and keep this in mind in the future.

- Tim

 

[Tim Staddon]

It's FAT32 because I need to boot into DOS to run certain applications.

I have seen this happen before on machines without SP2, however I have
posted a comment to the beta forum just on the off chance it is a bug either
with the OS or with the Service Pack.

The Windows 2000 platform's been around for five years now and despite all
the advancements made to PNP in that time, ISTM that there's been no
improvement whatsoever to the laborious task of migrating your OS onto a new
hard disk.

Given it has to be one of the most common system upgrades (after RAM), and
is quite often an essential part of a disaster recovery strategy, you would
think more effort would be spent making sure that Windows can resolve such a
fairly simple change without the need to faff around with the boot sector,
swapfile etc.

I'm not expecting Microsoft to kill off the 3rd party market here, but it
would be so nice for one to use a 3rd party imaging tool to clone the hard
disk AND have Windows figure out for itself that it's been moved to a new
disk.

And that's just IDE to IDE, never mind SATA or SCSI!

 

[Pegasus \(MVP\)]

It's FAT32 because I need to boot into DOS to run certain applications.

That's the tail wagging the dog. If you have to boot into DOS
then you should use a third-party boot manager such as
XOSL instead of sticking to FAT32 for your system partition.

<snip>

 

[Tim Staddon]

Pegasus,

The added security of NTFS is, for the most part, totally inappropriate FOR
THIS MACHINE - for my others, which are networked, I do make full use of
NTFS, EFS and a comprehensive backup strategy on the system volume.

I take on various development projects for people, which include such things
as replacing old, bespoke DOS-based applications (some, for example, are
written in DBASE, but I also work with Turbo BASIC applications, serial port
comms tools and so on) where no source code exists, with new Windows-based
versions.

In some cases, restructuring the whole database isn't possible (or the
client doesn't want me to do it), so I might decide instead to emulate the
DOS front end from within VB, simply updating the GUI and retaining the
existing database.

Because of the non-relational way many DOS-based databases were designed in
the first place, I often need to be able to run the original software just
to see how the user interface worked, and get a feel of how they processed
the data.

With very few exceptions, I can tweak them enough to get them to work on
FAT32, and then I'm in a position to save screendumps and so on, from within
XP itself. And hence, compare the development project side-by-side with the
functionality of the original. However, to maximize compatibility, it has a
FAT32 C drive, doesn't have dynamic volumes, and is not RAIDed. So I can
boot to DOS if necessary.

Versatility and compatibility, as far as this PC is concerned, are far more
important than security.

I do have an old Pentium 133 with a 250MB FAT16 hard disk available for
anything that cannot be run on this PC. So far I haven't needed to use it.

 

[Tim]

Hi,

I did say " but you may have a good reason for that." - you are obviously
more than aware of the pitfalls of fat32 va. the benefits of NTFS - you show
that this has more benefits to you and that was the sole intent on my
raising the topic so that is moot.

Interesting line of work. I tend to write only new systems so have a
requirement for Win9x compatiblity or later and that requirement is
thankfuly reducing.

Let us know how you get on.

Personally I would do the repair install on the new HDD - its a no brainer
and it otherwise works. It may be prudent to use a fresh restore of the
image before trying as a booted image that results in a crash may damage
this image. In this case the repair install has little to do with changing
the HDD, but all to do with having SP2 beta in.

But please do note that using a beta product on a production machine that is
obviously an essential part of your business is advised against.

- Tim

 

[Tim Staddon]

Hi,

Here's a funny one for you...

I booted to Windows 98 command prompt and did an FDISK/MBR.

Problem solved. No idea why it worked, but it did!

 

[I'm Dan]

Here's a funny one for you...

I booted to Windows 98 command prompt and did an FDISK/MBR.

Problem solved. No idea why it worked, but it did!

Ah, yes -- the Kawecki trick. See www.goodells.net/multiboot/notes.htm#03
for an explanation.

 

[shmthaus]

Go to device mgr and set the hdd to generic and do
setupmgr and sysprep again.

Have tried this for processor, hdd and other devices when
trying to setup an image to use on different pc
configurations.

 

[Guest]

Hi,

Before I go on, I'd like to point out I'm MCSA certified, and I have
deployed Windows 2000 and XP in corporate environments using RIS, Unattended
AND 3rd party imaging tools like Zenworks, Ghost and DriveImage.

First of all certification means nothing at all, experience does.

I have a Seagate 60GB hard disk which has failed its SMART test and is
rapidly filling up with bad sectors. Thankfully, the 16GB boot partition
(FAT32) is secure enough at the moment to copy across to another drive, and
the other partitions (for data) are backed up. This is a development / test
machine, not networked, and is running XP Professional with the Service Pack
2 pre-release installed.

Like I've done a thousand times before, I booted into DOS, and cloned the
active boot partition to a new hard drive (a Samsung) using Norton Ghost,
and did a bitwise comparison of the partition on both drives. It did copy
OK. I've checked the boot sector - fine.

If you have a failed cluster the same cluster would be empty on the cloned partition i.e. a bitwise comparison would be passed.

A clone is of course made before system failure and tested on a similar system to ensure that the image actually works properly!

When I take the old HDD out and set the new one as primary, it boots to the
OS menu okay. DOS sees the same C drive as it did with the old disk - a 16GB
FAT32 partition containing a bunch of apps and a Windows directory for XP
Pro.

XP boots OK, however the user list never appears on the blue GUI screen.
CTRL-ALT-DEL doesn't do anything either.
I get the same thing when I select Last Known Good, Safe Mode, Safe Mode
with Networking, and Safe Mode Command Prompt.

Probably because this is one of the damaged clusters that had to contain that information.

I've cloned the drive a second time, this time using Partition Magic 8, and
AGAIN it's copied fine, verified OK, but still the same problem.

The same problem as before, if you have bad clusters you're going to image them to the new drive.

The swapfile is definitely copying over OK - I've hardcoded XP to use a
swapfile of 128MB, it's located on the FAT32 partition.

Why saving the Swap file on a FAT32 on the same harddrive, you gain no extra performance by doing this. As an MCSE you're told to move the SWAP file to another harddrive to improve performance!

The ONLY thing that's changed in the system, is the hard drive, so AFAIK
there should be no issue whatsoever in doing a forensic clone of the boot
partition from the old HDD to its replacement.

So, I'm wondering if Device Manager is fixated on the fact that the boot
partition is located on a Seagate disk. Could that be the reason why ONLY XP
seems to have a tough time? In which case, what's the simplest way to force
it to recognise that the boot drive is now a Samsung?

If I'm lucky I can copy it across a couple more times before the Seagate
gives out completely, so any suggestions would be gratefully received.

You might try a repair of the failed clone and cross all your fingers and toes and hope that it works and I do hope that you've learned from this experience