If you do dd if=/dev/sda of=/dev/sdb bs=1M and then use sdb on another computer then there is no reason it wouldn't work. Also your question is unrelated to original wishlist item. So, it's not a right place to discuss it. Use appropriate mailing list.

Ok. I see disk-IDs are not reliable in some situations. I just happen to work differently with grub-legacy. I just started using grub2, so I am still learning new ways I guess.


Well for updating disk-ids that's the best part. I use 2 versions of fstab files from grub-legacy (cuz I use grub-legacy at the moment) that I just swap part of my image restore script, so I only need to do the setup once, I keep 2 files, one for disk1 disk-ids and one for disk2 disk-ids and they just get renamed accordingly, part of the restore script. Since I don't need to regenerate a disk-id and the way I work with it they are reliable on my setup, I never end up manually updating disk-ids.

But you know I could modify my script and include regenerating a UUID and updating grub on the drive I restore it to, I'm sure I can work out something.

I'll learn how to use UUIDs correctly for my setup.

Yes, I believe in my case the disk id is taken from the disk, not the BIOS. I never checked that, really.

My BIOS is dated from 2007.

I'll just have to work around duplicate UUIDs by send the 'tune2fs -U random /dev/sdXN' command from either a live CD or a bootable disk after each restore of partition or disk cloning I perform between disks. On the same disk that's fine, but on a different disk I will have to change the UUID and then possibly re-run 'grub update' so that the new UUID is copied into the grub config files. I hope it does!

It will take more time for testing as I have to include these extra steps but if it's reliable and work nicely I can live with it.

And nothing prevents me from using disk-ID in fstab.

Ok I understand the concern. It seems in my specific situation it would work fine but not as default when looking into all configurations.

Ok, I'll change my method and update my procedures and live with it, since it's the way the market is moving forward with grub2.

tnx!

Duplicate UUIDs is a problem indeed. I wasn't sure the commands you listed where actually assigning new UUIDs without reformatting, that was the part I was missing. I will keep them in note for when I need them.

I have realized I made some mistakes when I tested before logging the issue, so the fact grub is not bootable has nothing to do with grub2, grub-legacy, UUIDs or other, it seems to affect Kubuntu 11.10 so I logged that part in Launchpad for Kubuntu. Please disregard all the mention about "not bootable after a clone". The rest about the UUIDs being duplicated after a clone is moved as feature and I agree.

tnx for the commands and explanation!

Ok well I realized I mentioned 2 problems in one ticket. The other problem may be Kubuntu related so I will open on there.

For the UUIDs, the disk IDs are reliable on my machine, so I'll agree with you as I don't know for other machines. Let's keep this as a feature.

Could you tell me how to change and assign UUIDs without reformatting a partition? I have not found anything clear on that yet.

tnx

--This problem is also logged at https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/920144--


grub2 v1.99 included with Kubuntu 11.10.

I have 2 identical disks, the only difference being their manufacturer serial number (disk ID).

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.

With grub2 I realized it really wants to use UUIDs everywhere, which I had to fight for. I don't think the approach of grub2 fits for everyone as UUIDs are NOT unique, therefore when you clone partitions or disks the UUIDs are the same on both partitions or disks. This is a very bad method. So I told grub2 not to use UUIDs and I have put DEVICE ID (/dev/disk/by-id/ata-etc...) in the FSTAB and grub.cfg (using 40_custom script). This method is the only one which gives unique identifiers to a partition, not even device name does (sda, sdb can be swapped, so that's not unique). It works fine on my grub2 disk. But only on the disk I have 'installed' grub2 to. The one I clone it to does not work.

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

If I install grub2 on DISK2 connected alone (it becomes sda1), I can boot it if it's alone or connected as first drive. grub-legacy cannot chainload to grub2 so I cannot chainload if the disk is 2nd in order. But I can boot directly from a menu in grub-legacy.

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

But if I image sdb1 on DISK2 and restores it to sdb1 on DISK2, it works! On another disk, it doesn't.

Even if the UUIDs are the same on both disks, DISK1 should be able to boot after being cloned if it's alone connected. But it does not.

This problem is not existent with grub-legacy.
My needs go beyond UUIDs and I need disk and partition cloning to work properly.

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

Thank you