M
Michael Solomon \(MS-MVP Windows Shell/User\)
Thank you, Sharon.
Nothing you did or said was an issue for me.
Nothing you did or said was an issue for me.
V
*Vanguard*
Michael Solomon (MS-MVP Windows Shell/User) said in
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).
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).
V
*Vanguard*
William B. Lurie said in news:[email protected]:
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
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
V
*Vanguard*
William B. Lurie said in news:[email protected]:
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.
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.
V
*Vanguard*
William B. Lurie said in news:[email protected]:
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).
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.
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.
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.
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).
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.
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.
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.
M
Michael Solomon \(MS-MVP Windows Shell/User\)
I haven't used it in a long time but I always thought Ghost was a great
product.
product.
M
Michael Solomon \(MS-MVP Windows Shell/User\)
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.
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.
W
William B. Lurie
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.
--
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.
--
W
William B. Lurie
*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
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
M
Michael Solomon \(MS-MVP Windows Shell/User\)
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.
appeared to give me more options, it also felt more intuitive to me.
R
Richard Rudek
I've not used it, but presumably your doing ALL OF THIS using Drive
Image's PQRE ?.
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.
T
Tom
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.
LOL!