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?
On 06/14/2015 07:55 PM, Timothy Murphy wrote:
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?
Interesting. And I thought uuid's were supposed to be unique on a system.
On 06/14/2015 08:58 PM, John R Pierce wrote:
On 6/14/2015 6:55 PM, Timothy Murphy wrote:
Maybe I used dd at some point. Would this keep the same UUID?
DD just does a blind block by block copy between two devices or files.
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-eve... 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...
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/libuuidwhich is used by |uuidgen|and especially by the ext2/3/4 tools E2fsprogs to generate UUIDs:
$ uuidgen f81cc383-aa75-4714-aa8a-3ce39e8ad33c
On 06/14/2015 10:08 PM, jd1008 wrote:
On 06/14/2015 08:58 PM, John R Pierce wrote:
On 6/14/2015 6:55 PM, Timothy Murphy wrote:
Maybe I used dd at some point. Would this keep the same UUID?
DD just does a blind block by block copy between two devices or files.
I thought that uuid had nothing to do with drive content, so dd would have (should have had) nothing to do with it.
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/.
On 06/15/2015 07:56 AM, Robert Nichols wrote:
On 06/14/2015 10:08 PM, jd1008 wrote:
On 06/14/2015 08:58 PM, John R Pierce wrote:
On 6/14/2015 6:55 PM, Timothy Murphy wrote:
Maybe I used dd at some point. Would this keep the same UUID?
DD just does a blind block by block copy between two devices or files.
I thought that uuid had nothing to do with drive content, so dd would have (should have had) nothing to do with it.
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.
On Mon, 15 Jun 2015, jd1008 wrote:
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
On 15.06.2015 18:13, John Hodrien wrote:
On Mon, 15 Jun 2015, jd1008 wrote:
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.
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
On 6/15/2015 9:08 AM, jd1008 wrote:
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?
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.
On 06/15/2015 11:08 AM, jd1008 wrote:
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?
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 Mon, 2015-06-15 at 21:41 -0500, Robert Nichols wrote:
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:-
/dev/sda5: LABEL="a5u" UUID="3cbc7570-30b8-4970-a0df-a9a9602770d0" TYPE="ext4" /dev/sda2: UUID="e954fbaa-dc51-46dc-a352-cceb439080e5" TYPE="crypt_LUKS" /dev/ram0: UUID="49b98b86-116a-469b-b6de-a157bb0a12dd" TYPE="ext2" /dev/sda1: LABEL="d6sys" UUID="cd632820-0701-4a6a-b329-6798b6a29966" TYPE="ext3" SEC_TYPE="ext2"
On Tue, 16 Jun 2015, Always Learning wrote:
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
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.
I encrypted some of those partitions.
The 'blkid' command produces a list of UUIDs for those partitions.
A few examples:-
/dev/sda5: LABEL="a5u" UUID="3cbc7570-30b8-4970-a0df-a9a9602770d0" TYPE="ext4" /dev/sda2: UUID="e954fbaa-dc51-46dc-a352-cceb439080e5" TYPE="crypt_LUKS" /dev/ram0: UUID="49b98b86-116a-469b-b6de-a157bb0a12dd" TYPE="ext2" /dev/sda1: LABEL="d6sys" UUID="cd632820-0701-4a6a-b329-6798b6a29966" TYPE="ext3" SEC_TYPE="ext2"
LUKS provides a UUID, so being encrypted isn't a barrier to having a UUID.
jh
On Tue, 2015-06-16 at 11:30 +0100, John Hodrien wrote:
On Tue, 16 Jun 2015, Always Learning wrote:
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
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.
Yes you are correct. Maximum 4 primary or maximum 3 primary and 1 extended which is then sub-divided into more partitions.
LUKS provides a UUID, so being encrypted isn't a barrier to having a UUID.
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
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.
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.
On Tue, 16 Jun 2015, Always Learning wrote:
But my point was M$ DOS partitions, not being GPT partitions, can have UUIDs. The original poster appeared to suggest that was not possible.
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.
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.
You never mount a partition, only a filesystem. The partition merely points you to where the filesystem is.
jh
On 16 Jun 2015 12:12, "Always Learning" centos@u64.u22.net wrote:
On Tue, 2015-06-16 at 11:30 +0100, John Hodrien wrote:
On Tue, 16 Jun 2015, Always Learning wrote:
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
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.
Yes you are correct. Maximum 4 primary or maximum 3 primary and 1 extended which is then sub-divided into more partitions.
LUKS provides a UUID, so being encrypted isn't a barrier to having a
UUID.
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
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.
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.
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.
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.
On 06/16/2015 06:43 AM, James Hogarth wrote:
On 16 Jun 2015 12:12, "Always Learning" centos@u64.u22.net wrote:
On Tue, 2015-06-16 at 11:30 +0100, John Hodrien wrote:
On Tue, 16 Jun 2015, Always Learning wrote:
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
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.
Yes you are correct. Maximum 4 primary or maximum 3 primary and 1 extended which is then sub-divided into more partitions.
LUKS provides a UUID, so being encrypted isn't a barrier to having a
UUID.
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
Those were filesystem UUIDs not partition UUIDs ...
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.
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.
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.
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.
On 06/16/2015 09:00 AM, Robert Nichols wrote:
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.
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.
Am 16.06.2015 um 12:23 schrieb Always Learning centos@u64.u22.net:
On Mon, 2015-06-15 at 21:41 -0500, Robert Nichols wrote:
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.
these are the ids of the filesystems.
-- LF
On 6/16/2015 3:23 AM, Always Learning wrote:
The 'blkid' command produces a list of UUIDs for those partitions.
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.
-
Always Learning -
Dennis Jacobfeuerborn -
James Hogarth -
jd1008 -
John Hodrien -
John R Pierce -
Leon Fauster -
Robert Nichols -
Timothy Murphy