Two Partitions With Samd UUID??

Home » CentOS » Two Partitions With Samd UUID??
CentOS 18 Comments

I seem to have partitions on two different disks with the same UUID:
[tim@helen ~]$ sudo blkid /dev/sda2
/dev/sda2: LABEL=”/boot1″ UUID=”5bbc8e95-6108-41f5-bc0e-5b5f8df5ce03″
TYPE=”ext3″
[tim@helen ~]$ sudo blkid /dev/sdb2
/dev/sdb2: LABEL=”/boot1″ UUID=”5bbc8e95-6108-41f5-bc0e-5b5f8df5ce03″
TYPE=”ext3″
This is causing some confusion, as these are boot partitions, and grub2 seems to be choosing the wrong one.

I wonder how this occurred;
I thought different partitions on different disks necessarily had different UUIDs?

Maybe I used dd at some point. Would this keep the same UUID?

18 thoughts on - Two Partitions With Samd UUID??

  • I thought that uuid had nothing to do with drive content, so dd would have (should have had) nothing to do with it. I thought it had to do with information when the device is queried (manufacturer’s name (id), device model, date of manufacturer, serial number ….etc). But …. https://liquidat.wordpress.com/2013/03/13/uuids-and-linux-everything-you-ever-need-to-know/
    says:
    After generating 1 billion UUIDs every second for the next
    100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs. Linux generates uuids in the file listed at https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=refs/tags/v3.8

    and you can generate new ones via proc:

    $ cat /proc/sys/kernel/random/uuid eaf3a162-d770-4ec9-a819-ec96d429ea9f

    There is also the library libuuid
    <http://linux.die.net/man/3/libuuid>which is used by |uuidgen|and especially by the ext2/3/4 tools E2fsprogs to generate UUIDs:

    $ uuidgen f81cc383-aa75-4714-aa8a-3ce39e8ad33c

  • You thought wrong. The UUID for a GPT partition is a number that is recorded in the GPT. The UUID for a filesystem is a number that is recorded in the filesystem super block. The UUIDs for LVM physical or logical volumes are numbers recorded in the LVM header. Etc., etc., etc. When you use dd to copy them, the UUIDs get copied too, and significant confusion can result.

    Now, the drive itself does have a UUID derived from information that includes the serial number. But, unless you are referencing the drive by /dev/disk/by-uuid/*, you are not making use of it. I’ve occasionally used /dev/disk/by-id/xxx to select a particular drive partition that could not be reliably identified in any other way (encrypted swap partition on a non-GPT drive), but I don’t recall ever using /dev/disk/by-uuid/.

  • Thanx for the update but what about non-gpt and non lvm partitions?
    What is used as inp nut to create a universally unique id?

    (Actually, for an id to be universally unique, one would almost nee knowledge of all existing id’s. So, I do not have much credence in this universal uniqueness.

  • Sufficiently random gets you there, since you’re not connecting billions of filesystems to a single system. If you really want to generate them by hand, feel free, as mkfs.ext4 lets you specify the filesystem UUID.

    I think you’re finding a problem where one does not exist.

    jh

  • The UUID optionally used for mounting has nothing to do with GPT or LVM, its a label in superblock of the FILE system contained in the logical partition or volume.

  • Or if you are in the situation of the original poster and made a copy using dd use tune2fs -L and -U to modify label and uuid of the copy.

    Regards,
    Dennis

  • Non-GPT partitions do not have a UUID. The _content_ (filesystem, LVM physical volume, non-encrypted swap space, etc.) of such a partition could have a UUID, but the partition itself does not.

  • ON CentOS 5, using GPARTED I created partitions for filing systems ext3
    and ext4. 4 primary and unlimited (except by space) extended partitions. That suggests those partitions are not GPT but old fashioned M$DOS

    I encrypted some of those partitions.

    The ‘blkid’ command produces a list of UUIDs for those partitions.

    A few examples:-

  • If it is old fashioned MSDOS, you can have four total primary and extended, not four primary plus extended. An extended partition then provides a container for further logical partitions.

    LUKS provides a UUID, so being encrypted isn’t a barrier to having a UUID.

    jh

  • Yes you are correct. Maximum 4 primary or maximum 3 primary and 1
    extended which is then sub-divided into more partitions.

    But my point was M$ DOS partitions, not being GPT partitions, can have UUIDs. The original poster appeared to suggest that was not possible. He wrote

    When I think I am mounting a M$ DOS partition, am I mounting a real partition or merely ‘the file system’ within that partition ? Some may think one can’t have one without the other.

  • No, the partition there does not have a UUID. Run fdisk, create a partition, dd if=/dev/zero of=/dev/sda4

    blkid

    You’ll see no UUID, as the partition does not provide a UUID, and there’s nothing on it to provide a UUID. Format it, or make some swap space or whatever, and you get a UUID.

    You never mount a partition, only a filesystem. The partition merely points you to where the filesystem is.

    jh

  • ext3
    partitions. extended, UUID.

    Those were filesystem UUIDs not partition UUIDs …

    LUKS has its own header similar to ext4, lvm, etc headers which has a UUID
    in it.

    This UUID being associated with the LUKS header indicates it is not a partition UUID.

    A dd of this (or lvm snapshot) to another partition will keep the same UUID.

    A partition UUID within a GPT table would not be persisted in this manner, and msdos labeled disks have no concept of this to begin with.

    Of course you can have a partition or filesystem without the other. This is how raw devices work and you can mkfs a block device with no partitions.

    When you mount something you mount the filesystem.

  • Am 16.06.2015 um 12:23 schrieb Always Learning :

    these are the ids of the filesystems.

  • LUKS physical volume UUIDs, actually. When you create a LUKS logical volume within that PV, it also has a UUID, and a filesystem within that LUKS LV will have its own UUID. These are all part of the partition’s
    _content_. A GPT partition has its own UUID, independent of the partition’s content. An MSDOS partition does not.

    Indeed. If your version of cryptsetup is new enough (supports the
    “–header” option), try doing the luksFormat operation with a detached header. Now you will find that your LUKS partition no longer has a UUID.

  • I obviously had LVM on my mind when I wrote that. Sorry. The principle still holds, though. A filesystem within that LUKS container has its own UUID, separate from the LUKS UUID.

  • those are the UUID’s of the file systems contained in the partitions, which is NOT the same thing as the UUID that GPT uses to identify the partition itself.