Trying to set cloned partition as new root

Weapon S · 02-17-2017, 11:44 AM

I have done similar things in Debian a couple of times, but now it doesn't seem to work.
On a BIOS system (i.e. non-UEFI). I have a working Ubuntu on /dev/sda1, with grub installed to the same disk (/dev/sda). Then I cloned this partition to /dev/sdc1. Then I generated a new UUID for /dev/sdc1 using tune2fs. Then I changed the /etc/fstab on /dev/sdc1 to use the clone as root by UUID. Then I ran update-grub. Then I restarted. Of course now the computer still boots from the disk /dev/sda. The clone was listed in the GRUB start-up menu as expected marked as "Ubuntu (on /dev/sdc1)" or something. I choose to boot into this system. So far so good.
Then I look at blkid (to ensure drive assignment hasn't changed) and /proc/mounts to verify I'm actually in the new system... and I'm not. /dev/sda1 is the root. I'm flabbergasted.
So apparently there is some configuration somewhere that reverts to the old disk partition. I guess it could be in the GRUB line. I'm not very comfortable with advanced configuration of GRUB. Or there could be some Ubuntu specific mechanism. Any way... I don't understand at all why update-grub didn't work.

yancek · 02-17-2017, 12:09 PM

If you have the boot partition on sda1 and cloned it to sdc1, you need to check the UUIDs in the grub.cfg file of at least sdc1 to verify that it is using the correct UUID. If you cloned the sda1 boot files to sdc1, that isn't changing the UUID entries in the grub.cfg file.

Weapon S · 02-17-2017, 12:20 PM

Wait. Since I'm booting from sda, all the grub configuration is in sda1, right? Or do I have to chroot into the sdc1 to properly configure GRUB? I don't get it. Could you please explain?

This is what the specific entry on sda1 looks like in /boot/grub/grub.cfg. (I have replaced the UUIDs with **SDA1** and **SDC1**

Code:

menuentry 'Ubuntu 16.04.2 LTS (16.04) (on /dev/sdc1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-**SDC1**' {
	insmod part_msdos
	insmod ext2
	set root='hd2,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1  **SDC1**
	else
	  search --no-floppy --fs-uuid --set=root **SDC1**
	fi
	linux /boot/vmlinuz-4.4.0-62-generic root=UUID=**SDA1** ro
	initrd /boot/initrd.img-4.4.0-62-generic
}

Why is **SDA1** there?

yancek · 02-17-2017, 03:48 PM

run sudo blkid and get the UUID for sdc1. Replace the current UUID on the sda1 grub.cfg file where you have **SDA1** and **SDC1** with that UUID.

Quote:

Why is **SDA1** there?

Because you put it there when you copied/cloned sda1 to sdc1. The more interesting questions is why does the 'set root' line show the correct UUID which I expect would be explained by how Grub searches for boot files which is something I've never explored.

TxLonghorn · 02-18-2017, 08:47 AM

Moving the root partition to a new drive
You can skip the part about switching to GPT partitioning with a bios_grub partition, if you want to stick with msdos partitioning - but the rest applies.

EDIT: Actually, after reading your first post again, there is a different way to approach it. AFter you get your fstab edited correctly, you can boot into your current Ubuntu on /dev/sda1 and run

Code:

sudo update-grub

That will put the new Ubuntu on /dev/sdc1 on the Grub menu. Reboot. Chose the new menuentry for the Ubuntu on sdc1. After booting into that, run

Code:

sudo update-grub

and

Code:

sudo grub-install /dev/sdc

Weapon S · 04-30-2017, 01:16 AM

I guess that will be a solid way to work around it. But I still think it is broken, because basically grub doesn't configure things right for a multi-boot Ubuntu (i.e. with two Ubuntu installations).

TxLonghorn · 04-30-2017, 11:41 PM

Quote:

Originally Posted by Weapon S

I guess that will be a solid way to work around it. But I still think it is broken,

You are wrong. It is not broken.

Quote:

Originally Posted by Weapon S

basically grub doesn't configure things right for a multi-boot Ubuntu

Also wrong. What are you talking about? Give an example.

Weapon S · 05-03-2017, 12:20 PM

What do you mean an example? My case is the example. I have Ubuntu. I clone the partition; I generate a new UUID for the partition. I now have a second installation of Ubuntu. I run update-grub.
GRUB detects the two installations, makes separate menu entries for the installation, sets all the parameters correctly for both installations, and then copies the UUID of the root of the current installation to a critical part of grub.cfg for the cloned installation.
If I chroot into the cloned installation and then do update-grub it will probably set the root for both installations, old and cloned, as the cloned root; but at least I'll have the cloned installation working.
I suspect it is some configuration Ubuntu has done to GRUB, and not a fault in GRUB itself.

jailbait · 05-03-2017, 03:27 PM

I suggest that you check grub.cfg and see if grub is passing the kernel the correct UUID in the root=UUID= parameter. I have had trouble with grub doing that incorrectly in the past.

--------------------
Steve Stites

TxLonghorn · 05-04-2017, 06:21 AM

Quote:

Originally Posted by Weapon S

If I chroot into the cloned installation and then do update-grub it will probably set the root for both installations, old and cloned, as the cloned root.

If you chroot into the cloned installation and then do update-grub, it will update the grub.cfg file on the cloned installation. It will not "set the root for both installations" - whatever that means. Update-grub updates the grub.cfg file - that's it - nothing more. If you have changed the UUID's there will be no confusion between the 2 OS's.
On the other hand, if you boot into the old OS and update Grub, as I suggested, you will then have the new one listed on the Grub menu and then you can boot into it and update grub.cfg and install that grub to sdc (or to any drive).
If there is a problem, review the tutorial I linked to to see if there is a step you missed.