There are advantages and disadvantages of the methodology you use.  I 
have the following questions:

1.  The SL live CD presumably requires a manual configuration of the 
network -- this university uses /22 IPv4 subnets (we have not made the 
full conversion to IPv6, although we support IPv6 addresses and most 
IPv6 utilities/services) and Network Manager does not seem to be able to 
detect this.  Thus, during the SL live CD boot, the network must be 
manually configured one machine at a time.

2.  On the target machine, one must repeat step (1) and get past LAN 
security (assuming that the machine that contains the tar image is not 
on the WAN with additional issues thereby created due to network 
security control) to untar / onto the target machine.  Note that (to the 
best of my knowledge), tar does not create the MBR (I am being specific 
to the IA-32/X86-64 typical boot architecture in this comment) and thus 
requires the additional manual steps you outline.  dd of an entire hard 
drive does clone the MBR and also effectively does the formatting step 
of each partition (we are not using logical volumes, but "old fashioned" 
distinct partitions).

You also presume a high throughput network, depending upon the size of 
the tar file image, as otherwise the time for getting the tar image can 
be substantial.  Whilst the network here is adequate at switched 802.11 
100BT, with only limited segments at 1 Gbit/sec or higher bandwidth, the 
actual throughput -- as measured -- can be less than 1 Mbit/sec causing 
substantial delays.  These workstations are NOT on a 1 Gbit/sec segment, 
but only at 100BT, and we (locally) have network issues.  As the 
workstations have physical security locks and are cabled through raised 
flooring, physically moving the machines to a location with a proper 1 
Gbit/sec LAN segment, bypassing the local university security 
implementations, VLAN segments, etc., is a significant amount of 
physical work.

Am I misstating your methodology?

Yasha Karant

On 01/29/2013 07:56 AM, Steve Gaarder wrote:
> I've done cloning for many years with tar:
>
> On the source machine, boot from an SL live CD and mount the source's
> root file system.  Make a tar file of this system with a command like:
>
> cd /mnt/wherever
> tar -cSf - . | ssh someuser@somewhere 'cat >mysystem.tar'
>
> Then, on the target, boot the live CD, partition the disk, create the
> root filesystem and mount it.  THen untar the contents with something like:
>
> cd /mnt/wherever
> ssh someuser@somewhere cat mysystem.tar | tar -xpSf -
>
> You may need to change /etc/fstab and /boot/grub/grub.conf, if the
> partition layout is different or the files use UUIDs.  In the latter
> case, I just change to partition names (e.g./dev/sda1).
>
> Then run grub to install the boot loader:
>
> grub
> root (hd0,X)
> setup (hd0)
>
> This works great as long as the hardware is similar enough that the
> initrd/initramfs still works.  Otherwise, there's an extra step to
> regenerate it, which I can explain if people want.
>
> Steve Gaarder
> System Administrator, Dept of Mathematics
> Cornell University, Ithaca, NY, USA
> [log in to unmask]
>
> On Tue, 29 Jan 2013, Yasha Karant wrote:
>
>> We have a limited, small, number of IEEE 802.3 connected hardware
>> platform identical workstations to clone -- no 802.11 nor any shared
>> (remote, distributed) disk storage (at this time).  My plan was to get
>> one fully operational and configured, and then clone the hard drive
>> image onto the remaining machines one hard drive at a time.
>>
>> Let A represent the operational (clone source) machine, and Bhd a
>> target hard drive.  The hard drive on A is /dev/sda, call it Ahd.  A
>> is shut down power off.  Bhd is installed into an available bay on A,
>> A is booted, and Bhd appears as /dev/sdb in A.  Using dd on A, clone
>> /dev/sda to /dev/sdb .  Mount on A the partition of /dev/sdb that
>> contains /etc (there are no end user home directories -- only home
>> directories are those of the system administration users).  Using a
>> text editor (e.g., vi), modify the /etc/sysconfig/net*
>> scripts/directories, as well as /etc/hosts. for the name and IP
>> address of machine B that will contain Bhd (resolv.conf will be the
>> same -- all of these machines are in the same DNS subzone, same TCP/IP
>> subnet).  Iterate through all of the target workstation hard drives.
>> As there are no other distributed services running, this should suffice.
>>
>> Shutdown A, remove Bhd, install Bhd into B, boot B upon which Bhd
>> should appear as /dev/sda .  Done.
>>
>> Is there a better method in terms of software?  At this time, I do not
>> want to setup a remote image server that effectively will download the
>> full image of Ahd onto Bhd over a network, nor do I want to make a
>> custom install DVD as we only have a small number of workstations to
>> clone, not, say, one hundred.
>>
>> I do understand that if Ahd and Bhd present different bad blocks to
>> the OS, and these are not "hidden" by the intelligence on each
>> individual hard drive, then dd may not work.  However, the drives
>> already have been surveyed and the bad block situation should not be
>> an issue.
>>
>> A related question (that was partially addressed in a different
>> thread):  is there a way to remove/disable Network Manager and use a
>> traditional static configuration?  On a laptop that needs to move
>> within the field from one 802.11 network to another, with a different
>> DNS zone and TCP/IP configuration, Network Manager provides similar
>> ease and functionality to the end user autoconfiguration applications
>> that are used under Mac OS X or modern MS Win.  This is unnecessary
>> and in some sense dangerous for static workstations that need no such
>> dynamic configuration.
>>
>> My thought was to find the RPM that installs Network Manager and
>> simply uninstall it, either via yum or a simple rpm -e command.  Is
>> Network Manager too deeply ingrained in current EL6 (using TUV
>> compliant model) to make this feasible?
>>
>> Yasha Karant
>>