SCOUG-HELP Mailing List Archives
Return to [ 18 | 
February | 
2004 ]
<< Previous Message << 
 >> Next Message >>
 
 
 
Content Type:   text/plain 
=====================================================  
If you are responding to someone asking for help who  
may not be a member of this list, be sure to use the  
REPLY TO ALL feature of your email program.  
=====================================================  
 
I think what I would attempt would be to use dfsee 6 (only version I have   
available to me at the moment, it's downloadable for free trial) to first   
select the new drive (File > Open disk) and use the "fdisk" menu of dfsee to   
create a new mbr (Mode=FDISK > New MBR code); if that's successful, then go   
back and select the old drive, and then use dfsee's clone feature to clone   
it to your new drive (Actions > Clone from whole disk).   
 
Wayne   
 
J. R. Fox writes:  
>   
> This seems like a good place to segue, on the heels of Sheridan's post about partition corruption.  How  
> much  
> of a mess can you make, by the simple act of trying to clone a hard drive ?  I may have just found out.   
>   
> Having irretrievably (?) lost the two W2K partitions on my desktop system some months ago, I wanted to  
> gain some insurance for the ones that are working fine on the Shuttle portable, esp. before I put eCS and  
> System Cmdr. on it and do some other possibly risky maneuvers.  (Drive trays are not a practical option  
> for  
> this little unit, so I'm stuck with the problems of a multiboot setup.)  So, I got a 2nd. identical H/D,  
> and set  
> about cloning everything as it exists at the moment -- some 18 partitions worth, including ones reserved  
> for  
> IBM Boot Mgr., and two eCS partitions.  Everything was going great, up until the very end.  (Beware  
> whenever  
> things seem to be going really well !  The edge of the cliff may be right there, just over the next rise.)   
>   
> Let me back this up a bit for you.  This is supposed to be a simple, straightforward procedure, right ?  
> The  
> first tool I reached for was GHOST 2003, by most accounts a capable product, but one with a rather dumb  
> design in its UI.  The drive-to-drive procedure with GHOST bombed out immediately, with an error message  
> that said "Call Symantec."  Uh, no thanks.  (I'm positiive that it did not get as far as starting to do  
> anything with  
> the bare drive.)  I next turned to Drive Image 4, a better program I'm quite familiar with at this point.  
> Right  
> away at the setup phase, I could see that its Drive-to-Drive feature -- unlike its regular Imaging feature  
> --  
> could only see the few FAT-16 partitions.  So much for that.   
>   
> I recalled that Ray has mentioned cloning *partitions* with Partition Magic, a number of times.  O.K.,  
> that's  
> taking the longer, slower, labor intensive route, but it should get me to the destination.  So I started  
> to clone  
> each partition in turn, drive to- drive, with PM-6.  This program spends a lot of time verifying the  
> target media  
> *first*, then verifying the partitioning / formatting / data copy the rest of the way -- so we're talking  
> several  
> hours overall.  Everything proceeded smoothly, right up through partition 17.  Maybe I should have had  
> some  
> concern that there were tiny variances in the size of the cloned partitions.  Like 305.8M vs. 305.9M.  Now  
> I can  
> tell you where I probably screwed up, on the final partition, but PM screwed up much worse on the disaster   
>   
> avoidance part of its design.  Ray had asked me, "Isn't there a PM gotcha about the source & destination  
> partition  
> sizes having to be the same, or larger at the destination end ?"  This was a an easily preventable  
> oversight on my  
> part, but the destination space was less than half a Meg. too small -- largely because of these very  
> small, but  
> cumulative differences !  At the end of cloning the last partition, PM barfed.  Worse yet, it wiped out  
> the first  
> partition *along with* the MBR, in a way that may be unrecoverable.  If the damn program had been properly   
>   
> designed, it should not even have attempted to clone the last partition, but seen a mismatch and returned  
> a  
> "Nope, you can't do that" sort of error.   
>   
> PM can no longer deal with the cloned H/D in any fashion.  It takes one look at the drive and gives forth  
> an  
> Error #108, the meaning of which seems to be:  "Sorry Pal, but you are utterly, totally *****d."  
> (PowerQuest  
> was bought out by Symantec, so I guess one is supposed to call the latter now, and shell out serious  
> dinero for  
> live support, if they even still support a version that old.  Again, no thanks.)   
>   
> Enter DFSEE.  Except for a couple relatively simple things, like Set Partition Active (much more  
> accessible  
> now, with the GUI version), I've never really learned how to use this program.  I recognize that a lot of  
> work  
> has gone into making it more non-techie friendly, and into revising the documentation and Help.  But I'm  
> sorry: reading through that stuff still makes me feel like a dolt.  I know that it has partition and whole  
> drive  
> cloning features, and maybe I should have tried the latter, from the get-go.  Anyway, at the moment I am  
> much  
> more interested in its analysis and recovery features.  It so happens that I have the DFSTART files from  
> the  
> Source drive.  However, so far I can't see that this is going to be helpful.  DFSEE (5.54) shows that  
> Partition 1  
> has been turned into Free Space, and that Partition 2 (the alternate C: partition) is now the first actual  
> partition.  
> Attempts to do anything to or with that free space results in a DFSEE error #252, General Command Failure.   
>   
> It is like that first 305M is there, but it _isn't_ there at the same time -- or it is at least  
> untouchable.   
>   
> In theory, PRESTORE should be able to resurrect the MBR from the DFSTART files, and the first partition  
> should be re-clonable.  But I'm not sure how to get there from here, or if it has any prospect of  
> working.  It  
> sure would be nice to salvage the work already done, if the results can be reliable.  Or maybe I should  
> just wipe  
> the duplicate drive (not sure How), and try the DFS drive to drive cloning.  The one thing I want to be  
> damn  
> sure of is that nothing adverse happens to the Source drive, in the course of attempting this.   
>   
> If anyone has a step-by-step for me here, it would really be appreciated.   
>   
>   
> Jordan   
>   
>    
>   
> =====================================================   
>   
> To unsubscribe from this list, send an email message  
> to "steward@scoug.com". In the body of the message,  
> put the command "unsubscribe scoug-help".   
>   
> For problems, contact the list owner at  
> "rollin@scoug.com".   
>   
> =====================================================   
>   
>   
 
 
=====================================================  
 
To unsubscribe from this list, send an email message  
to "steward@scoug.com". In the body of the message,  
put the command "unsubscribe scoug-help".  
 
For problems, contact the list owner at  
"rollin@scoug.com".  
 
=====================================================  
 
  
<< Previous Message << 
 >> Next Message >>
Return to [ 18 | 
February | 
2004 ] 
  
  
The Southern California OS/2 User Group
 P.O. Box 26904
 Santa Ana, CA  92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group.  ALL RIGHTS 
RESERVED. 
 
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International 
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
 
 |