LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices

Reply
 
Search this Thread
Old 07-10-2010, 12:24 PM   #1
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Rep: Reputation: 33
Need more details on how to clone a larger disk to smaller with cp


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?
 
Old 07-10-2010, 12:39 PM   #2
jlinkels
Senior Member
 
Registered: Oct 2003
Location: Bonaire
Distribution: Debian Lenny/Squeeze/Wheezy/Sid
Posts: 4,168

Rep: Reputation: 506Reputation: 506Reputation: 506Reputation: 506Reputation: 506Reputation: 506
Quote:
Originally Posted by Mountain View Post
I suppose I can leave the swap partition on the target untouched.
You have to do mkswap and swapon -a if you have not done so.
Quote:
Originally Posted by Mountain View Post
Copy the files from the source partition to the destination
I would prefer rsync
Code:
rsync -uav /mnt/source/boot/ /mnt/boot_target
Note 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.
Old 07-10-2010, 01:23 PM   #3
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Thank you. In regard to my other questions, can you offer any guidance? Or were all my other assumptions correct? (which would be surprising)
 
Old 07-10-2010, 04:03 PM   #4
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
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!

Last edited by Mountain; 07-11-2010 at 01:40 AM.
 
Old 07-11-2010, 02:28 PM   #5
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
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...
 
Old 07-11-2010, 03:10 PM   #6
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
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.)

Last edited by Mountain; 07-11-2010 at 03:12 PM.
 
Old 07-11-2010, 03:27 PM   #7
jlinkels
Senior Member
 
Registered: Oct 2003
Location: Bonaire
Distribution: Debian Lenny/Squeeze/Wheezy/Sid
Posts: 4,168

Rep: Reputation: 506Reputation: 506Reputation: 506Reputation: 506Reputation: 506Reputation: 506
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:

Code:
UUID=a81275ab-290c-4c7c-9fea-f9d0a888cdeb        /             ext3    defaults                 0    1
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.
Old 07-11-2010, 03:35 PM   #8
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by jlinkels View Post
Find the UUID's of your new disk (blkid) and insert them in your fstab. A line line this should look like:
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.

Last edited by Mountain; 07-11-2010 at 03:44 PM.
 
Old 07-11-2010, 05:50 PM   #9
gammahermit
Member
 
Registered: Apr 2010
Distribution: Arch
Posts: 42

Rep: Reputation: 4
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.

Last edited by gammahermit; 07-11-2010 at 05:59 PM.
 
Old 07-11-2010, 05:54 PM   #10
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
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...
 
Old 07-11-2010, 06:20 PM   #11
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by gammahermit View Post
When you boot up and get to the grub menu just press 'e'.
I can't seem to get a grub menu, even holding down the space bar.

The shell prompt is (intramfs)
 
Old 07-11-2010, 06:22 PM   #12
gammahermit
Member
 
Registered: Apr 2010
Distribution: Arch
Posts: 42

Rep: Reputation: 4
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.
 
Old 07-11-2010, 06:27 PM   #13
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by gammahermit View Post
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.
 
Old 07-11-2010, 06:27 PM   #14
gammahermit
Member
 
Registered: Apr 2010
Distribution: Arch
Posts: 42

Rep: Reputation: 4
Try pressing ESC right when grub starts up. That should allow you to see the menu.
 
Old 07-11-2010, 06:39 PM   #15
gammahermit
Member
 
Registered: Apr 2010
Distribution: Arch
Posts: 42

Rep: Reputation: 4
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.
 
  


Reply

Tags
clone, copy, dd, hdd, ssd


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Want to clone Windows Server 2003 to larger hard drive ZapTheSheep General 4 04-18-2011 06:57 PM
Compose two smaller images into one larger image diN0bot Linux - Software 4 03-14-2009 11:45 PM
backup a failing disk to a larger disk gfem Linux - General 8 07-13-2007 07:19 PM
smaller drive to larger drive duplication mystery midlifecrisis Solaris / OpenSolaris 6 02-01-2006 07:23 AM
Free disk space in '/' getting smaller and smaller. simjii Suse/Novell 5 12-16-2005 11:24 AM


All times are GMT -5. The time now is 12:13 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration