You will have to construct a new slave root filesystem whenever you change the software or system configuration on the slaves. The bootloader, boot kernel, or initial ramdisk filesystems only need to be changed when the slave hardware changes.
This document describes:
| Architecture: | Intel PIII | |||
| Hard drive: | Maxtor 98196H8 | on ide0 as master | (/dev/hda ) | |
| or | ||||
| Maxtor 4K080H4 | on ide0 as master | (/dev/hda ) | ||
| CD-ROM drive: | any IDE drive | on ide1 as slave | (/dev/hdd ) | |
| MAC Address: | This should be listed in the | dhcp information on the master | ( FILE /etc/dhcp.conf ) |
cvs -d :pserver:anonymous@gravity.phys.uwm.edu:/usr/local/cvs/medusa
login
cvs -d :pserver:anonymous@gravity.phys.uwm.edu:/usr/local/cvs/medusa
co clone
The password for user anonymous is medusa.
If something goes wrong during the cloning process, the cloning script will beep at you, print an error message, and drop you into a shell, from which you can try to debug the problem. Obviously this will require a keyboard and monitor. During the cloning process, data is being written to a file called /tmp/clone.log. This is a good place to start the debugging process.
The cloning CD has two vital components to it: a compressed cpio archive node.cpio.gz of the node filesystem to be cloned, and a bootloader directory isolinux. (It also has a src directory containing sources for the custom cloning scripts, but these are not used directly.) ISOlinux is a syslinux-based bootloader that is designed to boot off of an ISO9660 filesystem. Its directory contains the bootloader executable isolinux.bin, several configuration files, a linux kernel vmlinuz compiled with initial ramdisk (initrd) support, and an image of the root filesystem initrd.img that will be loaded onto the initial ramdisk. When the machine boots, the following takes place:
Once this is done, the init program will periodically check whether the CD has been removed from the drive, and will shut down if it has. Of course since all important filesystems have been unmounted, there's nothing to stop you from closing the drive and performing a hard powerdown.
During the cloning process, reading and writing the partition tables
becomes important to test drive and file system integrity. sfdisk
is used for this purpose. The following command will dump the partitions of
a device to a file:
sfdisk -d /dev/hda >
/tmp/hda.out
This information (/tmp/hda.out) can then be used to compare a
known model of a drive, with the drive during the cloning process. If the
drive passes a series of tests, then the /data
partition can be preserved.
The cpio archive was created during the kickstart process by the following commands:
cd / /usr/bin/find . -xdev | cpio -o --format=crc > /data/node.cpio /bin/gzip /data/node.cpioThis clones only the contents of the root partition, which should be all that you want. There should be no need to do this if you kickstarted the node following the instructions above.
Making a slave reclone itself over the network is a simple process. There should be two files on medusa at /root/clone_image/node.cpio.gz and /root/clone_image/CLONE_CD_VERSION . The file /root/clone_image/CLONE_CD_VERSION will tell you what the version is of the latest filesystem image, assuming that it was properly updated by the last person making the current filesystem image.
To reclone a specific slave, log into the master and issue the following commands(where XXX is the number of the slave you wish to rebuild):
rsh sXXX "/sbin/lilo -R ramclone" rsh sXXX "shutdown -r now"This will reboot the slave, and upon reboot, select the "ramclone" lilo image. This lilo image will start the network cloning process. During this time, it will be transferring a large file to itself from medusa. As a result, it will take a few minutes. In a pinch, you can loop these commands. HOWEVER, be warned that if you reboot too many machines at once, communication on medusa's internal network will slow down tremendously. If you want to reclone many machines over the network at once, please use the reclone_all.bash script described below, which has the right delays built into it to avoid any problems.
The cloning process has two vital components to it: a compressed cpio archive node.cpio.gz of the slave filesystem to be cloned, and a ramdisk bootloader. When the machine boots, the following takes place:
Previous slave tests for 6.2 system: