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...

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.

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...

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

No need to copy the files again.

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?

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.

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

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.)

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:

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.

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.

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.

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!