I need to clone a 160GB hard drive with Linux Mint 9 (not more than 10GB used) to a 30GB SSD that is partitioned carefully (aligned to cylinder boundaries) and is currently running Ubuntu (which I wish to overwrite with Linux Mint 9).

The SSD has a /boot partition, / and swap. The source (160 GB) does not have a separate boot partition.

Can anyone help me fill in the steps below? /dev/sdc will be the source (160GB) and /dev/sda is the target (with partitions 1,2 and swap on 5).

1. make a copy of /etc/fstab from the target drive before proceeding.
2. Ready the target partitions. Can I reuse the existing destination partitions on the SSD?
3. Ready the filesystems on each of the target partitions. /boot is ext2, / is ext4 and swap is already set up too. As I said, all contain data (Ubuntu) that I wish to overwrite. So what steps are needed here? Do I need to erase anything (files, etc.) before the copy/clone?
4. next, use dd to copy MBR (right?) And exclude partition table:
   Code:

   dd if=/dev/sdc1 of=/dev/sda1 count=1 bs=446

5. Mount the source and destination drives:
   
   Code:

   mount -t ext4 /dev/sdc1 /mnt/source
   mount -t ext2 /dev/sda1 /mnt/boot_target
   mount -t ext4 /dev/sda2 /mnt/root_target

6. I suppose I can leave the swap partition on the target untouched.
7. Copy the files from the source partition to the destination
   
   Code:

   cp -a /mnt/source/boot /mnt/boot_target
   cp -a /mnt/source/ /mnt/root_target

8. then I assume I go to /mnt/root_target and delete the /boot directory, right?
9. Change /etc/fstab to reflect the new partitions. I mount by label. Will my partition labels be intact after this?
10. Do I have to make any changes to GRUB? Anything else?

You have to do mkswap and swapon -a if you have not done so.
I would prefer rsyncNote the trailing slash in the source path! Using rsync in this way all permissions and attributes are preserved.

Sometimes I see the copying of the MBR fail in the way you describe. It doesn't do any harm if you do it, but if it doesn't work, use grub-install --recheck /dev/sda

jlinkels

1 members found this post helpful.

Thank you. In regard to my other questions, can you offer any guidance? Or were all my other assumptions correct? (which would be surprising)

still hoping someone with experience can reply to my questions before I start. I don't want to have to learn the hard way by screwing this up.

My remaining questions are:

1. Can I reuse the existing destination partitions on the SSD?
2. Do I need to erase anything (files, etc.) before the copy/clone? (e.g. rm -rf /mnt/target)
3. when and from what operating system would I run mkswap and swapon -a? Would I have to do this after booting into the newly copied OS?
4. Am I doing the right thing to move the source /boot directory into the target boot partition?
5. Will my partition labels be intact after this?
6. Do I have to make any changes to GRUB? Anything else?
7. When and from where would I run grub-install --recheck /dev/sda? After booting into new OS?
   

Thanks!

well, I had the choice to wait for a reply (which might not ever come) or push forward and try it. So I pushed forward (while continuing to seek answers in other places, of course).

Unfortunately, on boot I now get the grub_rescue prompt. Not sure where things went wrong...

I got a little further, but I appear to have hit a grub problem. Now, on booting up, I get this message:
ALERT! /dev/disk/by-uuid/xxxx-xxx-xxx-xx does not exist. Dropping to a shell.

The shell prompt is (intramfs)

running blkid shows my "/" partition as expected and my swap partition.

Neither have the UUID referred to in the error message, of course. My /etc/fstab mounts "/" and swap by label.

The offending UUID is listed in grub.cfg. But I'm not sure how to get rid of it.

Doing the dd clone of the whole disk was a lot easier because I didn't have to deal with any of this. But dd takes about 8 hours. If I can solve this problem and make the rsync cloning work, it will only take 7 minutes.

(If anyone wants to help me solve this, I'll post a script when I'm done, fwiw.)

Mounting by UUID nowadays is preferred over labels altough there is nothing wrong with labels.

Find the UUID's of your new disk (blkid) and insert them in your fstab. A line line this should look like:

The UUID for the boot partition must be specified in grub.cfg as you noted correctly. Also in fstab for all partitions that you want to mount.

jlinkels

1 members found this post helpful.

I need to do the opposite. I need to remove grub2's use of UUID's. How?

grub.cfg on my target filesystem lists a UUID that doesn't exist. That's the problem I need to solve. How do I reinstall grub in a way that prevents it from using the wrong UUID -- or any UUID at all. grub2 has the option to search by label instead of UUID. I just can't figure it out.

When you boot up and get to the grub menu just press 'e'. Then you can edit it. For now I would suggest forgetting about the UUID and just specify the the disk directly. So you can try to get into your new install.

It should look something like this

menuentry "Debian" {
set root='(hd0,X)'
linux /boot/bzImage-2.6.34 root=/dev/sdaX
}

It will have more but those are the two lines you need to edit. The first you just need to replace the X with the partition number you have have /boot in. For the second replace the X with the partition number you installed / to. Which I think should be 1 & 2 respectively.

If that works then you should get into your new installation. But this is just a temporary fix. You will have to edit the proper config files then run update-grub2 to install it. The config file is in /etc/grub.d/ but the files might differ on different distros. If you just jot down everything you see when you are editing the grub menu down and put it in a file called say 40_custom in the /etc/grub.d/ directory and make it executable (chmod +x 40_custom). Then run update-grub2 it should work.

It seems like grub2 and UUIDs are the Achilles heel in the process of using cp or rsync to clone a drive.

The only way I can see to resolve this is to make the filesystem using the old (source) UUID on the new (target) partition. That's not what I really want to do...

I can't seem to get a grub menu, even holding down the space bar.

The shell prompt is (intramfs)

You can move the installation to a new disk. I have done it a couple times. I just create a new partition on the new disk and copied the files over. Then edited some files and it worked. So you can do it, but you can run into some trouble on the way. And there is no point copying the firs 446 bytes of the MBR. There is nothing there that needs to be copied over. Just start fresh.

Thanks, but for the record, this isn't a solution to the problem I posted at the start of this thread. I don't want people to think this solves it for me because I'm not interested in doing a fresh install (in this context).

I'm trying to clone an existing install.

Try pressing ESC right when grub starts up. That should allow you to see the menu.

I wasn't saying do a fresh Install. But just setup the new hard drive from scratch. Setup the partitions put a filesystem on them. Then copy all the files over to it.