FIXMBR redux

  • Thread starter Thread starter William B. Lurie
  • Start date Start date
Thank you, Sharon.

Nothing you did or said was an issue for me.
 
Michael Solomon (MS-MVP Windows Shell/User) said in
If you delete the partition on the drive you originally imaged, the
MBR is gone, hence, if that drive is bootable upon restoring the
image you created of that drive, it must be restoring the MBR when it
restores the image.
Click to expand...

Deleting a partition only updates the partition table (which is after
the 460-byte bootstrap area of the MBR, or sector 0). Deleting a
partition does NOT touch the bootstrap program! That's why you can
still use that bootstrap program on that drive after deleting, changing,
or moving partitions whether using PartitionMagic, DriveImage, or FDISK
(without using its undocumented /MBR parameter).
 
William B. Lurie said in news:[email protected]:
Okay, I put the clone back in Slave spot so that I could search and
make the deletions you recommended. I found boot.ini and removed
the line referring to CMDCONS. That's the first good news. The first
bad news is that Search couldn't find CMDCONS itself, nor could
it find CMLDR.

The second good news is that I ran that drive again in Master or
Single position (alone, as Master) and this time it (of course)
didn't do the RC choice,ecause it is gone from boot.ini ....

But the second bad news is that it proceeds then to the black
Windows XP logo screen, and then to the light blue screen where
it should load my personal settings......and still hangs there.
So I'll hope you can tell me how to get past that road block.
Bill Lurie
Click to expand...

The cmdcons directory has the system and hidden attributes set. When
searching, you must use the advanced options to enable searching of
hidden and system files. However, there really isn't much searching to
do. The directory is:

C:\cmdcons

That is, it is right under the root node. Review the following KB
article:

How to remove Windows Recovery Console
http://support.microsoft.com/?id=555032
 
William B. Lurie said in news:[email protected]:
Thanks, Jeff. I looked for cmdcons and \cmdcons all over
c: ..... several ways. Windows Explorer; Search;
and even went to run 'cmd' and went to c:\ root
directory and I couldn't find it. And of course, I did all
the *show hidden files and folders* and cleared the Hide
Protected operating system files.

Of course, if I can't find those files and folders, then
I don't have to delete them.
Click to expand...

Hmm, maybe you really no longer have the Recovery Console installed but
the entry was left behind in boot.ini. If you select Recovery Console
from the boot menu, can you actually get into Recovery Console mode?
Could you show us the contents of your boot.ini file? It will list the
path to find its executables for its menu selection in boot.ini.
 
William B. Lurie said in news:[email protected]:
Sharon, it's indeed unfortunate that the software designer,
in PQ, chose to leave the words 'copy' and 'image' mixed
up. What they call a "drive image" is indeed a bunch of code
which their own recovery program is supposed to convert to
a clone or exact copy or duplicate of the original. Neither
they nore anybody else has made it clear to tired, muddled old
me, why that two-step capability is necessary or even desirable.
Click to expand...

If you were to save exact bit-for-bit-by-sector of your drive, your
backup media would have to be as large as the source drive you were
backing up. For an 80GB hard drive, you would need another 80GB hard
drive (you cannot mix media types, like using DVD to save this type of
image since the file systems and formatting along with the controller
support are different). Saving an image fileset which contains a
logical description of the physical definition of a partition means you
can compress it (to reduce how much backup media space you will need),
skip unused sectors (which DriveImage will do but not Ghost) but simply
record that they were skipped, and you can use a completely different
type of backup media, like CD-R[W], DVD-+R[W], tape, another drive (even
using a different interface), and so on. The recovery program will use
the file system needed to read the image fileset to perform a physical
write based on the logical information from those files.

A *clone* of a disk is what you were thinking of and will do a
bit-for-bit read of each sector on the source disk and lay down that
same exact data onto the target disk. So obviously your same media-type
clone disk has to be the same size or larger than your source disk.
Even if it were possible to save a *clone* of a hard drive onto DVD-R[W]
discs, would you really want to take the time writing to slower DVDs and
having to swap and store something like 20 of them when you could've
save an image fileset on half or less of that? DriveImage writes its
boot program on the first CD/DVD so you can boot from that and restore
using that media so it is still very convenient to use the image fileset
as opposed to using a clone or ISO image but the restore will take
longer because of the slower media onto which the image fileset was
saved unless, of course, you save it on, say, another hard disk. For
disaster recovery (that is external rather than using mirroring), I
prefer NOT to use hard drives because they are mechanical devices. Try
to explain to your boss that you cannot do a restore because the media
is okay (platters) but the interface controller on the hard drive or the
actuator for the head assembly doesn't work anymore. You can destroy
the removable media, too, but you could destroy CDs as well as you can
destroy the platters in a hard drive, but with removable media you can
get another drive to replace the faulty one. Disk images (clones or
image filesets) on hard disks should only be for short-term backups,
like maybe a week, for quickest recovery but not considered your
long-term recovery media. I've experienced a joker dropping a hard
drive and losing our recovery disk (but we had the older recovery
removable media to fall back on).
So I went back to where I was a month ago, when I tried making
what PowerQuest describes as a "copy". I installed my Slave
drive as Master and formatted it anew, as Active and Primary,
and empty. I then jumpered it as Slave, put it in Slave
position, put my Master on as Master, and used Drive Image 7.0
to "Copy One Drive to Another This copes the contents of
your Drive directly to another drive". Actually, I copied only
the first (Master) partition of my Master Drive to the Slave.

I used Partition Magic to verify that the Slave Drive contained
very close to the same number of bytes as the Master OS. I then
shut down, jumpered the Slave Drive as a Single Drive, put it in
Master position on the cable, no other drive present, and booted
up. It got to where I was when I did this same thing a month
ago, so at least it's reproducible. It booted through BIOS, to
the place where I could select XP Pro or Recovery Console, I
picked XP, and got the black Windows logo screen, and then after
the usual wait, the light blue Windows logo screen, which should
say "loading your personal settings"........and there it hangs.
So Windows copied nicely, and all my data and files and programs
and applications copied nicely, but it doesn't get to the "Loading
your personal settings" place. Those words are missing from the
light blue screen, and that's where I was when one of the MVPs
(who shall remain nameless) convinced me that I should not use
the "Drive Copy" path, that I really wanted the Image.
Click to expand...

Boy, sure sounds like what you did should have worked. The only thing
that comes to mind at the moment is disk signatures. Each disk has an
area where a unique signature of hex bytes get written to it. Windows
NT/2000/XP will use the signatures to identify the device. That is why
you can configure a partition on a disk as C:, insert a new hard drive
in the physical scan chain that positions it before your old drive, and
C: will still be seen as the partition on your now second hard drive. I
haven't much investigated how DriveCopy works. I would've thought that
it would copy ALL bytes across ALL sectors (rather than work within the
bounds of partitions). That would mean it would include the track 0
along with the MBR in which the disk signature is written. But if
DriveCopy doesn't touch the MRB (or track 0) then the second drive will
still have its disk signature that it had before when it was not drive
C:. The boot.ini file (other than for Recovery Console or some other
parallel installed OS) denotes where to find Windows based on physical
parameters (drive and partition), and that works because, as you've
mentioned, you got past the boot procedure and get into the OS load
process.
Well, he couldn't get me past that road block, in the XP
boot-up procedure, Sharon, maybe you can? Or maybe I need the other
piece of software that somebody just suggested here.
Click to expand...

See if using the /SOS option in boot.ini on the line used to load the
instance of the OS that you select. See
http://www.sysinternals.com/ntw2k/info/bootini.shtml for a reference of
boot.ini setup and options. However, it sounds like you are getting
farther than the driver load screen will show, anyway.

Do you get the same hang if you try to boot Windows into its Safe mode?
I have found, especially after some hardware changes or driver installs,
that Windows will hang during the device detect phase. So I boot into
Safe mode and then reboot again but into normal mode.
By the way, I searched for cmdcons folder on C:\ and can't find
it. Yes, I told it to seek hidden files. I did find it in boot.ini,
however.
Click to expand...

See my other posts in response to you not finding the cmdcons folder.

There is one other point that I would like to mention. When saving an
image fileset (not making a clone), do not save it on an NTFS partition
on a hard drive. While Symantec says they support the saving of the
image fileset on NTFS partitions, I have encountered problems with that
on many occasions. The restore will fail at some point, usually around
75%, and then abort with a message that it cannot file the image file
that it was just reading okay up to that point. One cure which often
helps is to NOT use the Caldera DOS that Symantec uses for the bootable
floppies (and for the bootable first CD in an image fileset saved to
that media type). They recommend creating an MS-DOS 6 or Windows 98/ME
bootable floppy as the first floppy in their 2-floppy boot set. When
Caldera DOS caused DriveImage to fail, I often could get a Win98 boot
floppy to work (but then I had to restart the entire restore). This is
not a problem of an NTFSDOS driver not working under Caldera DOS but
working under MSDOS6 or Win98. DriveImage doesn't need that driver but
it will still make BIOS calls through the underlying DOS. Hmm, this
isn't some really old computer that requires a disk overlay manager in
the bootstrap area of the MBR, is it?

The other cure is to not save the image fileset on an NTFS partition on
a hard disk and instead save it instead on a FAT32 partition (you don't
have NTFS on non-hard disk drives so it isn't an issue on those other
media types). This only addresses the problem if DriveImage should
abort for you at some time. However, if the image restore completes
okay then I would assume the entire process completed without any write
errors to the restore disk.
 
I haven't used it in a long time but I always thought Ghost was a great
product.
 
Yeah but aren't we just modifying the bootstrap? I agree, deleting the
partition does not touch the bootstrap. Of course, if I extend my thinking
on this, it doesn't have to touch the bootstrap or MBR. If you've modified
so that the bootstrap or MBR is looking for something that doesn't exist in
this particular image, that would explain the error William was getting. In
other words, the MBR is set to look for something that isn't in the image.

I know he's going to bust my chops on that because he'll say it's an exact
image but that is what I have been telling him. The hal or the hash is
different because of the changed hardware configuration, hence he gets a
missing or corrupt HAL.dll warning as he described. That means he's bumping
right into XP's anti-piracy scheme as I had surmised. He made an image of a
setup that was not installed when the other hard drive was also connected to
the system. When he restores the image, XP thinks it's a different
computer.
 
I don't remember what the reason was, Michael, but I tried
Ghost for a while, and I don't remember why, now, but I
didn't like it. I'm into Drive Image 7.0, specifically
for NT/2000/XP, and I'm getting to understand it and how
to work with it. And we are making progress, aren't we?
Only now I have 2 bootlogs for the experts to compare, since
it is obvious that nobody other than an MVP or Microsoft
insider could possibly know what more than a very few of
the calls in the bootlog mean.

In that regard, it occurs to me that it is just a little unfair
to try to compare the bootlog of an OS created a month ago, with
that of an almost-clone from today.

I will try to make my Master and Clone identical, tonight, and
create two new bootlogs which should be identical but which will,
of course, be different.

Bill L.
I haven't used it in a long time but I always thought Ghost was a great
product.
Click to expand...


--
 
*Vanguard* wrote:

Vang, you sent us so much info, so very thorough you are, and
informative, that I cannot answer you until I try to absorb
it all. And lest I forget....... thank you.
W B L
 
In my case, I liked the Drive Image interface better than Ghost and it
appeared to give me more options, it also felt more intuitive to me.
 
William B. Lurie said in news:[email protected]:snip]
So I went back to where I was a month ago, when I tried making
what PowerQuest describes as a "copy". I installed my Slave
drive as Master and formatted it anew, as Active and Primary,
and empty. I then jumpered it as Slave, put it in Slave
position, put my Master on as Master, and used Drive Image 7.0
to "Copy One Drive to Another This copes the contents of
your Drive directly to another drive". Actually, I copied only
the first (Master) partition of my Master Drive to the Slave.
Click to expand...
Click to expand...

I've not used it, but presumably your doing ALL OF THIS using Drive
Image's PQRE ?.
I used Partition Magic to verify that the Slave Drive contained
very close to the same number of bytes as the Master OS. I then
shut down, jumpered the Slave Drive as a Single Drive, put it in
Master position on the cable, no other drive present, and booted
up. It got to where I was when I did this same thing a month
ago, so at least it's reproducible. It booted through BIOS, to
the place where I could select XP Pro or Recovery Console, I
picked XP, and got the black Windows logo screen, and then after
the usual wait, the light blue Windows logo screen, which should
say "loading your personal settings"........and there it hangs.
Click to expand...
[snip]

Boy, sure sounds like what you did should have worked. The only thing
that comes to mind at the moment is disk signatures. Each disk has an
area where a unique signature of hex bytes get written to it. Windows
NT/2000/XP will use the signatures to identify the device. That is why
you can configure a partition on a disk as C:, insert a new hard drive
in the physical scan chain that positions it before your old drive, and
C: will still be seen as the partition on your now second hard drive.
Click to expand...

And this, I think, is the key !

I just reproduced this behaviour on a testbed system, by changing the
logical drive letter assigned to a System/Boot Volume from C: to G:...
:)

In your case, however, I will bet that it is the exact opposite of my
test. ie Your System/Boot Volume is G: (or perhaps another drive
letter).

Window Setup will do this sometimes, when there is an existing primary
partition, setting it up the new Windows installation to boot from a
Logical partition, which is usually mounted as G:. Some Brand-name
systems will, consequently, be shipped this way.

Basically, when the 'cloned' copy is booted, it's Disk signature, if it
has one, is NOT the same as the original, and thus when Windows looks in
the registry at boot-up (HKLM\SYSTEM\MountedDevices), there isn't an
entry for it, and it will then assign this 'new' volume a drive letter
based upon the 'order' it enumerates partitions/volumes. In this case,
first Active Primary Partition on the first Hard disk, it will be C:.

In other words, at the Welcome screen, Windows tries to initate various
logon and setup tasks, which are stored within the registry (likely the
user-related stuff), but it is failing or try to look in the wrong
place.

Specifically what it's trying to load, I don't know (yet). But it is
probably the whole of the 'user' Registry Hive. Why it doesn't produce
an error message, I think, is just an oversight (bug).

So what to do ?

Looking through the Drive Image 7.0 Help file ("Restoring a Single Drive
Using the PQRE"), there is an option to "Restore the original disk
signature". Try enabling that.

If that doesn't work, then things are likely to get ugly (technical). If
you really want to resolve this, I'll (we'll) need more details about
the system setup. First and foremost, is the wether the System/Boot
Volume is C: or not. Other low-level details, such as those presented by
PowerQuest's PTEDIT32.EXE utility, may be needed. It should be installed
already, in the "Program Files\PowerQuest\Drive Image 7.0\UTILITY"
folder.

I don't have a copy of Drive Image 7.0 here, either.

[snip]


PS: I stumbled across this thread from a link on the Windows XP expert
forums. I don't normally subscribe to this newsgroup, and had to
subscribe to answer this message. I have NOT read all of the other
messages, yet either, so be aware [Insert usually warnings, going of
half-cocked, etc] :).

PPS: like others on this forum (I'm sure), I'm quite busy, so don't
expect too much from me. But I hope I was able to contribute. I'll
likely unsubscribe from this group, as it's generally not one that I am
interested in. But time permitting, I'll try to monitor this thread for
a few days.
 
Alan F. said:
try this... get an old windows 9x start-up floppy and use the dos FDISK
command firstly to list the partitions on your cloned drive, and then to
set the appropriate one as the boot-up partition (I forget whether it's
called boot or system or whatever). I recently found that unless the
boot-up partition is marked as such, then XP will simply not boot from it.
If no partition is marked as bootable then XP refuses to boot from any
partition.

MS has not given the XP user any tools to set the boot partition before XP
has already booted up (by which time the tools are not needed). Naturally
I think this situation is a pathetic oversight on the part of MS, but I'm
sure they'll be really worried by that :-)

Oh, nearly forgot... I had used FIXMBR and some of the other stuff from
the XP recovery console but nothing in RC does what the old FDISK does.
There's nothing else on the XP installation CD to help.

One more thing... don't worry if FDISK thinks the partition is much
smaller than it really is. All we're doing here is setting the flag in the
MBR to let XP know which partition it is possible to boot from. Once you
have done that, get out of fdisk and boot from your hard disk.

cheers.
Click to expand...

LOL!
 
Back
Top