Re: transfering linux system to another hard drive

["L. C. Robinson" <lcr@onewest.net>]

On Tue, 4 Dec 2001, Tommy Moore wrote:

> Nope if you make the new partition on the second drive and copy
> data from the first all you do is boot in with boot disk when
> you changed hdb to hda and run lilo.  Have done this multiple
> times and it's always worked.

I agree with this outline, with a few details added.

> you may need to acc [add?] lba32 to the top of lilo.conf so
> that it'll work with all drives but once you've done that you
> should be set to to go.

This only applies to recent systems.  The lilo documentation
says: "Use of LBA32 is recommended on all post-1998 systems" (the
standard was adopted in 1998).  These systems must be able to
"use the Enhanced BIOS packet calls".  Many old BIOSes can only
boot from the first 1024 cylinders.  One solution is to make the
first partition within that space, for a small boot partition,
containing the /boot directory.  10 or 20 megs should be more
than you would ever need.  Just enough for the kernels (old and
new), and the bootloader map files, etc.  If you find that your
BIOS can boot with the new extended standards and a recent
version of lilo (see the lilo documentation), this is not
necessary.  Another solution is to boot with LOADLIN instead of
LILO.

> I'd rather spend 5 minutes doing this than to spend 20 doing a reinstall.

Indeed.  Once the system is working, one can do a normal upgrade.
 
> You can't do this on a running system though you have to do
> this from boot and root disks.

Well, you can do it on an new, unmounted drive, on a running
system.

> Just fdisk the new drive the way you like and format new partition and 

And the "format" command is really a mkfs (make filesystem)
command for your choice of filesystem types (probably mkfs.ext2).
But you probably knew that.

> then mount the drives on different mount points and then do a

> cp -ap .  /new_drive

> from with in the / directory of old drive and everything should
> work. 

I would add the -x option to that (same as --one-file-system, eg.
stay on this file system), or you may have problems with the new
mount point being recursively part of the copy -- kind of a mess.
With the -x option, you will have to copy one partition at a
time, for the old ones.  So the new cp command might be (after
doing a cd to the root of the partition you are copying:

cp -axp *  /new_partition_root_dir/

And don't forget to edit the new /etc/fstab to reflect the new
layout.

> Remember to reboot between the format and fdisk process though.

>From the fdisk man page:

   A sync() and a BLKRRPART ioctl() (reread partition table from
   disk) are performed before exiting when the partition table
   has been updated.   Long  ago it  used  to  be necessary to
   reboot after the use of fdisk.  I do not think this is the
   case anymore - indeed, rebooting too quickly might cause loss
   of not-yet-written  data.  Note  that both the kernel and the
   disk hardware may buffer data.

But then, the cfdisk man page still says:

 W      Write  partition  table  to disk (must enter an upper case W).  Since
        this might destroy data on the disk, you must either confirm or  deny
        the write by entering `yes' or `no'.  If you enter `yes', cfdisk will
        write the partition table to disk and the tell the kernel to  re-read
        the  partition  table from the disk.  The re-reading of the partition
        table works is most cases, but I have seen it fail.  Don't panic.  It
        will  be  correct after you reboot the system.  In all cases, I still
        recommend rebooting the system--just to be safe.

So watch for warnings when you finally write the new table.

And here's a tip from the sfdisk man page:

   For  best results, you should always use an OS-specific
   partition table program.  For example, you should make DOS
   partitions with the DOS  FDISK  program and Linux partitions
   with the Linux sfdisk program.

So you would leave some empty space in the early cylinder part of
your drive for MS-DOS, for later.  Early, because that OS may
balk at being booted from the latter part of a big disk.

Note that some users here may prefer sfdisk, because of it's
total command line orientation, and scriptable behavior.

Now, I know you don't want that old drive to stop when you
reboot, so you would shutdown without the -p (power off) option.
On my system (RedHat), this would mean editing the last line of
the /etc/rc.d/init.d/halt script, to remove that option.  If I
remember right, you run debian, so you would have to look around
a bit, maybe, for an equivalent.  This might not be necessary if
you have set your bios, as I have, to not power off on shutdown,
or if your bios or motherboard do not behave that way.

LCR

-- 
L. C. Robinson
reply to no_spam+munged_lcr@onewest.net.invalid

People buy MicroShaft for compatibility, but get incompatibility and
instability instead.  This is award winning "innovation".  Find
out how MS holds your data hostage with "The *Lens*"; see
"CyberSnare" at http://www.netaction.org/msoft/cybersnare.html