[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 9163 Date : 2004-11-08 Author : Kan Yabumoto Subject : Re: Still well and truely STUCK????? Size(KB) : 6
Pat wrote: > Source Drive is 40GB Maxtor Designated as C:\Main System Drive. > Dest Drive is 40GB Maxtor. Designated as D:\XXCLONED Drive. As a side note, let me comment on a very minor point. ------------------------------------------------------------ When we discuss XXCLONE, it is best not to refer to disks by C: and D:. Unlike the DOS-based system (Win 9X/ME), in Win NT/2K/XP, drive letters are normally fixed to partitions regardless of how you plug in the disk (as Disk0 (as master) or Disk1 (as slave), etc.). But, exactly because XXCLONE tries to swap drive letters when the cloned system is booted, our discussion simply gets more confusing if you talk about "D: drive" after a reboot into the newly cloned volume. If everything goes as designed, the system disk from the formerly D: drive will assign the C: designation. ------------------------------------------------------------- > When I carry out the following: > > Complete Re-Format of Drive D: the carry out the > following using the text shown: > > After Re- Format: > > Open Command Window. Enter the following command. > > Xxcopy C:\ D:\ /backup/b0 > > When this had finished entered this: > > Xxclone c: d: /backup0 /bc0 /start Again, a minor point here: The following two are equivalent: Pat's method: xxcopy c:\ d:\ /backup/b0 xxclone c: d: /backup0 /bc0 /start My suggestion: xxclone c: d: /backup1 /bc7 /start I suggest the second (XXCLONE-only) method because XXCLONE is superior to XXCOPY for a full volume backup because XXCLONE supports any file/directory name whereas XXCOPY cannot handle Unicode-based file/directory name. Other than that, both methods are equivalent. But, this is not the cause of the current problem. ------------- Now, here's my real response to the core issue here. Whenever you encounter an error message on HAL.DLL generated by XP, unless you have a reason to believe that the HAL.DLL file is really missing, don't take the error message at the face value. It is a very misleading error message by XP. In 99% of such cases, the real problem is the boot sequence had a invalid set up that the system did not find the HAL.DLL file in the windows system directory it expected. You should examine the whole setup very carefully. --------------------------------------------------- Whenever you see some boot-sequence problem (i.e., the HAL.DLL problem), I strongly advise that you use the quick boot diskette that is created by XXCLONE. It eliminates all the uncertainties of which of the three components is missing. You can always edit the BOOT.INI file on the diskette to cover all combinations of disk number and partition numbers. --------------------------------------------------- In the present case, my hunch is that the BOOT.INI file is not pointing the right partition. This is because the BOOT.INI file on the target volume has never been initialized properly (with the /BC0 switch). The BOOT.INI file is one of those file that cannot be simply copied from one volume to another. Furthermore, I suppose Pat's problem report must have some omission of the fact. If HAL.DLL was not found by the system, the target volume will not boot, period. I interpret what Pat really did was that he either manipulated the BIOS setting (or physically swapped the disks) to directly boot the system from the newly cloned disk. As long as the boot sequence used the existing BOOT.INI file (the one in the root directory of the original disk's active partition), the second entry (Disk 1, Partition 1) will address the correct disk's correct partition. But, if you manipulate the boot sequence (either from BIOS or by hardware re-configuration) and the system's disk-numbering scheme changes (the original disk1 may now be disk0). If the system uses the BOOT.INI file in the target volume (which was improperly copied because of the use of XXCOPY rather than letting XXCLONE to do it right), the contents of the BOOT.INI file should be carefully tweaked to match the condition. Over 95% of users's system, the system usually chooses the first disk (disk0) that is seen by BIOS as the first disk as the initial 'Bootstrap' disk. That's where the MBR is read and the active partition flag in the partition table inside MBR will choose which partition to go to. Then, the bootsector of the active partition loads NTLDR in the root directory of the partition which in turn reads the BOOT.INI file of the same volume. If the target volume was kept as the second disk (Disk1) of the system and the system was restarted from scratch, then, the original volume's BOOT.INI file will be used. So, as long as you use the same hardware configuration, the BOOT.INI file of the target volume will never be accessed in the boot sequence even if you boot the system into the target volume. I guess Pat's problem is when he wants the target volume to "self-boot" (i.e., the system boot sequence is directed to go directly to the cloned volume), the BOOT.INI file (which is identical to the original volume's BOOT.INI). At that time, I assume Pat's hardware configuration is such that Disk1 (in the second line of his BOOT.INI) does not even exist at that time. Again, this speculation is based on my observation (mentioned at the beginning) that Pat's usage of C: and D: confuses himself --- the BOOT.INI file that was transplanted from the original volume to the target without any change makes him believe that the second line in the BOOT menu will give him the "target" volume. What Pat does not realize is that the simplest remedy is to select the first line in the boot menu (disk0) which will let the system select the "target volume" which is at that configuration is connected as disk0. I bet if Pat uses the quick boot diskette, the problem will go away immediately. Once the proper value for the BOOT.INI menu line is determined with the help of the diskette, make the necessary change in the BOOT.INI file of the target volume. Get confused? I don't blame you. But, this whole problem would not have occurred if XXCLONE was allowed to the whole job. When an XXCOPY/XXCLONE hybrid solution is used, the BOOT.INI file's contents must be carefully adjusted. The easiest remedy is probably to let XXCLONE do its job with /BC1 at least. Kan Yabumoto
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.