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.
|