LinuxQuestions.org
Help answer threads with 0 replies.
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-11-2010, 09:12 PM   #16
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
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.
That won't work unless you install a MBR.

Here's my checklist:
[check] fdisk to set up partitions
[check] mke2fs to install file system
[check] mkswap to set up swap space
[check] rsync to copy all files
[ ] grub - Oops, heres where the problems are...
 
Old 07-12-2010, 09:13 PM   #17
gammahermit
Member
 
Registered: Apr 2010
Distribution: Arch
Posts: 44

Rep: Reputation: 4
Quote:
That won't work unless you install a MBR.
Yes it needs to have a MBR but there is no need to do it manually. It is probably unwise to do it that was as well. The drive will already have a MBR on it and if it doesn't then the partition manager will setup the partition tables and when you install grub/lilo it installs the image that launches the OS. So there is no need to actually copy it.

As for the grub problem. You need to modify the config file, like I said in a previous post, and reinstall it to that disk with "grub-install /dev/sda". Then it should boot up to the new disk.
 
Old 07-12-2010, 09:25 PM   #18
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
Yes it needs to have a MBR but there is no need to do it manually. It is probably unwise to do it that was as well. The drive will already have a MBR on it and if it doesn't then the partition manager will setup the partition tables and when you install grub/lilo it installs the image that launches the OS. So there is no need to actually copy it.
Hmmm, strange conversation we are having here... maybe I'm not being clear.

I know what you are saying, but I disagree in general about your method. If one is cloning a system, ideally one won't be pre-installing an OS. So copying the MBR with dd makes perfect sense. At least to me. Your method seems really inefficient and unnecessary.

Anyway, that's not the crux of the problem. The problem is the UUID's that grub2 uses by default -- even when you tell it not to. At least on Ubuntu, when you turn off the UUID feature, UUIDs still appear everywhere in grub.cfg.

I can hand-edit grub.cfg, but those changes won't stick. So I need to figure out how to make update-grub do what I want it to do. Not an easy task...
 
Old 07-12-2010, 09:30 PM   #19
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 12,491

Rep: Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077
If you insist on Ubuntu, go read this
It should resolve the UUID issues for you.

No need to copy the files again.
 
Old 07-12-2010, 09:35 PM   #20
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
Here's an update. Below are my revised proposed steps. I still want some feedback on this before I actually do it. I don't want to screw up my running system (the target).
  1. make a copy of /etc/fstab from the target drive before proceeding.
  2. Ready the target partitions. Yes, I can reuse the existing destination partitions on the SSD.
  3. Ready the filesystems on each of the target partitions. Erase all files on / and /boot unless using mke2fs. Optionally, could use mke2fs to make a new filesystem with UUID of source.
  4. next, use dd to copy MBR. 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. It is already activated.
  7. Copy the files from the source partition to the destination
    Code:
    rsync -ua /mnt/source/boot/ /mnt/boot_target
    rsync -ua /mnt/source/ /mnt/root_target
  8. then go to /mnt/root_target and delete the /boot directory.
  9. Do I have to make any changes to GRUB? Yes. Grub on the source system needs to NOT use UUID's (unless new filesystem is made with those same UUID's on the target system).

I kinda think those steps will work. Am I forgetting anything?
 
Old 07-12-2010, 09:41 PM   #21
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 syg00 View Post
If you insist on Ubuntu, go read this
It should resolve the UUID issues for you.

No need to copy the files again.
I think we posted at the same time. I've been reading that ubuntu link for two days. That's how I learned about the bug in GRUB_DISABLE_LINUX_UUID.

But I can't see how anything on that page really addresses the issue of properly getting rid of UUID's in the generated grub.cfg file. Using GRUB_DISABLE_LINUX_UUID="true" doesn't really do it. The UUID is still present in the newly generated grub.cfg in about a dozen places. True, it isn't in the critical places, but it's still there.

I suppose I could boot up the newly cloned system and run an update-grub followed by a grub-install and then I'd (hopefully) end up with the proper UUID's from the target system. But 1) that's extra work, and 2) I don't want to use UUID's at all.
 
Old 07-12-2010, 09:56 PM   #22
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 12,491

Rep: Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077Reputation: 1077
UUIDs is the Ubuntu way - been a pain for a while, even with classic grub, but at least it was easy to get around with that.
You could doctor the grub.cfg and not run update-grub. Ever. But the next software update will.

Grub2 still has plenty of warts, but the Ubuntu devs insist on forcing their vision down everyones throats.
 
Old 07-12-2010, 10:33 PM   #23
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 syg00 View Post
UUIDs is the Ubuntu way - been a pain for a while, even with classic grub, but at least it was easy to get around with that.
You could doctor the grub.cfg and not run update-grub. Ever. But the next software update will.

Grub2 still has plenty of warts, but the Ubuntu devs insist on forcing their vision down everyones throats.
Yes, I'm not liking a lot of things Ubuntu is doing lately...

I have already edited grub.cfg to use only labels and it works. But, as you point out, I need a solution that will stick.

drs305 at ubuntuforums gave me this helpful link. But it only contains part of the solution.

http://sourceforge.net/apps/mediawik...roblems:search
 
Old 07-12-2010, 11:26 PM   #24
gammahermit
Member
 
Registered: Apr 2010
Distribution: Arch
Posts: 44

Rep: Reputation: 4
Okay. It seems I'm not getting my point across very well. Lets forget about the MBR for a second and just concentrate on grub. /boot/grub/grub.cfg is automatically configured by update-grub2. It reads files in /etc/grub.d/ It runs each file in there to generate grub.cfg. The files in that directory may differ with different distributions. But you can just make a file called say 40_custom. And put in a menu entry for ubuntu on that disk. It should look something like this.


menuentry "Ubuntu" {
set root='(hd0,1)'
linux /boot/KERNEL_IMAGE root=/dev/sda1 ro quiet
initrd /boot/INITRAMDISK
}


You will need to change KERNEL_IMAGE to the name of your kernel image (you might have to change the path too). And change INITRAMDISK to the name of your initrd image, if your system uses one.

Then you need to run update-grub2. It will automatically generate grub.cfg. Then you can just reboot and you should be able to reboot to the new system.
 
Old 07-12-2010, 11:50 PM   #25
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
Okay. It seems I'm not getting my point across very well. Lets forget about the MBR for a second and just concentrate on grub. /boot/grub/grub.cfg is automatically configured by update-grub2. It reads files in /etc/grub.d/ It runs each file in there to generate grub.cfg. The files in that directory may differ with different distributions. But you can just make a file called say 40_custom. And put in a menu entry for ubuntu on that disk. It should look something like this.


menuentry "Ubuntu" {
set root='(hd0,1)'
linux /boot/KERNEL_IMAGE root=/dev/sda1 ro quiet
initrd /boot/INITRAMDISK
}


You will need to change KERNEL_IMAGE to the name of your kernel image (you might have to change the path too). And change INITRAMDISK to the name of your initrd image, if your system uses one.

Then you need to run update-grub2. It will automatically generate grub.cfg. Then you can just reboot and you should be able to reboot to the new system.
Thanks for continuing to assist.

Here is how I have manually edited grub.cfg. My system boots with this configuration. (fstab uses labels too.)

Code:
### BEGIN /etc/grub.d/10_linux ###
menuentry "Linux Mint 9, 2.6.32-21-generic (/dev/sda1)" --class linuxmint --class gnu-linux --class gnu --class os {
	recordfail
	insmod ext2
	#set root='(hd0,1)'
	search --no-floppy --label mylabel --set root
	linux	/boot/vmlinuz-2.6.32-21-generic root=LABEL=mylabel ro   quiet splash
	initrd	/boot/initrd.img-2.6.32-21-generic
}
Notice that I commented out set root='(hd0,1)'. I might put that back in just to be safe. (I believe that serves as a fall-back in case the label doesn't work for some reason.)

Most recently I have been attempting to make update-grub (as it is called on my system) generate the exact stanza shown above. I can't seem to do that by editing /usr/lib/grub/grub-mkconfig_lib.

So I guess you are telling me that I can do it by using 40_custom. That leads to a couple questions:

1. how do I make my entry in 40_custom the default so the system boots with no intervention (and not even showing a grub menu)? I suspect this question is trivial, but... I haven't done it yet so not sure how it works.

2. what mechanism takes care of kernel updates when I use 40_custom? Is it just up to me to write a menu stanza like that shown below?

I think the code I would add to 40_custom would be like this:

Code:
menuentry "Linux Mint 9 (newest)" --class linuxmint --class gnu-linux --class gnu --class os {
	search --no-floppy --label mylabel --set root
	linux	/boot/vmlinuz root=LABEL=mylabel ro   quiet splash
	initrd	/boot/initrd.img
}
Again, maybe I also need set root=(hd0,1) to be safe... not sure.

I heard that if I name the file 06_custom, the menu stanzas will come first instead of last.
 
Old 07-13-2010, 12:20 AM   #26
gammahermit
Member
 
Registered: Apr 2010
Distribution: Arch
Posts: 44

Rep: Reputation: 4
Okay good. But you need the "set root=" option in there. It tells grub the location of the /boot/ directory. the other root= option, the one in line that starts with linux, tells the kernel where to the root filesystem is. On your system they are the same. Back in the old days it was customary to have /boot/ /usr/ /tmp/ /home/ on separate partitions. And you need to change vmlinuz & initrd.img to the full name of the kernel image & initramdisk. Like your grub.cfg had it. Unless vmlinuz & initrd.img are symlinks to the actual file.


The ONLY files you should be editing for grub are the ones in "/etc/grub.d/". And "40_custom" is a file you should make and put in that directory. Though you could call it 06_custom, like you said, then it should be the first option and so the default. Or you would put this line "set default=#" in the file "40_custom". You will need to replace # with a number. That number specifies the entry number to be the default. So the exact number will depend on how many entries there are.

As for the kernel update problem. Check in / to see if there are files called vmlinuz & initrd.img. Those are symbolic links to the actual kernel and initrd files in /boot/. When the kernel is upgraded the links should be updated as well. So you won't need to run modify anything.
 
1 members found this post helpful.
Old 07-13-2010, 06:55 PM   #27
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
I got the last missing piece of this whole solution working the way I wanted it to work. I appreciate all the help here. I also had help over at ubuntuforums.

The grub2 "labels instead of UUIDs" issue was the last part keeping me from moving forward. Here's how I ended up resolving that.

http://ubuntuforums.org/showthread.p...64#post9585964

Now I'm going to try to put it all together and actually clone my larger disk onto my smaller SSD. I'll try to update this thread with my results.

Thanks again for all the input.

Last edited by Mountain; 07-13-2010 at 07:06 PM.
 
Old 07-14-2010, 12:04 AM   #28
Mountain
Member
 
Registered: Nov 2007
Location: A place with no mountains
Distribution: Kubuntu, sidux, openSUSE
Posts: 214

Original Poster
Rep: Reputation: 33
I have tested this several times on a test system and it is working. The test system does not have a separate boot partition. But I think I have figured out now I will need to do it. The steps below are the ones I propose will work on my real system with a separate boot partition. These steps are not really generic, but they may give a concrete example is anyone else wants to do things in a similar manner to what I'm doing.
  1. The source system must be prepared so grub2 does not use UUID's (or the target file system must be recreated with the same UUID, but I don't want that). Here is how to make grub2 use labels instead of UUID's: http://ubuntuforums.org/showthread.php?t=1530532
  2. copy source system to a USB stick
  3. copy source MBR to USB stick too
    Code:
    dd if=/dev/sda of=/path/to/image/linuxmint9.labelbased.mbr count=1 bs=512
  4. make a copy of /etc/fstab from the target drive before proceeding.
  5. boot target system from any live distro on a USB drive.
  6. insert the other USB with the cloned system to be copied (the source)
  7. mount source and target
    Code:
    mkdir -p /mnt/target
    mkdir -p /mnt/source
    mount -t ext2 /dev/sdc1 /mnt/source
    mount -t ext2 /dev/sda1 /mnt/boot_target
    mount -t ext4 /dev/sda2 /mnt/root_target
  8. since the partitions on the target system (an SSD) are already carefully aligned, reuse them but remove all files before starting.
    Code:
    rm -rf /mnt/root_target/*
    rm -rf /mnt/boot_target/*
  9. copy files to the target
    Code:
    rsync -ua /mnt/source/boot /mnt/boot_target
    rsync -ua --exclude 'boot' /mnt/source/ /mnt/root_target
    rm -rf /mnt/target/mbr
  10. restore MBR
    Code:
    dd if=/mnt/source/mbr/linuxmint9.labelbased.mbr of=/dev/sda count=1 bs=446
  11. existing swap can be reused with no additional steps required.
  12. unmount
    Code:
    umount /mnt/target
    umount /mnt/source
  13. Change /etc/fstab to reflect the new partitions. The source fstab was on a system without a separate /boot partition.
  14. reboot and see if it works

I think that covers every question I posed in my original post. It looks really simple now that I understand it better. The only part of the copy-cloning operation that is not straightforward is dealing with grub2 and UUIDs.

A real clone (using dd or similar) doesn't encounter any problems with grub2 and UUIDs (because cloned fs has same UUID as original). But a clone using rsync or cp does have a problem with UUID's. I chose to solve it by not using UUID's in grub2 and that proved to be a big challenge. But that works 100% now, and the rest is really trivial (at least it seems so now). Thanks for all the help!
 
  


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 07:57 PM
Compose two smaller images into one larger image diN0bot Linux - Software 4 03-15-2009 12:45 AM
backup a failing disk to a larger disk gfem Linux - General 8 07-13-2007 08:19 PM
smaller drive to larger drive duplication mystery midlifecrisis Solaris / OpenSolaris 6 02-01-2006 08:23 AM
Free disk space in '/' getting smaller and smaller. simjii Suse/Novell 5 12-16-2005 12:24 PM


All times are GMT -5. The time now is 03:51 AM.

Main Menu
Advertisement
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