At 03:08 PM 11/8/00 -0600, Bret Hughes wrote:
>I have just about completed a setup for a RedHat 6.2 workstation with
>all updates and a bunch of customizations to it. I will need to
>duplicate this on a bunch of new machines with identical harddrives.
>What is the fastest way to duplicate these multi partitioned drives? I
>experimented with dd about 6 months ago but it seemed really slow.
Depending on how many machines you want to deal with you may find that
kickstart is a better solution than dd (you would have to create a
kickstart file that installs the correct packages and then applies a diff
patch to the root filesystem to apply all your config changes, and you may
want to tack in some machine-specific stuff if you aren't using DHCP. The
advantage to this is that it is not only MUCH faster than making a
byte-for-byte duplicate of the filesystem, it's also faster than doing a
normal RH install, and all you require is a kickstart floppy, a RH install
cd (or nfs volume on your network), and optionally an NFS mountable
filesystem containing all the updated RPM's you want to install (you can
also upgrade all your packages automatically as part of the kickstart
file), so it saves time on moving hdd's around as well. If you're working
with less than say 6 machines it's probably not worth the trouble, but for
10 or more it's a life saver (actually just the image of being able to
insert 1 floppy each in 20 workstations and then run down the aisle
flipping each of them on and watch them all perform unattended NFS installs
of Redhat in a matter of minutes is worth it just for the shock it imparts
to NT fans). Another nice thing about this is that since kickstart can be
arranged to upgrade from a NFS filesystem at install time, a kickstart disk
becomes the ultimate troubleshooting tool if you have to deal with users
who break software. Just insert the kickstart disk and reboot. . .
>What I am going to try is booting from toms boot disk with both the
>newly configured drive in it and a new emtpy one. Then do dd if=/devhda
>of=/dev/hdb
>
>Would I gain anything by putting the empty drive on the second
>controller (/dev/hdc)?
Yes, but not a whole lot unless dd is streamlined to take advantage of the
ability to read & write in parallel (AFAIK it's not). Best improvements I
can suggest are:
- If you haven't already got one, buy a 5.25" removable IDE bay and use
that to swap drives around quickly so you don't need to take the case off
the main system. On some particularly clever IDE controllers you don't even
need to reboot when switching disks, just reset the controller.
- Set your boot disk up so that you use decent IDE configuration (using
hdparm) as this can easily half the time it takes to copy a full drive.
- Consider using sfdisk to non-interactively partition your destination
drive (or if you don't have too many drives to write to, use whatever you
prefer) and then "cp -av" to do a high-level copy of your root filesystem.
This should be a great deal faster than dd since it only needs to copy
useful information, not empty space (e.g. if you're using 30gb disks and
doing a 900mb install leaving 29.9gb of free space then dd needs to copy
30gb of info and cp only needs to copy 900mb).
- If your customization doesn't include using ext3, RAID, e2compr or
anything else that makes low-level changes to your filesystem, you may
consider trying other utilities to see if they're faster. Partition Magic
for example will copy partitions fairly quickly and has a nice friendly GUI :)
>What would be an efficient block size to use?
Some even multiple of the cluster size on the hdd, but smaller than the
drive's onboard cache. 32 or 64kb works well in my experience (most of my
IDE drives seem to have from 128 to 512kb if cache, your mileage may vary).
>Will this setup lilo (on the mbr) as well?
If you're copying the raw device (i.e. "/dev/hda" rather than the partition
"/dev/hda1") then it should. Assuming the drives are identical.
>Would I be better off just cpioing each partition to a server and
>creating a script that will partition the new drive, copy the files,
>mount the new partitions and run lilo? I guess this would not lock me
>into a specific harddrive geometery.
Yes, but then you have to boot the workstation in such a fashion that it
can access the server. . . You're approaching if not surpassing the
complexity of a kickstart setup.
>I guess I could fdisk the partitions and then dd the individual
>partitions? Is there a way to copy or script non interactively the
>creation of partitions on a hard drive?
Yes, read the docs for sfdisk. Kickstart also has the capacity to partition
drives as part of the kickstart initialization file, if you use the
"mkkickstart" script included with the kickstart rpm it should set the file
up to duplicate the partition structure on the current hdds automatically.
>Thanks,
You're welcome. Hope this helps :)
--
Who is this General Failure, and why is he reading my hard disk?
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
