davace
December 29th, 2009, 08:57 PM
This may be common knowledge but it took me many googles to figure out and at the very least, writing it will make me feel better inside.
PROBLEM: Copying partitions also copies the UUID which may subsequently cause problems with GRUB if it is using UUIDs to recognise your root partition.
DETAIL:
I wanted to move my existing Ubuntu install to a new hard drive.
I used a GParted boot CD/DVD (or was it just Parted?) to copy my original root partition from my old hard-drive, to a new one. I then resized it to take up the majority of the new drive. (The shortcut version - this copies the UUID too!)
The problems started when I was trying to get GRUB to boot my new hard drive. After much troubles I found that the two partitions have been given THE SAME UUID during the copy - which may make sense in some circumstances, but not in mine, where I wish to continue using the old root partition.
I learned by plugging and unplugging hard drives from my motherboard that if I only connected my new hard drive (with the copied partition) then everything would work - Ubuntu/linux would boot from the new partition. But when both 'new and old' hard drives were connected (even though the 'old' drive was connected to the second SATA slot (or hd1 when verified through GRUB) the kernel would still use hd1 (and not hd0) as the root drive! Interestingly "mount" would still show that /dev/sda1 was mounted on / - even though it was infact /dev/sdb5 (as verified by mounting /dev/sdb5 to /mnt)
Once I (eventually) figured out that both partitions were given the same UUID it was very easy to change one of them (use tune2fs and uuidgen - I would recommend changing the UUID of your old partition) and then everything works fine - presuming that (as I had already) you have ensured grub works on your new hard drive too. (When first confronted with something called a UUID - I just presumed it was a manufacturer number (it sounds so official :)
Anyhow - really pesky thing to figure out, so I wanted to make some noise about it so that hopefully others with the same problem might hear it. As for "who should fix this" I won't even pretend to know :).
Mostly I am hoping that either... this is really easy for others with the same problem to find in a web search, and save time... or, this is fixed sometime soon - even a system halt/pause & warning during boot-up would be better (hard drive repartitioning/rearranging just doesn't happen that often).
Cheers,
David
PS
The (stranger) symptoms:
* mount command would say that /dev/sda1 was mounted on / but I could mount /dev/sdb5 and access the same drive that was visible on /. However, if I then opened GParted, it would show /dev/sda1 as the drive that I expected it to be, that is, the drive which GRUB recognised as hd0.
* using vol_id showed TWO DIFFERENT id values for the drive IDs - I have NO idea where the second number came from - although admittedly one looked "formatted with hyphens and everything" and the other did not.
PROBLEM: Copying partitions also copies the UUID which may subsequently cause problems with GRUB if it is using UUIDs to recognise your root partition.
DETAIL:
I wanted to move my existing Ubuntu install to a new hard drive.
I used a GParted boot CD/DVD (or was it just Parted?) to copy my original root partition from my old hard-drive, to a new one. I then resized it to take up the majority of the new drive. (The shortcut version - this copies the UUID too!)
The problems started when I was trying to get GRUB to boot my new hard drive. After much troubles I found that the two partitions have been given THE SAME UUID during the copy - which may make sense in some circumstances, but not in mine, where I wish to continue using the old root partition.
I learned by plugging and unplugging hard drives from my motherboard that if I only connected my new hard drive (with the copied partition) then everything would work - Ubuntu/linux would boot from the new partition. But when both 'new and old' hard drives were connected (even though the 'old' drive was connected to the second SATA slot (or hd1 when verified through GRUB) the kernel would still use hd1 (and not hd0) as the root drive! Interestingly "mount" would still show that /dev/sda1 was mounted on / - even though it was infact /dev/sdb5 (as verified by mounting /dev/sdb5 to /mnt)
Once I (eventually) figured out that both partitions were given the same UUID it was very easy to change one of them (use tune2fs and uuidgen - I would recommend changing the UUID of your old partition) and then everything works fine - presuming that (as I had already) you have ensured grub works on your new hard drive too. (When first confronted with something called a UUID - I just presumed it was a manufacturer number (it sounds so official :)
Anyhow - really pesky thing to figure out, so I wanted to make some noise about it so that hopefully others with the same problem might hear it. As for "who should fix this" I won't even pretend to know :).
Mostly I am hoping that either... this is really easy for others with the same problem to find in a web search, and save time... or, this is fixed sometime soon - even a system halt/pause & warning during boot-up would be better (hard drive repartitioning/rearranging just doesn't happen that often).
Cheers,
David
PS
The (stranger) symptoms:
* mount command would say that /dev/sda1 was mounted on / but I could mount /dev/sdb5 and access the same drive that was visible on /. However, if I then opened GParted, it would show /dev/sda1 as the drive that I expected it to be, that is, the drive which GRUB recognised as hd0.
* using vol_id showed TWO DIFFERENT id values for the drive IDs - I have NO idea where the second number came from - although admittedly one looked "formatted with hyphens and everything" and the other did not.