Cloning GRUB2/GRUB-legacy makes clone not bootable

[Francis Lamonde]

grub2 v1.99 included with Kubuntu 11.10.
ALSO TESTED WITH
grub-legacy part of Kubuntu 11.10 packages (Muon).

I have 2 identical disks, the only difference being their manufacturer serial number (disk ID) or UUIDs if using them.

Before trying Kubuntu I was (And still am due to this problem) with openSUSE.

Both disks have the exact same partition table.
Both disks run exactly the same with the same distro, same grub-legacy, same data on each.
I can boot each disk in any order I want, whether they are both connected at the same time or any of them connected alone.
I can swap the order of the disks and boot no problem.

These disks are used in a testing and backup configuration and requirements, therefore I often make images of partitions and restores them, on any disk, as I wish. It always works, using 'dd' from inside the distro or 'g4l', the Ghost For Linux application on a bootable CD.

My problem:
With Kubuntu 11.10 I realized when I clone the disk or root partition, the cloned disk becomes UNBOOTABLE, not matter if I use grub2 or grub-legacy!
Everything works fine on the disk I installed Kubuntu on. The one I clone does not boot/startup grub (grub2 or grub-legacy, I get the EXACT same behavior).

Example:

DISK1
sda1 linux partition
sda7 temp partition
I have other partitions for DATA purposes only.
The root and boot are in sda1.

DISK2
sdb1 linux partition
sdb7 temp partition
I have other partitions for DATA purposes only.
The root and boot are in sdb1.

With openSUSE I can clone sdb1, sda1, sdb7 and sda7 and restore the images to the other disk or the same disk and both disks remain bootable, no matter the order and no matter if one or both are connected at the same time. This is my requirement and openSUSE fulfills it.

If I CLEAN install Kubuntu 11.10 on DISK2 connected alone (it becomes sda1), I can boot it no problem,

The problem occurs if I clone sdb1 and sdb7 of DISK2 to sda1 and sda7 on DISK1. Then DISK1 does not boot grub2 (or grub-legacy) menu no matter what. Alone, both disks, 1st or 2nd, problem is the same. I get a blank screen with a fast blinking cursor top left and only CTRL-ALT-DEL works. My DISK1, newly cloned BYTE PER BYTE including MBR and partition tables becomes totally unusable.

This is an obvious show-stopper for me cuz the cloned disk is not bootable!

But if I image sdb1 on DISK2 and restores it to sdb1 on DISK2, it works! On another disk, it doesn't. No matter if it's grub2 or grub-legacy!

This problem is not existent with openSUSE using grub-legacy.

What's the problem with Kubuntu 11.10?
And how to fix it so that a simple clone will work (re-installing grub2 or grub-legacy after a clone is not an option, this defeats the purposes of my cloning requirements).

Thank you

[Phillip Susi (psusi)]

How exactly are you cloning the disks? If it was a byte for byte clone, then the partitions on the cloned disk would have the same UUID as the originals. Check the output of the blkid command. If they have the same UUID, then connecting both at once will confuse the system. If you change the UUID of the clone, then you will need to reinstall grub as it will still be looking for the original UUID.

[Francis Lamonde (frankebay99)]

I was aware of that problem, yes, this is why I don't use UUIDs, I use disk-IDs.

But UUIDs or not doesn't change the result, cuz yes I did a byte-per-byte copy BUT even if I totally unplug the original disk and boot with ONLY the cloned disk plugged in, it's the same behavior, a blank screen at GRUB2 and only ctrl-alt-del works.

This is why I am really confused, here...

[Francis Lamonde (frankebay99)]

I'll give a little more info.

I know that if I do a clean install and from there I play around imaging the disk or partitions and restoring older images on the SAME disk, it works, I'm doing it for over a month now.

This lets me think that if I boot from a live CD or a bootable disk and re-install grub2 onto the CLONED disk which doesn't boot, it may well work and I may well be able to image and restore anything I want onto any of the 2 disks. This is a fair guess. Question is, would it be interesting for you to know the outcome of this test or it doesn't matter?

[Phillip Susi (psusi)]

Grub doesn't support "disk-ids". It either uses the old ordinal system ( hd0 ) or searches for the fs by uuid. If you make a byte for byte copy of the disk and remove the original disk, the new one will boot fine because it will still find the root fs having the same uuid. That takes me back to the question of how are you duplicating the disk?

[Francis Lamonde (frankebay99)]

fstab still supports disk-ids, but I guess that's not part of grub, really, it's to mount the fs.
In grub.cfg and other grub files you are correct it has UUID. But let's put aside UUIDs for a moment, cuz that did not change anything for the blank screen.

I have tested all what you mentioned before opening the ticket.

Let me recap for easier reading:

How am I doing the copy?
Byte-per-byte.
At the interface level I use 2 different ways:

1- I use g4l bootable CD and image my root partition in RAW mode (http://sourceforge.net/projects/g4l/)
2- If I am inside the distro on one disk and the other disk's partition is unmounted, I use the following command:

sudo dd if=/dev/sdxy ibs=4096 conv=noerror | gzip -9 > /img/filename.img.gz

Never had a problem with either ways, except now with Kubuntu 11.10 (never tested with older versions of *buntu).

Now if I clone my root partition (and I also clone the /tmp partition), remove the original disk and try to boot with only the cloned disk plugged in like you mention, I still get the blank screen instead of grub2's menu. That is my problem, actually and the reason why I opened this ticket.
I have tested these exact steps using grub-legacy as well and surprisingly I get the same result. Which complicated furthermore my troubleshooting and testing as now I have no idea what else to test.

So the cleanly installed Kubuntu with either grub2 or grub-legacy can boot up no problem. I then initiate an image and restores the image to another identical disk and whether that cloned disk is booted alone or with the original disk as SATA1 (SATA0 being the cloned disk), I get the same blank screen instead of grub's menu.

That is 4 different setups:

1- grub2, cloned disk as SATA0 and original as SATA1;
2- grub2, cloned disk alone as SATA0, original disk completely unplugged;
3- grub-legacy, cloned disk as SATA0 and original as SATA1;
4- grub-legacy, cloned disk alone as SATA0, original disk completely unplugged.

Result: exact same. Blank screen with top left blinking cursor and only command working is CTRL-ALT-DEL.

Cloning is performed either of the following ways:

1- Using g4l bootable CD and image my root partition in RAW mode;
2- If I am inside the distro on one disk and the other disk's partition is unmounted, I use sudo dd if=/dev/sdxy ibs=4096 conv=noerror | gzip -9 > /img/filename.img.gz

[Phillip Susi (psusi)]

If you are just cloning the root partition, then you are not copying grub. You either will need to install grub on the destination disk, or clone the entire disk, not just the partitions.

[Francis Lamonde (frankebay99)]

By root partition I mean the whole partition from sector 1, which includes MBR.

'sudo dd if=/dev/sdxy ibs=4096 conv=noerror | gzip -9 > /img/filename.img.gz'

is supposed to copy MBR as well, unless I made a mistake in my command? That is possible, I will re-verify, Phil.
Listen, I will retry that above command and see what it does, unless you tell me right away it's wrong.

Hey wait... you know what? I think I did not use the above command yet in my tests, I did it on the same disk, backup and restore on the same disk, but I used g4l to restore to the OTHER disk, the cloned one.
And in g4l I am cloning sdb1 to sda1, not sdb to sda so it "probably" does not copy the MBR ( have to check that assumption).

Now you mention about this, it makes me think... since I do restores on the cleanly installed Kubuntu, grub2 is already there, therefore if I don't copy and restore the MBR, it doesn't change anything cuz the MBR already has grub2 in it. That would make sense. I think that might be the problem, I have to check a few things and do a couple more tests.

I'll be back, tnx for pointing this out.

[Francis Lamonde (frankebay99)]

Ok command

'sudo dd if=/dev/sdb1 ibs=4096 conv=noerror | gzip -9 > /img/filename.img.gz'

should copy the MBR as well, as I am not skipping (skip=x) any block size.

All I have to test is use that image and restore it with command

'sudo dd if=/img/filename.img.gz | gunzip | sudo dd of=/dev/sda1'

It should then overwrite MBR on the cloned disk. I will test that and see.

I am also contacting g4l developer to see if it does copy MBR when selecting the root partition from g4l menu.

[Phillip Susi (psusi)]

No, sdb1 is the partition. The mbr is before the partition. If you want to clone the whole disk and keep it bootable, you need to clone the whole disk ( sdb, no 1 ).

[Francis Lamonde (frankebay99)]

That would explain a lot of things.

I will test this and make sure it works.

This would mean, if it works, that I have always done my backups and restores the wrong way and by luck it always worked when using the same distro. Which means my grub has not been updated since 2007.

Tnx for that!

[Francis Lamonde (frankebay99)]

I confirm this bug as being INVALID.

For the past 5 years I have been doing my cloning the wrong way and by luck I never had a problem.

The MBR was not cloned this is why I had problems now.

tnx