Jump to content

How to copy your disk to a larger one


banjo
 Share

Recommended Posts

Shortly after I installed Mandrake 9.1 my hard disk began

making a squealing noise as it spun up. This made me

skeptical about the longevity of the drive, so I bought

a new, larger disk to replace it.

 

Since I was also unhappy with the size of the root directory and

the way it was partitioned by the Mandrake install, (it was almost

full already), I decided to partition the new disk differently.

 

I was moving from a 40 Gig Western Digital to a 120 Gig Maxtor.

 

Cloning the disk was not an option because of the change

in size and partition table, so I did some research

and decided to copy the old disk to the new one manually.

 

This is the way I copied the disk. I wrote this in the

hope that someone may find it useful. I used generic *nix

tools to do this, so it should work on just about any

distro you have.

 

How to copy the Linux disk to a new, larger disk.

 

***************************************

 

Here are the major steps I performed to do this task.

 

1. Obtain The Required Materials

2. Install The New Disk in the Computer

3. Partition The Disk

4. Make File Systems On The New Disk

5. Copy Files From Old Disk To New Disk

6. Swap The Disks

7. Fix LILO to make it bootable

8. Boot the new disk

 

 

***************************************

Obtain Required Materials

***************************************

 

I bought a copy of Knoppix from

http://www.edmunds-enterprises.com/ to use as

a rescue Linux.

 

You can use any rescue disk you want to as long as

it has utilities like cfdisk, cp, mke2fs, etc.

I chose Knoppix because of its ease of use and

reputation for reliability.

 

I bought a new hard disk.

I got a Maxtor 120 Gig drive. They just keep

getting bigger. 97 bucks OEM.

 

***************************************

Install The New Disk

***************************************

 

I installed new drive as slave on IDE0. The

goal is to copy the files from the old disk on

/dev/hda to the new disk on /dev/hdb.

 

I booted the computer to Setup and confirmed that the BIOS

had seen the new disk. Then, I set the boot priority

to boot from the ATAPI drive so that I could boot

Knoppix.

 

I booted to Knoppix. This left both /dev/hda (the original

disk) and /dev/hdb (the new disk) unmounted.

 

***************************************

Partition The New Disk

***************************************

 

The old partition setup was

 

part1 / 5.8 Gig

part2 extended

part5 swap 0.5 Gig

part6 /home 31.0 Gig

 

One problem was that the root partition had

all of root on it, and it was already 66% full.

So I decided to partition the new, larger disk

differently. Here is the new scheme:

 

 

part1 / 6 Gig

part2 extended

part5 swap 0.5 Gig

part6 /home 88.5 Gig

part7 /usr 25 Gig

 

On the old disk, /usr contains most of the files in root.

So I moved it to its own partition and made it

bigger. I did that instead of simply making / bigger

to avoid any problems with the 8 Gig limit for CMOS

access at boot time.

 

The new disk showed up as /dev/hdb and empty.

 

I used cfdisk to partition /dev/hdb. Cfdisk is a

curses based version of fdisk. It works great.

 

*************** NOTE *********************

Make sure that you are partitioning the correct disk.

You do not want to be changing the partitions on the

original disk.

*************** NOTE *********************

 

I ran cfdisk against the new, virgin disk and got:

> cfdisk /dev/hdb
No partition table or unknown signature on partition table
Do you wish to start with a zero table [y/N] ?

 

I answered "yes" and I was presented with an empty partition

table and a menu at the bottom of the screen. Here is an example of one

of the menus.

 

      [Bootable]  [ Delete ]  [  Help  ]  [Maximize]  [ Print  ]  [  Quit  ]  [  Type  ]
     [ Units  ]  [ Write  ]

 

Use the arrow keys to highlight the desired function and type

the Enter key to perform the function. You will be prompted

for the appropriate types and sizes. Make sure to toggle

the Boot flag ON for the primary partition, hdb1.

 

I created one [Primary] partition and three [Logical] partitions.

Cfdisk named the partitions for me, and I did not have to create

the extended partion, hdb2, which contains the three logical

partitions.

 

I had to create the partitions in the proper order to get them numbered

with the appropriate numbers. I wanted the numbers to match the original

numbers to minimize changes to /etc/fstab. In this case, the only

change will be the addition of hdb7 for the /usr directory. So, I

created them in the following order:

 

/

swap

/home

/usr

 

 

Here is the result of my efforts as displayed by cfdisk

                                          cfdisk 2.11x

                                      Disk Drive: /dev/hdb
                               Size: 122942324736 bytes, 122.9 GB
                      Heads: 255   Sectors per Track: 63   Cylinders: 14946

   Name           Flags         Part Type     FS Type             [Label]            Size (MB)
-------------------------------------------------------------------------------------------------
   hdb1           Boot           Primary      Linux                                    5996.23
   hdb5                          Logical      Linux swap                                501.75
   hdb6                          Logical      Linux                                   90001.02
   hdb7                          Logical      Linux                                   26436.05

 

I then selected [Write] from the menu and answered "yes" when

asked if I really wanted to write the partition table.

After the partition table was written to the disk

the new partitions showed up in /dev.

 

/dev>ls hdb*
hdb@  hdb1@  hdb2@  hdb5@  hdb6@  hdb7@

 

Notice hdb2, which is the extended partition created to

hold the logical partitions, 5, 6, and 7.

 

Here is more detailed information.

 

~>cat /proc/partitions
major minor  #blocks  name     rio rmerge rsect ruse wio wmerge wsect wuse running use aveq
  3    64  120060864 ide/host0/bus0/target1/lun0/disc 6 26 48 80 0 0 0 0 -2 4304870 34340012
  3    65    5855661 ide/host0/bus0/target1/lun0/part1 0 0 0 0 0 0 0 0 0 0 0
  3    66          1 ide/host0/bus0/target1/lun0/part2 0 0 0 0 0 0 0 0 0 0 0
  3    69     489951 ide/host0/bus0/target1/lun0/part5 0 0 0 0 0 0 0 0 0 0 0
  3    70   87891583 ide/host0/bus0/target1/lun0/part6 0 0 0 0 0 0 0 0 0 0 0
  3    71   25816423 ide/host0/bus0/target1/lun0/part7 0 0 0 0 0 0 0 0 0 0 0

 

 

***************************************

Make File Systems On The New Disk

***************************************

 

The next step is to make file systems on the

new disk partitions.

 

********************* NOTE *********************

Be EXTREMELY careful to make the new file systems

on the new disk. If you inadvertently make new file

systems on the original disk, all of the data on the

disk will be lost, and it doesn't ask, and there is no

undo! If you are nervous about this, install *only*

the new disk for this part and then shut down and

install the original disk for the copies.

********************* NOTE *********************

 

The new disk is still installed as /dev/hdb, so

we must make the file systems there.

 

Use mke2fs on each partition

 

Options

-j creates the ext3 journal

-c checks for bad blocks

-L <name> labels the file system

/dev/hdb* is the target partition

 

> mke2fs -j -c -L /  /dev/hdb1
> mke2fs -j -c -L /home /dev/hdb6
> mke2fs -j -c -L /usr  /dev/hdb7

 

If you use the -c flag, this will take a long

long time. I don't know exactly what it does or

how important it is since I am using a journaled

version of the file system. Just be prepared to

spend an hour or so doing this if you are checking

for bad blocks.

 

***************************************

Copy Files From Old Disk To New Disk

***************************************

 

Once the new file systems are in place, you can copy

all of the files from the original disk onto the new

one.

 

I did the file copy using Knoppix so that the

old disk will be mounted read-only. This should

minimize any accidents causing files being written

to the old disk by mistake as I am copying them over.

 

make mountpoints for new and old root directories:

> mkdir /mnt/newroot
> mkdir /mnt/oldroot

 

These mount points exist only in the RAM disk

of Knoppix, so they must be recreated each

time you boot Knoppix.

 

mount the root partiions

> mount -w /dev/hdb1  /mnt/newroot
> mount -r /dev/hda1	/mnt/oldroot

 

Some of the directories do not need to be copied,

so I just made those directories on the new disk, i.e.

 

/home which will be on a separate partion

/proc which contains only pseudo files

/tmp which should be empty

/usr which will be on a separate partition

 

>mkdir /mnt/newroot/home
>mkdir /mnt/newroot/proc
>mkdir /mnt/newroot/tmp
>mkdir /mnt/newroot/usr

 

Because I am moving /usr to its own partition on

the new disk, I did not want to copy it from

the old disk onto the new one. I wanted to copy all

of the directories other than /usr. To do that,

I copied them one at a time from the old to the new.

 

I could not figure out how to tell cp to skip

/usr. There must be a way. But I did them all one

by one anyway. There are not that many. Here is

an example of the commands I used:

 

> cp -pax /mnt/oldroot/bin /mnt/newroot/bin

 

Options:

p means preserve the ownership, timestamps etc

a means archive, same as dpR

d means do not dereference links

R means recursive copy

x means stay on this one file system

 

That command both makes the new directory and also

copies all of the contents over to the new one.

I copied all of the relevant root directories to

the new disk:

 

> cp -pax /mnt/oldroot/boot /mnt/newroot/boot
> cp -pax /mnt/oldroot/dev /mnt/newroot/dev
> cp -pax /mnt/oldroot/etc /mnt/newroot/etc
> cp -pax /mnt/oldroot/initrd /mnt/newroot/initrd
> cp -pax /mnt/oldroot/lib /mnt/newroot/lib
> cp -pax /mnt/oldroot/mnt /mnt/newroot/mnt
> cp -pax /mnt/oldroot/opt /mnt/newroot/opt
> cp -pax /mnt/oldroot/root /mnt/newroot/root
> cp -pax /mnt/oldroot/sbin /mnt/newroot/sbin
> cp -pax /mnt/oldroot/var /mnt/newroot/var

 

Once the root directories have been created and copied,

the mount points for /home and /usr exist on the new disk.

So mount and copy the other two partitions.

 

Knoppix mounted /mnt/oldroot/home automatically

when I mounted /mnt/oldroot. I don't know why.

If it does not do that, just mount it yourself,

readonly, like this:

 

> mount -r /dev/hda6 /mnt/oldroot/home

 

Mount the new file systems and copy

> mount - w /dev/hdb6 /mnt/newroot/home
> cp -pax /mnt/oldroot/home /mnt/newroot
> mount - w /dev/hdb7 /mnt/newroot/usr
> cp -pax /mnt/oldroot/usr /mnt/newroot

 

I left the usr and home names off the destination

path because if I put them there, cp would create

new directories by that name in the existing ones,

and I would end up with /mnt/newroot/home/home and

/mnt/newroot/usr/usr.

 

The above commands took quite a while to

complete. More than half an hour each.

 

Since I have changed the way the / directory is

partitioned, I needed to modify the /etc/fstab

to mount the new partiton.

 

edit /mnt/newroot/etc/fstab and make it mount the

new /usr partition.

 

Here is the current fstab:

 

/dev/hda1 / ext3 defaults 1 1
none /dev/pts devpts mode=0620 0 0
/dev/hda6 /home ext3 defaults 1 2
none /mnt/cdrom supermount dev=/dev/scd0,fs=auto,ro,--,iocharset=iso8859-1,codepage=850,umask=0 0 0
none /mnt/floppy supermount dev=/dev/fd0,fs=auto,--,iocharset=iso8859-1,sync,codepage=850,umask=0 0 0
none /proc proc defaults 0 0
/dev/hda5 swap swap defaults 0 0
/dev/sda1 /mnt/flasha vfat noauto,user 0 0
/dev/sdb1 /mnt/flashb vfat noauto,user 0 0

 

I needed to add:

/dev/hda7 /usr ext3 defaults 1 2

 

Notice that this mounts /dev/hda7, not /dev/hdb7.

Once I make the new drive master, it will become

/dev/hda. Here are the meanings of the options.

 

defaults adds the following options

rw, suid, dev, exec, auto, nouser, and async.

1 means that dump(8) should dump this file system

2 means the fsck(8) checks the file system on second pass

 

 

************** IMPORTANT **********************

Unmount all of the disks to flush out the files.

************************************************

 

> umount /mnt/oldroot
> umount /mnt/newroot/usr
> umount /mnt/newroot/home
> umount /mnt/newroot

 

Shutdown Knoppix and turn off the power.

 

***************************************

Swap The Disks

***************************************

 

Unplug the IDE cable and power plugs from both disks.

 

Jumper the new disk to be IDE master.

 

Plug the IDE cable and power plug into only the new disk.

 

************** IMPORTANT **********************

By swapping the disks before fixing the MBR

with lilo, you won't have to edit lilo.conf

to get the MBR installed onto the correct disk.

 

Apparently the boot=/dev/hda in /etc/lilo.conf

tells lilo where to *store* the new MBR as well

as where to get it at boot time. If you leave

lilo.conf the way it was on the old disk, lilo

puts the new MBR onto /dev/hda, which must be the

new disk if you want it to boot.

************************************************

 

***************************************

Fix LILO

***************************************

 

Boot the computer using Knoppix.

 

The new disk is now recognized by the BIOS

as /dev/hda.

 

> mkdir /mnt/newroot
> mount -w /dev/hda1 /mnt/newroot
> mount -w /dev/hda6 /mnt/newroot/home
> mount -w /dev/hda7 /mnt/newroot/usr
> cd /mnt/newroot
> sbin/lilo -v -v -r /mnt/newroot

 

The options mean:

-v make this verbose

-v make this even more verbose

-r chroot to the /mnt/newroot directory before

running lilo

 

I used the version of lilo on the new disk

(relative addressing... no / before sbin)

 

> umount /mnt/newroot/usr
> umount /mnt/newroot/home
> umount /mnt/newroot

 

 

Shutdown Knoppix.

 

Fix the BIOS to boot first from the primary

IDE disk.

 

Boot the computer.

 

The computer should come up with a copy of the

system you had previously, but on the new disk.

 

 

***************************************

What really happened.

***************************************

 

Of course, this project did not go as cleanly as

I describe it above. In fact, I did the thing three times

before I got it right.

 

The first time I tried, I fixed LILO with the new disk

still installed as /dev/hdb, thinking that the -r /mnt/newroot

would cause the lilo compiler to install the MBR onto /dev/hdb.

Not so. In fact, it went onto /dev/hda. Then,

when I tried to boot the new disk, my computer went through

the BIOS POST and then........... nothing........ the

black screen of death! Of course what had happened was

that there was no MBR on the new disk at all. It had been

written to the old disk.

 

I ran out of time and reinstalled the old disk

(which still managed to boot somehow). Days later I

figured out what had gone wrong, so I hooked up the new

disk as /dev/hda and fixed LILO. After that, it booted

fine.

 

However, we had added files and changed files

on the old disk. The new disk was no longer an accurate

copy. So, to capture the changes, I decided to

do the copies over again.

 

I hooked up both disks and copied the /bin directory

again. But then when I did a du on the new /bin it was

twice the size of the old one. I tried another directory

using the following copy command:

 

> cp -ax --backup=none /mnt/oldroot/var /mnt/newroot/var

 

to make sure that no backup copies were being made

on the new disk.

 

That also resulted in a var directory that was twice the

size of the original. Obviously, the original files I

had copied before and the new copies were both on the

new disk. This must be a function of the journaled file

system, but I did not want to leave it that way. I wanted

to start the new disk with a copy that was as close as

possible to the original one.

 

I decided to start over again by making new file systems

on the old disk and doing the copies again. A couple

of weeks went by before I got around to it.

 

I booted to Knoppix again with both drives installed,

and did the command

 

> mke2fs -j -c -L /	/dev/hdb1

 

I watched this cook for over 20 minutes and it still was not done.

Knoppix was hung up, and there was no cursor or mouse

action. I could not ctrl-c out of the process. This did not

happen when I made the file systems on the empty partitions.

 

So I reset the computer.

 

I got around the problem by leaving out the check for

bad blocks when I made the new file systems.

I made the file systems using:

 

> mke2fs -j -L /  /dev/hdb1
> mke2fs -j -L /home /dev/hdb6
> mke2fs -j -L /usr  /dev/hdb7

 

This took only a few minutes, and it did not hang the

computer. I do not know what effect this will have on

the future of the file systems, but I am typing this onto

the new disk, and it seems to work OK.

 

After making the file systems again, I reaccomplished

all of the copies in the same way I did it before.

Then, I shut down the computer and swapped the disks.

I fixed LILO and booted from the disk.

 

LILO worked fine. Linux came up, but with lots of

errors, which went by too fast for me to tell what

they were. Then, it dropped me into a console login

instead of my normal KDE startup.

 

After a few minutes of cogitation, I realized that

I had not fixed /etc/fstab this time. This made /usr

just an empty directory. So, I booted into Knoppix

again and added the mount of the new /usr partion.

I rebooted the computer from the new disk, and it ran.

 

That's the real story. If you follow the instructions

in the first half of this saga, and you leave

nothing out, and you make no mistakes, you should end

up with a bootable disk in two or three hours.

 

If you do it the way I did it, complete with brain

cramps and poking around in the dark, it will take

a few weeks.

 

I hope this writeup is not too long. I wanted to include all

the details so that it can provide some answers for

those who have not yet been through this. I learned a

lot about what is on my disk and how to maintain it,

and that is the point of running Linux instead of

fnWindows. I own it; it does not own me.

 

Happy computing to all.

 

Linux rocks!

 

Banjo

(_)=='=~

Link to comment
Share on other sites

Good work, just some quick notes.

 

1) you can do everything without a live cd, just by booting your regular Mandrake. All the tools are there. Use cp -apx in your root dir to the mounted partition of the new drive and all is fine. Yes this works also if your root partition is mounted read-write, just let the process do its thing.

 

2) you can set up lilo in a way that it gets installed on hdb with the proper cylinder info (or whatever pointer info it uses) for the hdb boot partition BUT as if hdb is hda, meaning: it prepares for the fact that the location of the image (vmlinuz) is currently on hdbx but will later be on hdax, same for the mbr - it will go onto your new hdb drive. So after shutdown, swapping the drives, and reboot, you are fully done.

I will see if I can find a link to this article/howto on lilo... Found it: http://tldp.org/HOWTO/LILO-4.html

(tlpd, why didn't I think of that first but let google find it for me..?)

 

3) the times that 8GB was the limit have gone since LBA was enabled on harddrives/motherboards. Only if your system counts in CHS: Cylinders, Heads and Sectors (in the BIOS) will you have this 8GB limit. Check my install page on my site - I happily have 3 8GB partitions on my new 160GB drive that can all serve as root (yes, I just throw everything into 1 big partition, except /home - have been accused to be a complete beginner due to that, ah well) and be booted fine with lilo.

 

So if you follow the above advice with some minor modifications that I hint at here, you will only have 1 single (shutdown and swap drives and) reboot, and no need for any (slow and possibly, at the moment you got and wanted to use your new drive, unavailable) live-cd or so.

 

 

Note: if the lilo-thing (from hdb but for configuration as hda) is too hard, you can just omit using lilo, just make sure you have adapted lilo.conf in the exact way that it matches the situation when hdb is used as master/hda. Delete any files in /boot on hdb that are lilo.images (they are called boot002 or boot003 - doing this from memory, will find the exact names as soon as I'm on my own machine). Then shutdown, swap drives, boot from Mandrake installation cd, do 'rescue', then do: repair bootloader. If it does not find any lilo mbr image in /boot, it will use the /etc/lilo.conf file to put things into the mbr AND create this /boot/boot002 (?) image. If however, it does find these boot00n images, it will use that, so if you hadn't deleted them, it will put that into the mbr, most likely with the right pointers for your OLD hard drive....

Link to comment
Share on other sites

Thanks for the extra tips and pointers.

 

The reason that I booted from a rescue disk was to avoid

trying to copy files from the old disk as they were

being changed. I guess I have spent too many years with

ill-behaved OS's (like fnWindows) which are *always* hitting

the disk. I guess it will work OK with Linux.

 

I kind of figured that the 8 Gig was not an issue, but then

I didn't know how to confirm that on my particular BIOS.

Putting it all into one partition would have been simpler,

but then I would not have had the joy of my long, strange

trip. :wall::lol2:

 

The funniest thing is that after I did all of this, my "disk

noise" is still there.......... so it is just a fan.... after all..... :wall:

 

LOL

 

Oh well. I needed a bigger / anyway.

Maybe I will go figure out how to hook up that

ol' 40 Gig as /home2.... or I could go make a huge

/ on that ol' disk and put /home on the new one......

The possibilities are endless..........

 

Thanks again for the pointer to the HOWTO

 

I will now go and study.

 

Banjo

(_)=='=~

Link to comment
Share on other sites

  • 2 weeks later...

Just an addition, which I forgot to make for a bit: the files in the /boot dir that I mentioned are:

boot.0200

boot.0300

etc.

 

They are images of the lilo that gets written to your MBR, and if you swap harddrives, the information they contain may become incorrect. If you then use the rescue mode of the boot cdrom, the wrong image gets restored (it will likely just do a 'dd' command to put the file back in place), still not getting you the right system. (At least, I think that is what happens.)

 

So you have to make sure there is no such image, then you can use the rescue mode of the installation cd to restore lilo onto your MBR with the right settings from lilo.conf.

Link to comment
Share on other sites

Note: you typically don't want the bootsector, since a new harddrive is usually larger than the old one, and you may want to change partition sizes. Then the vmlinuz image in /boot will not be at the same place as on the old harddrive, and you end up with a non working system...

 

If you want the same hd partitioning, dd is likely the fastest tool.

Link to comment
Share on other sites

Banjo- nice tutorial

While reading your how-to I noticed the comment about the mke2fs command and the -c flag.

What the -c flag does is a scan of the physical surface of the device (i.e. hard drive) to check for bad sectors (You can do the same in Windows Scandisk "thorough"). Also years ago I saw some of the older bioses that had a utility to also do that. IMHO if a person has the time then even new drives it is not a bad thing, if you don't have the time and it's a new drive or one that you are certain has no bad sectors then I wouldn't worry about it too much.

I run a printout of man pages for mke2fs and here is how it describes the -c flag.

 

OPTIONS

 

-c Check the device for bad blocks before creating the file system.

If this option is specified twice, then a slower, destructive,

read-write test is used instead of a fast read-only test.

 

Then I ran a printout of man pages for badblocks and here is the description of it

 

DESCRIPTION

badblocks is used to search for bad blocks on a device (usually a disk partition). device is the

special file corresponding to the device (e.g. /dev/hdc1).

 

Important Note: If the output of badblocks is going to be fed to the e2fsck or mke2fs

programs, it is important that the block size is properly specified, since the block numbers

which are generated is very dependent on the block size in use. For this reason, it is strongly

recommended that users not run badblocks directly, but rather use the -c option of the e2fsck

and mke2fs programs.

 

 

So I hope this info has been of some help or interest. If you want to read the complete man page on the subject just enter the command

 

user@localmachine$ man mke2fs

user@localmachine$ man badblocks

 

and if one wants to run a printout then enter the command

 

user@localmachine$ man mke2fs |lp

user@localmachine$ man badblocks |lp (or where-ever your printer is located ...in my case it's |lpr

 

 

Desire

Link to comment
Share on other sites

  • 4 weeks later...

Desire,

 

Thanks for the information on the -c flag.

 

I have not been back to this thread for a while, so

I hope this question isn't too stale.

 

How much protection is provided by the journaled

file system? For example, if I do not use the -c option,

and then I run into a bad block on the disk, will I gain some

measure of protection from the journal?

 

Anybody have any pointers to some docs about

exactly what the journal does and how it works?

 

Thanks in advance.

 

Banjo

(_)=='=~

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...