Tags:
create new tag
, view all tags
Starting to develop a script (or two) for some work at CFK. See #Purpose.

LATEST UPDATE: See CpCloningScript.

UPDATE: Moved the old approach (R1.2) to DdCloningScriptOld to preserve it more explicitly in case I want to continue with that -- I've since discovered parted which looks like a more fruitful approach. Hmm, well why not just keep this note here saying R1.2 is the old version before you discovered parted? Well, see the next update.

NEXT UPDATE: I've thought about the overall sequence of operations and decided that the "move the clone master drive to the clone target drive and boot with a parted boot / root floppy" approach will overall be the most efficient for most machines (i.e., where the hard drive is not easily removable). I was going to preserve R1.3 with my "reasoning" for this so I tried to "freeze" R1.3 by releasing the edit lock, but when I edited and saved again within a few minutes I was still at R1.3. So, I will preserve my reasoning in this "refactoring" and possibly delete it sometime in the future.

NEXT UPDATE: I decided to attempt the parted approach, ran into a lot of problems that might be due to hardware or my mistakes. See especially Parted#Recent_Experience. I plan to get back into this next week. In the meantime, this page is "on hold".

*NEXT UPDATE: Doing pretty good -- the approach described under #Linc's_Notes does work -- there are a few improvements to be made (discussed there).

See:

Contents

Purpose

Purpose of the script(s):

When the CFK has multiple machines with the same equipment (RAM, hard drive (size), video and sound card, etc.) a more efficient way to install the Vector CFK Linux is by cloning the hard drive from a good installation. (More efficient than doing one-off installs from the installation CD-Rom.) It might be even more efficient to do installs over a network, or clone hard drives over a network ??, and Joe Simpson is looking into at least the first of these) Of course, that approach may require temporary installation of a NIC and will require booting from an appropriate floppy.

Procedure

Refactoring, to switch to the "move the clone master drive to the clone target drive and boot with a parted boot / root floppy"

In more detail, the anticipated procedure is:

  • Create a good install on a hard drive in one machine (the "cloning master machine"). (Assuming a 1.2 GB minimum size hard drive, I plan to make swap (hda1) between 200 MB and 250 MB, and devote about 1 GB to hda2 -- if the hard drive is bigger than 1.2 GB I will keep these sizes the same in order to make the dd process as fast as possible.) Leave lilo set up to boot from hda and test the install.

  • Remove the hard drive from the cloning master and install it temporarily in another machine that needs Vector CFK installed (a "cloning target machine"). If possible, try to avoid changing any jumpers (just to minimize the physical work required) -- oops, this is a flaw in my logic -- I was hoping that by booting from a floppy I would not have to change any jumpers, but I may not be able to avoid that. I think it will be worth some experimentation to try -- maybe (as Jesse has implied / stated) we can make some changes in the bios so both hard drives are recognized.

  • Whatever jumper or bios changes are done, remember them as they will have to be undone at the completion of the procedure.

  • Boot from a parted boot / root set that also contains the scripts (that will be written)

The following is what the script will / should eventually do -- until the script is complete, the following steps must be done manually.

  • Therefore, these assumptions as we boot up: drive to be cloned is hda (i.e., master or "standalone" on first disk controller) probably with a Windows partition or two. Good install is on /dev/hdb (i.e., slave on first disk controller) with swap on hdb1, install on hdb2. (_Hmm, in some cases I could probably minimize jumpering by putting the master clone drive on the second controller, if a cable is already installed or easily added, and make it slave or master depending on whether a CD-Rom (or second hard drive is already installed).

Thus, it sounds like the installer should be prompted to indicate which drive (hdb, c, or d (and maybe even hda) has the clone master (and then we should go the further step of prompting him for which drive is the clone target) -- I might do this eventually, but maybe not to start. But, it shouldn't be that difficult if I write everything using variables for the drives. Guess those could be $CLONE_MASTER_DRIVE and $CLONE_TARGET_DRIVE or some mnemonic abbreviation thereof.

Oops, the install script should also consider the possibility of two hard drives, but maybe we'll hold that until some time in the future. There are a number of possibilities, hopefully they will be simple like make the second hard drive /data or a new /home, which points back to the need for the first script I considered (DdCloningScriptOld, abandoned to take this approach with parted).

  • Run fdisk on the $CLONE_MASTER_DRIVE and run p(rint) to view the partition table. (Assume hdb as $CLONE_MASTER_DRIVE for the first draft of the manual procedure, and stop talking in terms of variables for the manual procedure -- too confusing, IMHO.) Record the appropriate numbers. I'll specify those once I get back to a Linux machine. The script will eventually grep the appropriate numbers and save them as variables for the next step, something like $SWAP_PARTITION_SIZE and $HDX2_PARTITION_SIZE.

  • Use fdisk (or sfdisk) to create two partitions on /hda -- hda1 with same size as hdb1, and hda2 with same size as hdb2. Incidentally, this leads to any data on the Windows partitions becoming inaccessible (or certainly difficult to access), which is one of the requirements on CFK ("wiping" existing data / programs off the hard drive).

  • Alternate considered and rejected: If we made hda2 with all remaining space on drive, and then dd'ed hdb2 to it, would hda2 remain at it's original size after the cloning? If so, that would be a better way to go because we'd save some steps. No, it won't (per Linc Fessenden -- hda2 will "shrink" to the size of the partition copied to it (hdb2).

  • dd hdb1 to hda1 and hdb2 to hda2:

dd if=/dev/hdb1 of=/dev/hda1
dd if=/dev/hdb2 of=/dev/hda2

Aside: Here's how to copy the MBR from one disk to another:

dd if=/dev/hda of=/dev/hdb count=1 bs=512

_Note: That copies the entire MBR which includes the boot loader and the partition table. Under certain circumstances, you may wish to copy the boot loader and not the partition table -- this might be possible by choosing to copy a smaller section -- Linc has tried copying 496 bytes, I've tried copying 446 bytes, and neither of us has been successful so far. There is an alternate approach described under #Linc's_Notes.

Future modification -- I shouldn't have to dd the swap drive -- I should be able to just create it with type swap, then mount it (??), then tell Vector to use it. Currently I'm not sure how to do that, and I'm unsure when I'd tell Vector to use it -- would I have to boot into the new installation first? If so, the dd'ing approach may overall save time. Still, I want to learn the other approach for my own needs, but that will be a future revision to the script. Actually, I'm very close to knowing how to do that -- so I'll consider for a moment -- the steps to create a swap drive from scratch -- wait, I think all I'd have to do is create a partition of type swap at the "expected location" with, for example, parted. If the master image was set up to expect its swap partition at that "expected location", it should already be included in the /etc/fstab. In any case, I don't think I have to do anything like mkfs -t swap ..., or format that area -- I might have to edit fstab. Anyway, for now I'll still leave this as a future modification, then try to do some experimentation.

Note: If you went through this procedure to create a new clone master drive, don't perform the next step (expanding hda2) -- you will need to do this later when you finally put the master in its original machine. The approach is similar, the details may be different and, at least initially, I won't develop those details here. (Really, it amounts to booting the machine with the parted boot / root set and making the changes to hda, might be that the procedure is identical.)

  • If there is any unused space on hda, use parted to resize hdba to use all that free space. (That should be fairly easy -- when I first run fdisk I should record the "end" of hda, now all we do is use parted resize with the same start and the new end.) Add the command (after some more reading of the parted manual).

  • Now we are almost done:
    • shutdown the machine,
    • remove the clone master drive and floppy
    • restore any jumpers to their original condition
    • on reboot, go into setup and restore any bios setting changes to their original condition
    • reboot
    • test

Notes from Linc

Just pasting in some notes from Linc Fessenden and others of the LVLUG which I might be able to incorporate tomorrow:

As I mentioned I was going to try and clone drives by partition and not just bit for bit. I wanted to attempt this to resolve any issues we might have due to differing drive geomotries. Here are the results and the proceedure I followed:

add copy drive as slave
boot machine from floppy
get to prompt #ctrl-c a couple times gets you there
cfdisk /dev/hdb
add 200meg swap on hdb1
add rest linux native on hdb2 # and make bootable
mkswap /dev/hdb1 # 10 seconds
mke2fs /dev/hdb2 # 20-30 seconds for 6gb
tune2fs -j /deb/hdb2 # another 10-15 seconds
mount -t ext3 /dev/hda2 /mnt/linux
mount -t ext3 /dev/hdb2 /mnt/temp
cd /mnt/linux
cp -a * /mnt/temp # copies *ALL* the cfk stuff in under 15 minutes!!
halt
switch so new drive is hda
reboot from floppy: linux root=/dev/hda2
login in as root
open terminal
/etc/lilo
reboot without floppy
all is well with the world and you are done.

Alternatively, you can do a bit for bit copy which takes an hour, or the same length of time doing an install by cdrom (this is only a 133mhz machine after all...) The only horrible part about following the above process is the complete piece of junk I unwittingly picked as a copy box. Any time the drive types change you have to let bios on this thing time out before it'll let fix anything (1-2 MINUTES)... Ick.

<and from dann>
I guess my email to you was unneccessary. But,

/sbin/lilo

And you are golden.

<and from linc again>
You should be able to do a "dd if=/dev/hda of=/dev/hdb bs=496 count=1" but I haven't actually tried it yet. The booter info is contained in the first 496 bytes of the disk even though the entire mbr is 512, the lasst bits contain partition info... One moment while I actually try this.......................................

Oh well, I guess theories don't always pan out smile

RE above: I've tried 446 bytes without success -- Linc thinks the size of the partition table may depend on something else (block size) and is investigating further. I think I'll try some googling, maybe like on [MBR "partition table" boot loader].

Here's an alternate way to install the boot loader in the MBR of a cloned disk without destroying the partition table:

mount -t ext3 /dev/hdc2 /mnt/temp
chroot /mnt/temp /sbin/lilo
umount /mnt/temp

UPDATE: Eventually got the above to work at least once when the target disk (MBR) was hda and the source disk (MBR) was hdc. (IIRC, earlier failures occurred when the target disk was not hda and that intuitively makes some sense (because all the things like fstab use the hda notation) but I can't explain fully.)

NEXT UPDATE: Since writing the above, I did some more reading, and I believe it was in the LILO HOWTO that I found the procedure for doing the chroot trick when the target disk is not hda -- it involves some changes to the lilo.conf file -- in some places you specify hdc (or whatever) and others (IIRC) you specify hda. Also, I've seen at least two web sites that specify the number of bytes for dd'ing the MBR without the partition table as 445 instead of 446 -- maybe that is the key, but probably Joe Simpson is right when suggesting that maybe this can only be done between identical disks, because some of the locations of map files and so forth would be different otherwise, and then something in those 445 (or 446) bytes would point to the wrong place.

Deciding on the Approach

I was thinking about moving hdb2 to the new machine, then booting from a parted boot / root floppy disk set and doing the resizing. Rethinking, I could also install parted (and the necessary libraries, and any scripts I write on hda in the cloning master machine, and resize hdb2 before moving it to the cloning target machine. I'll think about this a bit, because, since I think the other approach (the carry the cloning master drive from target to target is more efficient "mechanically" I'd want to make sure I could do it that way. What are the pluses and minuses of the two approaches:?

Alt 1: Move Clone Target Drive to Clone Master Machine

Pros:

  • Could put parted, its libraries, and my scripts on the master drive -- after the cloning process is complete I could run parted without a reboot (even part of the script) to properly resize hdb2 before removing it for re-installation in the clone target

Alt 2: Move Clone Master Drive to Clone Target Machine

Cons:

  • I need to do something to make the clone target boot from the temporarily installed drive, like:
    • Change jumpers to set the original drive as slave, set the master drive as master, which means I may have to partially uninstall the drive to reach the jumpers, and change them back after the install
    • Modify the image (lilo) on the master to boot from hdb2, but after the install change lilo back to boot from hda2 -- oops wait -- don't think that can work as the MBR is expected on hda (isn't it?)
    • Use a boot floppy that boots to hdb2 to start the cloning process. Advantages -- less screwing around, could have parted, libraries, and my scripts on the same floppy (with a small enough kernel)

Decision (with some discussion first)

On some machines it is fairly easy to remove the hard drive (swing out drive bays, etc.) like the Dells I've recently used. On those, it is tempting to remove the clone target drive and take it to the master.

But, the more common situation will be that the hard drive is not easy to remove, so we should plan for that. And, if the hard drive is difficult to remove, it may be difficult to change jumpers, so I want to avoid that. And, since the lilo approach can't work (AFAICT), I think I'll plan on the "move the clone master drive to the clone target drive and boot with a parted boot / root floppy" approach.

Resources

See ResourceRecommendations. Feel free to add additional resources to these lists, but please follow the guidelines on ResourceRecommendations including ResourceRecommendations#Guidelines_for_Rating_Resources.

Recommended

  • (rhk) makedisk readme; ; - there's some useful stuff at this site, starting with this readme which gives the steps to create a Linux boot disk in dos or Linux

Contributors

  • () RandyKramer - 18 Feb 2003
  • <If you edit this page: add your name here; move this to the next line; and include your comment marker (initials), if you have created one, in parenthesis before your WikiName.>

Page Ratings

Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r9 - 2003-03-19 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look