HowTo: Moving Linux from IDE to a SATA drive

Quakeboy02 · 03-09-2007, 01:21 PM

I just moved my IDE boot drive to a SATA drive, so I thought I'd detail the process in case anyone else is interested. This howto uses the simple case of one root partition and one swap partition.

Partitioning the new drive:

First, decide on the amount of swap space you'll need. Subtract that from
the size of the drive and creat the first partition with that size. I'm
using an 80GB drive, and I want about 1GB swap space, so my first partition
will be a 79GB primary Linux partition.

Code:

# fdisk /dev/sda

Code:

n: new partition
p: primary partition
1: partition number 1
1: First cylinder
+79G: Last cylinder or +size (etc)

Now, create the swap partition. First is the extended partition where it resides.

Code:

n: new partition
e: extended partition
2: partition number
<enter>: first cylinder (default)
<enter>: last cylinder (default)

Next is the actual swap partition.

Code:

n: new partition
l: logical partition
<enter>: first cylinder (defaults to first cyl of extended partition)
<enter>: last cylinder (default)

Change the type of the partition created for swap to "Linux swap" type.

Code:

t: change type of partition
5: partition number
hex code: 82 (Linux swap)

List the partition for a look before writing it.

Code:

p:
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
   /dev/sda1               1        9606    77160163+  83  Linux
   /dev/sda2            9607        9729      987997+   5  Extended
   /dev/sda5            9607        9729      987966   82  Linux swap / Solaris

It's what I want, so write it and exit fdisk.

Code:

w:

Copy the MBR from your booted IDE drive to the new SATA drive

Code:

# dd if=/dev/hda of=/dev/sda bs=446 count=1

WARNING: be VERY sure you get the if and of right!!!

Copy the "/" partition to the new drive:

Mount the new root partition

Code:

# mount /dev/sda1 /mnt

Copy the data

Code:

# cp -axu / /mnt

Stop udev so that the "/dev" directory can be copied

Code:

# /etc/init.d/udev stop

Copy the /dev partition

Code:

# cp -axu /dev /mnt

Restart udev

Code:

# /etc/init.d/udev start

Make a swap partition out of /dev/sda5

Code:

# mkswap /dev/sda5

Chroot into /mnt to make double damned sure you don't wack your root for this. Be ABSOLUTELY SURE that you run this command before proceeding!!!

Code:

# chroot /mnt

Change the mount table (/etc/fstab) for the new drive to these values:

Code:

proc            /proc           proc    defaults        0       0
/dev/sda1       /               ext3    defaults,errors=remount-ro 0       1
/dev/sda5       none            swap    sw              0       0

Change /boot/grub/device.map to these values:

Code:

(hd0)   /dev/sda
(hd1)   /dev/sdb

Change the appropriate root sections of the menu.lst file:

Code:

### BEGIN AUTOMAGIC KERNELS LIST
...
# kopt=root=/dev/sda1 ro

title           Debian GNU/Linux, kernel 2.6.19.5-k7
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.19.5-k7 root=/dev/sda1 ro
initrd          /boot/initrd.img-2.6.19.5-k7
savedefault

### END DEBIAN AUTOMAGIC KERNELS LIST

NOTE: change all the /dev/hda1 to /dev/sda1 in the AUTOMAGIC KERNELS LIST
NOTE: leave the hash ("#") in front of "kopt=root=/dev/sda1 ro"

Run grub to fixup a few things. I'm not an expert on this, but it's required or the thing won't boot.

Code:

# grub

Code:

grub> device (hd0) /dev/sda

NOTE: If this responded with an error, check to see that the /dev directory
really was copied, above.

Code:

grub> root (hd0,0)

Code:

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  16 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/boot/grub/stage2
 /boot/grub/menu.lst"... succeeded
 Done.

Code:

grub> quit

Tell grub to do its thing to make it bootable.

Code:

# update-grub
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz-2.6.19.5-k7
Found kernel: /boot/vmlinuz-2.6.19.4-k7
Found kernel: /boot/vmlinuz-2.6.19.3-k7
Found kernel: /boot/vmlinuz-2.6.19.2-k7
Found kernel: /boot/vmlinuz-2.6.18-386
Found kernel: /boot/vmlinuz-2.6.18-4-k7
Found kernel: /boot/vmlinuz-2.6.18-3-k7
Updating /boot/grub/menu.lst ... done

And, it's time for the moment of truth! Reboot the sytem, and change the BIOS so that it boots from your SATA drive. Don't be surprised if a full fsck is run on /dev/sda1 during boot. Also, don't be surprised that a big red "failed" is displayed just before the sytem reboots after the fsck. That's normal.

And, the system should reboot onto the SATA drive. At least, mine did.

dannystaple · 03-09-2007, 06:23 PM

Hmm - interesting.

With the dd method - you might want to use a linux CD in recovery mode and the original drive mounted there as read only - as anything left unsynced, or being written to /var and other things could be problematic.

I tend to use LVM (linux volume manager), so I would probably have attempted to use that to migrate the root fs, and then run grub to put a bootloader on the new drive. LVM means that you can add a partition on the new drive into an existing volume group, and then migrate the old drive contents to it (ensuring there is enough space). A choice part of the LVM guide goes through it:
Removing an Old Disk

Danny

Quakeboy02 · 03-09-2007, 06:31 PM

"With the dd method - you might want to use a linux CD in recovery mode and the original drive mounted there as read only - as anything left unsynced, or being written to /var and other things could be problematic."

I don't understand what you mean. I only used "dd" to copy the MBR.

syg00 · 03-09-2007, 08:05 PM

And I'm not understanding why you did ...
After the chroot, you re-installed grub - could also safely be done without the chroot.
Also, perhaps it should be noted this is very Debian specific re the menu.lst format, and grub-update.

Interesting exercise - I never do this on a running system. A liveCD avoids any issues with the pseudo filesystems (like /dev and /proc).

Quakeboy02 · 03-09-2007, 08:15 PM

"After the chroot, you re-installed grub - could also safely be done without the chroot.

Yes, but I thought it might be better in a sandbox. Personally, I don't know enough about grub to do anything useful, and I didn't want to bork the grub on my other disk. At first, I tried just changing the device.map and menu.lst files, but it wouldn't boot. So, I pulled out the example on the ubuntu DMRAID howto page and just followed the bouncing ball with the grub commands. It worked, so that's what I posted.

"Also, perhaps it should be noted this is very Debian specific re the menu.lst format, and grub-update."

Uh, good point. If a moderator wants to move it to the Debian forum, be my guest. Or this can die here - either way.

"Interesting exercise - I never do this on a running system. A liveCD avoids any issues with the pseudo filesystems (like /dev and /proc)."

I ran across the method of fixing /dev on another thread, so I thought I'd incorporate that here. It was a simple, fun project, and went a lot more quickly and troublefree than I thought it would.

Quakeboy02 · 03-09-2007, 08:21 PM

"And I'm not understanding why you did ... "

Syg00, I don't think I understood what you meant in my earlier post. Did the grub commands I used recreate grub? I thought they did everything but make the MBR. Grub makes me nervous for some reason. I had a working menu.lst with a number of kernels in it that I wanted to have in grub on the new drive. You know how these things go - if you've got a hammer... If you've got a minute, what would have been the "preferred" method of making the new grub and including the list of kernels?

syg00 · 03-09-2007, 08:44 PM

This is Linux - that means choice. I don't like the term "preferred" - what works is good.
However, IMHO restoring sector 0 (MBR for wont of another name) is never desirable. Or needed.

Quote:

Did the grub commands I used recreate grub? I thought they did everything but make the MBR

Exactly the opposite - all you did was update the boot record. So the dd was unnecessary.
All the grub files were already in the (new) grub directory (including the menu.lst). Grub-update merely worked on that (existing) file.

Later: Perhaps I shouldn't have used the term "installed". The product was already installed (hence the grub command worked). Unfortunately that usage is common - grub-install is just a wrapper that does what you did; i.e. grub must be installed for grub-install to work. Confusing, no ... ???

Quakeboy02 · 03-09-2007, 09:20 PM

"Exactly the opposite - all you did was update the boot record. So the dd was unnecessary.
All the grub files were already in the (new) grub directory (including the menu.lst). Grub-update merely worked on that (existing) file."

I don't follow. This was (in theory) a virgin disk. There would be no MBR on it until either grub-install or the "dd" was run, would there?

syg00 · 03-10-2007, 12:59 AM

You had done "cp -axu /dev /mnt" - your disk was virgin no longer.
Running the "root" (to locate the stage files) and "setup" (to update the MBR) commands from within grub wrote the loader code.
That loader code is not required till you boot - the grub commands can be done from a liveCD in need.

Quakeboy02 · 03-10-2007, 01:53 AM

"You had done "cp -axu /dev /mnt" - your disk was virgin no longer."

Well, /dev/sda1 wasn't.

"Running the "root" (to locate the stage files) and "setup" (to update the MBR) commands from within grub wrote the loader code."

Ahh. OK, this is the part I was missing. I thought the setup only modifed the MBR, I didn't understand that it rewrote it with a new one. What I knew was that I had transferred the MBR and had modified the two grub text files but it still wouldn't boot. Unfortunately, I didn't feel up to redoing everything just to test out whether I needed to have loaded the MBR in the first place. So, should I remove that part of the HowTo, the "dd" part? I may eventually go through this again without doing the dd, just to have done it.

Thanks for your help.

dannystaple · 03-10-2007, 07:06 AM

Quakeboy02,
I realised I missed what you were doing with dd, and following this, I think that part is solved. I admit I would still be more comfortable doing the volume migration than a massive recursive cp command. I realise that the cp is preserving timestamps, permissions and links, but how about pseudo filesystems and the like?

For the benefit of anyone reading it, I should mention that my LVM method only works for someone who already got an LVM volume set in use for the root fs.

Danny

Quakeboy02 · 03-10-2007, 12:37 PM

"I realise that the cp is preserving timestamps, permissions and links, but how about pseudo filesystems and the like?"

I have to tell you that this wasn't just an intellectual exercise on my part, left for someone else to test. This is my primary machine, and I am running live on this disk as I type.

J.W. · 03-10-2007, 03:58 PM

Quakeboy - you might want to consider submitting this article as an LQ Linux Answer. LQ tutorials are always available, whereas a thread can very easily get lost in a crowd

Quakeboy02 · 03-10-2007, 04:02 PM

"Quakeboy - you might want to consider submitting this article as an LQ Linux Answer. LQ tutorials are always available, whereas a thread can very easily get lost in a crowd"

J.W.
I'll think about it. But, I think I need to run it again on a blanked drive, taking syg00's comments about grub and dd into account. It sounds like I've got some redundant steps, and if so, I'd like to clean them up. In any case, I'll keep a link to it, so that I can refer to it when it comes up.

dannystaple · 03-11-2007, 06:23 AM

Quote:

Originally Posted by Quakeboy02

"I realise that the cp is preserving timestamps, permissions and links, but how about pseudo filesystems and the like?"

I have to tell you that this wasn't just an intellectual exercise on my part, left for someone else to test. This is my primary machine, and I am running live on this disk as I type.

Point taken - if it worked, then it probably is not a problem. Good work anyway.
It is definitely more generalised than IDE to SATA, but really describes any disk to disk migration, with IDE to SATA as a good use case.