Re: Transplanting old System to New Drive
Hi Martin,
As luck would have it, I did just that this weekend. Except that my
system used lvm for all partitions, which massively simplified the
procedure for me.
Martin McCormick (martin@x.it.okstate.edu on 2011-08-14 21:32 -0500):
> I have a 10-gigabyte hard drive that sounds like a 747
> just before takeoff so the time has come to replace it. I
> replaced it with a 16-gigabyte SATA flash drive and IDE adaptor
> as the system it runs on is a little too old to handle a large
> drive.
Flash drives have different requirements on alignment and block
size than spinning disks, because of their limited erase cycles. You're
probably better off creating a new partition table. Then again, the
jury's still out on whether drive longevity is a real issue.
>
> If I use dd to copy the 10-gig drive over to the new
> drive as in:
>
> dd if=/dev/hda of=/dev/hdb bs=20M
Sure, but then you'll run into issues with partitioning. You can only
resize the last partition on the disk. How many partitions were on the
original disk?
> it works when I remove the old screamer drive, change the jumper
> on the new drive to Master and boot but this is not very
> efficient as it wastes almost 6 gigs of drive.
>
> What I tried to do was to format /dev/hdb with hdb1
> being around 15GB and then /dev/hdb2 being extended and holding
> hdb5 marked as swap just like /dev/hda. /dev/hdb1 is also set to
> bootable and shows up as such when using fdisk /dev/hdb and
> then the p command.
# dd if=/dev/hda of=/dev/hdb bs=512 count=1
or
# sfdisk -d /dev/hda | sfdisk /dev/hdb
would only copy the partition table to the new disk (assuming MBR
partitioning of course). Then you can use any other partitioning tool
to resize the partitions without caring for the data just yet.
Second: if you're using less than 4 partitions, there is no need for an
extended partition. Just using hdb1 and hdb2 will be fine.
> The rsync command tries to copy everything on the old
> disk except /proc and it also fails to copy those files which
> probably never stay around such as timer values and other
> volital information so /dev and everything else get copied.
For 1:1 pristine copies, I recommend using just tar:
# tar cv --one-file-system . | tar xC /mnt
will recreate the current directory in /mnt. Assuming you have already
mounted your new partition in /mnt and your PWD is /, that will
transfer your complete root filesystem to the new disk, excluding any
other mounts (proc, sys, dev, tmp).
>
> When I boot the efficiently-built system, it does start
> to boot and then hangs.
At a guess: it hangs at either "LILO" or "GRUB loading..." ?
You probably need to reinstall your bootloader after changing
partitions. But you did not give the error message, nor which
bootloader you were using (lilo, grub-legacy, grub-pc?). Like another
respondent has said, if you did any formatting (mkfs.*) then you might
need to change /etc/fstab accordingly.
> Is there a way to copy the working file system to a
> larger drive such that the new drive will also boot?
There is. But what you need to do differently depends on where it
failed and what the error message was.
> I even tried to use the dd method and then tune2fs but I
> either did something wrong or this can't work because I still
> had only a 9.6G file system when all was said and done.
tune2fs will not resize your partitions, you need a partitioning tool
for that (followed by resize2fs). And if you did the dd-per-partition,
then only resize2fs should suffice.
Regards,
Arno
Reply to: