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