Hi, I need to install a bigger hard drive in my laptop which dual boots Windows & Linux. I was wondering if anyone knows of any gotchas that I should be aware of? What I'm planning to do is to boot from the GParted liveCD and first use dd to clone the original drive with dd if=/dev/sda of=/dev/sdb and then use gparted to resize the partitions. Seems too simple, have I missed something? Glenn -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
2008/8/22 Glenn Ramsey <glenn(a)componic.co.nz>:
Hi,
I need to install a bigger hard drive in my laptop which dual boots Windows & Linux. I was wondering if anyone knows of any gotchas that I should be aware of?
What I'm planning to do is to boot from the GParted liveCD and first use dd to clone the original drive with
dd if=/dev/sda of=/dev/sdb
and then use gparted to resize the partitions.
Seems too simple, have I missed something?
Glenn
That would probably work, but it's not how I'd do it because it is likely to result in your partition table being 'less than ideal' for the new drive geometry. I generally create a new filesystem (with the new drive where it's going to be permanently, and the old drive as slave). Mount the new filesystem as '/target' and the old one as '/source', use cp -a to copy everything over. Then update the UUID's in /target/boot/grub/menu.lst and /target/etc/fstab to match the new filesystem. You can get filesystem UUID's using the vol_id command. Then run grub-install --root-directory=/target. There may be better ways, but this works for me.
From Matt Browne via wlug secretary.
Glenn Ramsey wrote:
Hi,
I need to install a bigger hard drive in my laptop which dual boots Windows & Linux. I was wondering if anyone knows of any gotchas that I should be aware of?
What I'm planning to do is to boot from the GParted liveCD and first use dd to clone the original drive with
dd if=/dev/sda of=/dev/sdb
and then use gparted to resize the partitions.
Seems too simple, have I missed something?
Glenn
If you're copying from a drive smaller than 137GB to one that larger than 137GB you may find the new drive won't boot afterwards if cloned using dd or Clonezilla. From my experience even reinstalling the boot loader doesn't help in this situation. I don't know the exact reason behind this is, but I expect it's due to drives that exceed the 48-bit LBA boundary requiring a slightly different partition layout. A fresh OS install though will boot fine so for Linux partitions at least a cp -a afterwards will do the trick. I'm not aware of a nice way to work around this for Windows partitions. Not sure if this problem still exists with SATA, but I've run into it a few times with PATA drives. Matt Browne
Hello,
From Matt Browne via wlug secretary.
Glenn Ramsey wrote:
Hi,
I need to install a bigger hard drive in my laptop which dual boots Windows & Linux. I was wondering if anyone knows of any gotchas that I should be aware of?
What I'm planning to do is to boot from the GParted liveCD and first use dd to clone the original drive with
dd if=/dev/sda of=/dev/sdb
and then use gparted to resize the partitions.
Seems too simple, have I missed something?
Glenn
If you're copying from a drive smaller than 137GB to one that larger than 137GB you may find the new drive won't boot afterwards if cloned using dd or Clonezilla. From my experience even reinstalling the boot loader doesn't help in this situation. I don't know the exact reason behind this is, but I expect it's due to drives that exceed the 48-bit LBA boundary requiring a slightly different partition layout.
A fresh OS install though will boot fine so for Linux partitions at least a cp -a afterwards will do the trick. I'm not aware of a nice way to work around this for Windows partitions.
Not sure if this problem still exists with SATA, but I've run into it a few times with PATA drives.
A way around this might be to create the partitions on the new drive, and then copy the filesystems. The copied filesystems can then be extended to fill the newly created partitions. The steps for extending an ext2/3 filesystem can be found at http://www.howtoforge.com/linux_resizing_ext3_partitions_p2 I am sure you will be able to find something to deal with your ntfs filesystems in the same way, \ Andreas
Andreas Löf wrote:
Hello,
From Matt Browne via wlug secretary.
If you're copying from a drive smaller than 137GB to one that larger than 137GB you may find the new drive won't boot afterwards if cloned using dd or Clonezilla. From my experience even reinstalling the boot loader doesn't help in this situation. I don't know the exact reason behind this is, but I expect it's due to drives that exceed the 48-bit LBA boundary requiring a slightly different partition layout.
A fresh OS install though will boot fine so for Linux partitions at least a cp -a afterwards will do the trick. I'm not aware of a nice way to work around this for Windows partitions.
Not sure if this problem still exists with SATA, but I've run into it a few times with PATA drives.
A way around this might be to create the partitions on the new drive, and then copy the filesystems. The copied filesystems can then be extended to fill the newly created partitions.
The steps for extending an ext2/3 filesystem can be found at http://www.howtoforge.com/linux_resizing_ext3_partitions_p2 I am sure you will be able to find something to deal with your ntfs filesystems in the same way,
\ Andrea
I did try creating the partitions first and then copying the filesystems themselves last time I ran into the problem, but the new drive still would not boot. I can't complain though, 9 times out of 10 I find dd or Clonezilla does the job fine. Matt Browne
If you're copying from a drive smaller than 137GB to one that larger than 137GB you may find the new drive won't boot afterwards if cloned using dd or Clonezilla. From my experience even reinstalling the boot loader doesn't help in this situation. I don't know the exact reason behind this is, but I expect it's due to drives that exceed the 48-bit LBA boundary requiring a slightly different partition layout.
A fresh OS install though will boot fine so for Linux partitions at least a cp -a afterwards will do the trick. I'm not aware of a nice way to work around this for Windows partitions.
For very large drives, it might help to put /boot on a smaller partition by itself (as used to be necessary with LILO on much smaller 'large drives'). Using my method, you would first create the partitions on the new drive, mount /target then create and mount /target/boot inside that, and then do the copying from the original filesystem.. and of course add a new entry for /boot in /target/etc/fstab.
Bruce Kingsbury wrote:
2008/8/22 Glenn Ramsey <glenn(a)componic.co.nz>:
Hi,
I need to install a bigger hard drive in my laptop which dual boots Windows & Linux. I was wondering if anyone knows of any gotchas that I should be aware of?
What I'm planning to do is to boot from the GParted liveCD and first use dd to clone the original drive with
dd if=/dev/sda of=/dev/sdb
and then use gparted to resize the partitions.
Seems too simple, have I missed something?
Glenn
That would probably work, but it's not how I'd do it because it is likely to result in your partition table being 'less than ideal' for the new drive geometry.
I generally create a new filesystem (with the new drive where it's going to be permanently, and the old drive as slave). Mount the new filesystem as '/target' and the old one as '/source', use cp -a to copy everything over.
Then update the UUID's in /target/boot/grub/menu.lst and /target/etc/fstab to match the new filesystem. You can get filesystem UUID's using the vol_id command.
Then run grub-install --root-directory=/target.
There may be better ways, but this works for me.
Thanks everyone for the advice. Bruce, what is the issue with the partition table? Here's how it went... I was copying from an 80GB drive and I ended up by using clonezilla to clone it onto a 120GB drive in a USB caddy. Then I booted Linux from the original drive and used gparted to move & resize the partitions, using almost the same layout as the original. Then I made the adjustments to the grub menu and fstab as detailed above before swapping the drives. This was suprisingly painless, and there was only one gotcha, which was when I tried to mount the cloned drive from the original it got confused because the UUIDs were the same; uuidgen and tune2fs -U fixed this. Glenn -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
Bruce, what is the issue with the partition table?
Some software (fdisk?) complains about partitions ending halfway across a cylinder, which is quite likely to happen if you dd one drive to another with a different geometry. I don't know exactly why it was considered not a good idea, I'm not even sure if if it's still an issue, but I prefer to create my partitions 'cleanly' with fdisk rather than cloning the layout of a previous drive. There are possibly other reasons why you shouldn't clone drives that way. One you've already found which hadn't thought of is that if you plug the original drive back in at a later time you have multiple partitions with the same UUID, and since Ubuntu relies on UUIDs to recognise partitions this will lead to unpredictable problems. They're supposed to be 'Universally Unique' Identifiers. Having said that, I used to clone drives with dd in the past and it never caused any insurmountable problems...
participants (5)
-
Andreas Löf -
Bruce Kingsbury -
Chris O'Halloran -
Glenn Ramsey -
Matthew Browne