[Tfug] Cloning systems

[Jim March]

Man, I hope somebody has a solution...because I'm going to face the
same issue when I upgrade my laptop's 80gigger to a 160 sometime soon
(probably still have Ubuntu at said time...).

Jim

On Nov 19, 2007 3:13 PM, Bexley Hall <bexley401 at yahoo.com> wrote:
> Hi,
>
> I had to play swap-a-disk over the weekend (it's
> a game similar to whack-a-mole... except you use
> a BIGGER HAMMER!).  This is on a Slowaris box but
> I think the issues apply to all non-toy OS's.
>
> My initial goal was to move a file hierarchy onto
> a new drive having a different size and geometry.
> I typically use tar to do this:
>
> # #mount new filesystem hierarchy under /mnt
> # tar cpf - <names> | (cd /mnt; tar xpf - )
>
> where "tar" is "/usr/local/bin/gtar" in this case
> (I never trust Solaris' tar(1) ).
>
> Unfortunately, this messes the bed under Solaris
> since hard links aren't supported accross file
> systems so you end up with /mnt/whatever linking
> to /whatever (no goodness there).
>
> A workaround is:
>
> # tar cpf - <names> | chroot /mnt tar xpf -
>
> But, this requires several things to exist in
> the chroot'ed file hierarchy just to implement
> the command itself (e.g., "tar" as well as the
> three or four .so's that it uses -- my gtar is
> not statically linked).
>
> While this may not be rocket science, it is,
> nevertheless, a royal PITA.  :<  Thus raising
> the question:  is there an *easier* way of doing
> this?
>
> Having built the new file hierarchy, I installed
> boot blocks and verified the drive would boot
> correctly and "run" as the original did.
>
> Now, the second goal was to *clone* this drive
> onto an identical mate (i.e., same size and
> geometry).  My first attempt was:
>
> # dd if=/dev/rdsk/c0t0d0s2 of=/dev/rdsk/c0t1d0s2
> bs=SxHb
>
> where:
>
> S is number of sectors per track
> H is number of heads per track
>
> (note that the system has been in single user mode
> for all of this and it is largely quiescent with
> me as the sole user at the text console)
>
> Note that the s2 slice is the "backup" slice which
> should represent the entire disk (i.e., equivalent
> to the "c" slice in a NetBSD/SPARC system)
>
> My thinking was that this should copy the contents
> of all of the files as well as all of the supporting
> filesystem scaffolding.  E.g., I shouldn't even have
> to dick with boot blocks on the "new" drive!
>
> This *appeared* to work -- displaying the number
> of records written as identical to the number of
> *cylinders* in the geometry (i.e. "as expected").
>
> Of course, it *didn't*! :<  So, where did I go
> wrong (i.e. which assumptions are in error)?
>
> Note that I have subsequently cloned the drive just
> by repeating the tar(1) procedure outlined above
> so this question is more of an academic nature, now.
> But, I'd like to know if my approach was inherently
> flawed or if I just got bitten by gremlins in my
> *application* of that approach (i.e., made a typo
> somewhere).
>
> Thx!
> --1138
>
>
>       ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>