SCIENTIFIC-LINUX-USERS Archives

January 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lamar Owen <[log in to unmask]>
Reply To:
Lamar Owen <[log in to unmask]>
Date:
Wed, 30 Jan 2013 10:48:55 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
On 01/29/2013 10:48 AM, 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.
>
> ...

There are two issues with the procedure you posted:
1.) Cloning a r/w/ mounted filesystem with dd isn't a good idea, as even 
a quiescent Linux box is doing a lot of writing on the root filesystem, 
so you'd need to boot in single user mode;
2.) dd can choke on errors and stop before it's actually finished.

Both can be alleviated using the SL Live DVD; I'm not 100% sure about 
the SL Live DVD contents, but it may be that ddrescue is installed, and 
ddrescue will do a better job of dealing with any errors, as well as 
giving you live progress information (opening another terminal and 
issuing a kill -USR1 $pid isn't required to see how far it has gone or 
how fast it's going).  The ddrescue buffering is also more intelligent 
than dd, and will pick a reasonable blocking size for max throughput.  
What you don't want is the filesystem being cloned to be mounted r/w.

You can spin your own Live discs or even make a bootable USB stick if 
you need special tools or configs available.

Or you can use ClonezillaLive and get a nicely integrated setup that 
will just work with minimal fuss.  I've used CLonezillaLive to clone 
some complex configs, and it almost always does the right thing, and 
does it quickly.

As others have mentioned, filesystem UUIDs and similar are also 
duplicated when you do a straight clone, and this may not be desirable.

> 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?
While disabling NetworkManager on an interface-by-interface case is 
easily done (edit the 'traditional' /etc/sysconfig/ifcfg-$iface file 
(for eth0, that's ifcfg-eth0, for example) and add 'NM_CONTROLLED=no' 
and do the config by hand.  This is documented in 
/usr/share/doc/initscripts-*/sysconfig.txt

For normal static configs (specifically not those using bridging or 
teaming, though) NetworkManager works fine, in my experience, and is 
well-documented in upstream's manuals.

ATOM RSS1 RSS2