bugGNU GRUB - Bugs: bug #35354, add a search option for diskids


You are not allowed to post comments on this tracker with your current authentication level.

bug #35354: add a search option for diskids

Submitter:  Francis Lamonde <frankkubuntu>
Submitted:  Mon 23 Jan 2012 01:38:07 AM UTC
Category:  Booting Severity:  Minor
Priority:  1 - Later Item Group:  Feature Request
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  FrankKubuntu
Open/Closed:  Open Release:  other
Release:  Reproducibility:  Every Time
Planned Release:  2.03+

Jump to the original submission

Thu 26 Apr 2012 05:53:43 AM UTC, comment #12: 

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.

Vladimir Serbinenko <phcoder>
Group administrator
Thu 26 Apr 2012 01:06:54 AM UTC, comment #11: 

I agree sometimes it is very useful to have UUID and search for them, but ...when the partitions or disks are on the same machine, only. Having the same UUID on different PC's should be no issue for GRUB.
So how is this problem that after cloning SECTOR by SECTOR two identical disks (excepto for ...serial number? disk uuid ?) you have to reinstall grub forcibly?

I have been trying to get to it some time now, and I am not cloning 1 or 10 pc's ...It breaks all the cloning scheme , programs etc etc that have been used for years.

So what's left? Read the full source code to find out ?

This was not happening before, so what is the change the came to this flaw?

Felipe Solari <flip66>
Wed 01 Feb 2012 06:33:36 PM UTC, comment #10: 

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.

Francis Lamonde <frankkubuntu>
Wed 01 Feb 2012 06:09:23 PM UTC, comment #9: 

I think you didn't understand what I was saying: GRUB uses BIOS to access disks by default. And BIOS disk driver (known as int 13h) has no function to get the ID.

As to the need of updating UUIDs in configs, you need it with disk ids as well.
Also even when using disk ids btrfs uses UUID to assembly the different members to a consistent FS. With duplicates you can end up with one original disk being matched with a clone and so have an utter mess.

Vladimir Serbinenko <phcoder>
Group administrator
Wed 01 Feb 2012 05:49:58 PM UTC, comment #8: 

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.

Francis Lamonde <frankkubuntu>
Wed 01 Feb 2012 05:39:28 PM UTC, comment #7: 

Actually supposing that you're on BIOS, there is simply no way to ask the device id from BIOS.
And UUID trend is older than GRUB2. And as I mentioned before some FS and other structures will have problems in case of duplicate UUID.

Vladimir Serbinenko <phcoder>
Group administrator
Wed 01 Feb 2012 05:31:32 PM UTC, comment #6: 

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.


Francis Lamonde <frankkubuntu>
Wed 01 Feb 2012 03:38:37 PM UTC, comment #5: 

Looking into specs I discovered that this info is unavailable through BIOS. So while having sth like this is possible in platforms that support it or if you use direct disk modules, it's not viable as any kind of default.

Vladimir Serbinenko <phcoder>
Group administrator
Sat 28 Jan 2012 02:54:40 PM UTC, comment #4: 

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!

Francis Lamonde <frankkubuntu>
Sat 28 Jan 2012 02:46:49 PM UTC, comment #3: 

The part "as available through BIOS" wasn't gratuituous. Many BIOSes give garbage instead of ID.
Also I wanted to mention that with duplicate UUIDs you may also run into other problems like RAID or btrfs misassembly.

To change UUID on ext*:
tune2fs -U random /dev/sdXN
on xfs:
xfs_admin -U generate /dev/sdXN
on jfs:
jfs_tune -U random /dev/sdXN
on nilfs2:
nilfs-tune -U `uuid -v 4`/dev/sdXN
on reiserfs:
reiserfs-tune -U `uuid -v 4`/dev/sdXN

Vladimir Serbinenko <phcoder>
Group administrator
Sat 28 Jan 2012 02:33:45 PM UTC, comment #2: 

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.


Francis Lamonde <frankkubuntu>
Sat 28 Jan 2012 01:12:58 PM UTC, comment #1: 

Having same UUID for 2 different filesystems is recognised as an error and not running FS-specific tool to change UUID after clonning is a mistake. The disk IDs available through BIOS are unreliable. Having such extension is possible as long as it's not increasing the size of critical modules but it's minor.
So this makes it a feature request with minor priority.

Vladimir Serbinenko <phcoder>
Group administrator
Mon 23 Jan 2012 01:38:07 AM UTC, original submission:  

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


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

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

Francis Lamonde <frankkubuntu>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by flip66 (Posted a comment)
  • -email is unavailable- added by ridikulus_rat
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by frankkubuntu (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-02 phcoder Planned ReleaseNone 2.03+
    2012-04-20 ridikulus_rat Carbon-Copy- Added ridikulus_rat
    2012-02-01 phcoder Priority5 - Normal 1 - Later
        SummaryCloning GRUB2 1.99 makes clone not bootable add a search option for diskids
    2012-01-28 phcoder SeverityMajor Minor
        Item GroupSoftware Error Feature Request

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code