Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been running Ubuntu 10.04 and just installed Linux Mint 13. I may go with Linux Mint full-time, but for now I wanted to install it to the first partition, but keep Ubuntu bootable.

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048    58593279    29295616   83  Linux
/dev/sda2        58595326   976768064   459086369+   5  Extended
/dev/sda5       959980140   976768064     8393962+  82  Linux swap / Solaris
/dev/sda6        58595328   898696186   420050429+  83  Linux
/dev/sda7       898697216   959963135    30632960   83  Linux

sda6 is a data partition with all my documents. sda7 was added new to create the dual boot setup. I cloned sda1 to sda7 with

 dd if=/dev/sda1 of=/dev/sda7

Of course this also cloned the UUID, so I created a new UUID for sda7 with

tune2fs /dev/sda7 -U random

When I list UUIDs with blkid it has indeed changed. I then installed Linux Mint to sda1. I also have fstab setup to mount sda7 so I can copy configuration files to the new OS. I boot into Linux Mint fine, but when I try to boot into Ubuntu, I get a message (from memory, may be incomplete) that the loader can't find /dev/disk/by-uuid/<old UUID>.

At this point I looked in grub.cfg, and sure enough, the old UUID is listed, along with the new one:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Ubuntu, with Linux 2.6.32-41-generic (on /dev/sda7)" --class gnu-linux --class gnu --class os {
    insmod part_msdos
    insmod ext2
    set root='(hd0,msdos7)'
    search --no-floppy --fs-uuid --set=root 3869f8c2-dcf8-4522-bc8b-91b0ce0040fa #This is the new UUID
    linux /boot/vmlinuz-2.6.32-41-generic root=UUID=72a5e117-9a39-4de1-9d28-53791d055ff5 ro quiet splash #This is the old UUID
    initrd /boot/initrd.img-2.6.32-41-generic

I then tried to fix this with sudo update-grub, but I still get the same entry with the mix of new and old UUIDs. I also tried manually editing grub.cfg to replace the old with the new UUID, but I still get the same message, that the loader can't find a device with the old UUID.

So, where is update-grub reading the old UUID from? And how do I fix grub so that it can boot the cloned partition?

share|improve this question

My guess is that you are not viewing/editing the same grub.cfg that the bootloader is looking at. Remember, you have two different /boot/grub directories now, and the bootloader needs to know which one to look for. update-grub is updating the grub.cfg in the currently mounted /boot/grub/grub.cfg. I'm guessing that the bootloader is looking on the other partition. After I finish my first cup of coffee, I may be able to confirm this by following through your post and perhaps making notes, but right now it's got to be an educated guess.

I believe what you need to do is to run sudo grub-install --root-directory=/ /dev/sda. I'm giving the full version for extra information - the --root-directory parameter defaults to /.

This command will reinstall the boot loader on /dev/sda, telling it to look in the "root-directory" parameter (/boot/grub) for grub.cfg. If you wanted your grub.cfg to be in a different distro, you can mount it and specify a different "root-directory", such as, for example, /mnt/my_other_distro/ if it were mounted in /mnt/my_other_distro.

Let me know if you have problems while I drink my coffee. :)

Edit: (after coffee) I see now one important problem... you should have changed the UUID for sda1, not sda7. Then, when you installed Mint onto sda1, it would change it anyway if you reformat, but if you didn't change it, it might get confused. By changing the UUID for the old Ubuntu installation, you invalidated all the mount settings in its /etc/fstab, along with the GRUB menu. I assume Mint doesn't regenerate the menu, but only copies the entries, so it doesn't care whether it's correct or not.

Running update-grub corrects grub.cfg, but not the grub code in the MBR; this is changed only using grub-install.

And Linux Mint doesn't know what the entries in grub.cfg actually mean, as it may refer to a drive that isn't even present right then. It simply adds the new entry to the top of the existing ones, I think.

share|improve this answer
So does the bootloader pass control to the partition? grub-install already ran as part of the Linux Mint install (right?), because I get the grub menu, and Linux Mint (first OS) loads successfully. Are you saying that when I choose Ubuntu it passes control to grub.cfg on sda7, and fails because that grub.cfg hasn't been updated with the UUID? Anyway, came up with a solution (see below), though this answer is also helpful. – Lee Hachadoorian Jun 26 '12 at 16:37
No. I added more to my answer, but the bootloader, the part of grub in the MBR, reads a single grub.cfg for it's operation. The problem is Linux Mint didn't really configure it to look in the changed UUID location - it really didn't know that was even it. It could be that the existing entry was for a drive that was not currently connected. – Marty Fried Jun 26 '12 at 19:02

OK, I figured out a solution, which is probably what I should (or shouldn't) have done in the first place.

After dd cloning the Ubuntu partition, before installing Linux Mint, I booted into Ubuntu. That's when I realized (looking at the partition table) that the UUID had been duplicated, so I generated a new UUID. But when I installed Linux Mint, it formatted the original partition and generated a new UUID anyway. Basically, I ran

sudo tune2fs /dev/sda7 -U <old UUID>
sudo grub-update

and reset fstabs appropriately, and everything worked. Never should have altered the UUID of the cloned partition in the first place.

Still, it might be useful to know how to alter the UUID of a partition and still have the bootloader find it, so Marty thanks for your response above.

share|improve this answer
The solution isn't what you should have done in the first place, but it's probably the easiest way to have fixed it now. The alternative would be to do the grub-install, but then you'd still need to change the UUIDs in /etc/fstab for the old Ubuntu. The solution "in the first place" was to regenerate a UUID for sda1, not sda7. Then, everything would have worked fine after that. – Marty Fried Jun 26 '12 at 19:06

This will remain helpful for others and alike and me too.


just a tread I found while looking.....and right after loging-out of here after I've added this below.....

---------------end of edit#1

And I have to add this;

UUID will always remain the same no-matter the formatting. It CAN change, if required, only when using Dban or SecureDelete (which everyone can find using HaremsBootCD for all OS or UltimateBootCD for windows)(because it logs-out/off of the OS in order to run those programs) Only SecureDelete can talk directly to the HDD. No format done through the/any OS can erase the UUID, not even through an ordinary liveCD (as explained/said above).

So yeah, just as I would have guess, if the cloned partition has cloned the uuid(which is a VERY bad idea and mismanagement from the software dev depart...) it would be safe to keep log and note of the uuid of both drives and partition table in order to correct the future fstab(using any live CD to edit it as root ofcourse) for linux to boot. But I don't think or see how the cloned would have any part of the root partition-table. Partition and partition-table are two different thing, one goes on top of the other as a layer ON the table. So the UUID should remain the same..... unless there are an added new partition on that table(ether primary,logical, or extended)

So, out of thread here now... Linux is fun because we can do that, but also, linux is a pain because we have to know that we have to do and must do all those such "tricky" thing.

And I LIKE/LOVE the Ubuntu/Mint/Debian/CrunchBang/Slackware forums because we can exchange old and NEW solution. Not as like(not that liked/loved by most and I) in the arch forums where any"solved" is very outdated after just 12days or worst, and/or any user even get reprimanded for trying to say "thank you" (even after reading arch-manuals)(maybe I should start making my own OS from LFS --linux-from-scratch;) might be easier to build than ask other how theirs is working, who knows(?)

Anyway, I landed here out of a google search for/if a way of cloning a linux install. Not only I have found it can be done, but that I will have to make sure it has the correct UUID, which I had not thought of beside just cloning it and boot.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.