[<<]Message[>>]    [<<]Author[>>]        Subject[>>]    [<<]Thread[>>]

Number   :  9189
Date     :  2004-11-11
Author   :  Kan Yabumoto
Subject  :  Re: Xxclone of Laptop XP Pro Disk
Size(KB) :  4


At 2004-11-10 12:00, you wrote:


>Oops! I tempted fate earlier by writing
>I'd done 'full disaster rehearsals on a
>Win 2k SP4 laptop *and* on a Win XP Pro
>SP2 laptop'. This was perfectly correct
>for the W2k laptop but I'd not yet
>physically swapped the drives on the XP
>machine. When I did so (two hours after
>posting the message) Sod's Law struck.
>
>Everything went fine up to getting the
>login screen. When I OK'd my password,
>the screen changed to the 'Please Wait =AD
>Logging off...' screen. (No other
>message). After 3 minutes and plenty of
>disc activity I got part of the Windows
>jingle. At 4 min the login screen
>returned. I entered the password and the
>same thing happened. Repeated this four
>times. Then tried logging in as
>Administrator (instead of just as me with
>admin privileges). Same result, so I gave
>up and swapped the drives back to square
>one.
>
>Can anyone help me over this final hurdle
>with the XP backup?
>
>For what it's worth:
>
>1. I did all the Xxclone operations
>with the default setting /BC0.
>2. At all times I worked from my own
>user area with admin privileges.
>3. The file Xxclone5.bat exists on the
>clone but since I can't log in it's not
>been activated yet.
>4. BOOTSECT.DOS look identical in
>master and clone.
>5. The debug log files for W2k (which
>worked fine) and XP (which stalled at log-
>in) both contain the line 'Failed CopyFile
>C:\NTBootDD.sys to G:\NtbootDD.sys'.
>However, since this file doesn't seem to
>exist anywhere on the XP or W2k laptops it
>can hardly matter.
>
>I'm stumped for now. Would appreciate any
>help.
>
>Thanks,
>David Tong.


Currently, XXCLONE does not support a dual-boot
disk completely. You are correct that BOOTSECT.DOS
is not customized for the target disk (but must
be adjusted to each disk dimention). The target
volume will become a single-boot (non-dual-boot)
disk at this time.

Also, if you create the target volume from scratch,
you may need to initialize the bootsector (/BC2)
and most likely, you should initialize the BOOT.INI
file at least once (/BC1). Under normal circumstance
(unless your system relies on a non-standard
boot tools, you should re-initialize the MBR once
(/BC4). Combining these, /BC7 will do it.
Although this may be a hassle, we wanted to be
on the "safe" side since it is not easy to determine
if a given MBR or bootsector image is not-initialized
at all or has been initialized by a third-party tool.

As to the very slow boot process, we have heard
similar reports from time to time. The initial
delay in XP at the beginning of the boot sequence
is a little mysterious for us. Although we have not
confirmed this, we have a hypothesis to explain this.
That is, immediately after you attach a brand new
disk to an XP system and initialize the disk for
the first time (creating a partition, format the
volume, etc.), the system registry may not be fully
"synchronized" the new hardware configuration. Therefore,
if you re-boot once after the introduction of the
new hard disk to the XP system, the system registry
is fully synchronized. Then, the XXCLONE operation
that transfers the synchronized system registry
to the target volume and the boot process may go
much smoother than otherwise. As I said, we have not
tested this theory. But, it is based on our experience
that every time you attach a new device, the plug-and-
play scheme kicks in with the XP and the system typically
accept the new device without a reboot in many cases.
But, I guess the next time you boot the computer, the
XP will take longer in the boot sequence. I'm not
sure if this behavior is related to the unusually long
delay at the first boot from the XXCLONEd disk in some
cases. We just don't have a good answer to the delay
at this moment.

You are correct that the NTBOOTDD.SYS is not needed
in most system. When it does not find the file,
it generates the log entry for it and you can safely
ignore the error message. The terse debug info
is not meant to be "user-friendly" and we did not
spend time to document it (there are probably other
similar error messages that are harmless).

Kan Yabumoto



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.