UUID of a drive that won't show up in /dev/disk/by-uuid or blkid

Question

I have a USB drive that is not receiving a UUID. When I look at the contents of the /dev/disk/by-uuid it doesn't exist there. The dev point that the partition lives in is on /dev/sdb. I am able to see sdb under /dev/disk/by-path. Also, when using blkid, I get zero output. I'm assuming that I got an error code that returned back.

Is there a way to get a UUID for this partition?

Result of fdisk -l /dev/sdb:

Disk /dev/sdb: 320.1 GB, 320072932352 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142446 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00082145

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   625141759   312569856   83  Linux

The partition table and partition was created with gparted, so it was partitioned and ran the command mkfs.ext3.

Output of fsck -n /dev/sdb1:

fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
fsck.ext2: Superblock invalid, trying backup blocks...
zwei was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
zwei: 11/19537920 files (0.0% non-contiguous), 1275097/78142464 blocks

It was formatted as an ext3 drive. Why is that showing up as ext2?

Answer 1

That's what's supposed to happen.

There are two colloquial uses of the term "disk" or "drive" in play here: the first one refers to a physical device such as a usb stick. The second refers to a filesystem partition, of which there may be several on one physical device.

Device nodes like /dev/sda refer to the first sense (physical devices); device nodes like /dev/sda1 refer to the second (filesystem partitions). Make sense? sda1 is a filesystem partition on physical disk sda. It is possible to format an entire device with one partition, but that is unusual, so in general, /dev/sda will never have a UUID.

Filesystem partitions have UUIDs, physical devices do not.¹ I believe they are created randomly when the filesystem is created (which is why they will change if you, eg, reformat a partition, and why if you block level copy a partition and create a new partition with the image, you will have two partitions with the same UUID).

So, keep in mind the UUID is created when the partition is formatted. When you partition a disk (eg, with fdisk), you are not formatting anything, you are just setting the partition type (and size, etc) in the partition table, so the new unformatted partitions do not have a UUID.

Finally, since it is the tool used to format the partition that sets the UUID, it may be possible that very old tools may not do this. However, you can always set a new one (for ext) with tune2fs, eg:

tune2fs -U random /dev/whatever

---

1. Apparently GPT formatted ones do, although the device in the question is implicitly MBR formatted (it does not have an EFI partition, and fdisk either indicates a GPT disk or for older versions report it as unsupported).

   It should also be noted, though, that MBR formatted disks do have a similar identifier that is combined with a per partition index, such that partitions containing filesystems that can't keep their own UUID (eg.vfat) can have a unique "PARTUUID"; this can be used much the same way for many things (eg., in fstab, with udev, and for mounting) but it is not a true 128-bit UUID.

   The 32-bit base of the PARTUUID is shown in fdisk output from the question: Disk identifier: 0x00082145.

Answer 2

Try sudo with the ls -l /dev/disk/by-uuid or blkid /dev/sdb1

I have a partitioned+formatted sdb1 also, for some reason it doesn't show up in the list unless I use sudo.

Answer 3

I have found that file -s can give the UUID for a partition in a case where blkid will not:

sudo file -s /dev/sda1
/dev/sda1: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=ef55765f-dae5-426f-82c4-0d98265c5f21 (needs journal recovery)

If it detects something else (e.g. DOS/MBR boot sector), try adding -k to return all matches.

Answer 4

The /dev/disk/by-uuid is populated on boot by program "partprobe". If you have disk or partition that partprobe can not recognize, then partprobe fails with error and stops scanning rest of partitions:

root@machine1:~# partprobe 
Error: /dev/mapper/sda5_crypt: unrecognised disk label
root@machine1:~# 

That's obviously error on partprobe part. Probably specific to ubuntu 14.04 (trusty). The workaround is to run partprobe explicitly on the partition that was not scanned:

root@machine1:~# partprobe /dev/sdd1

Note that partprobe is started many times are result of every disk-managing operation, so the workaround is short-lived.

Answer 5

You ask,

Is there a way to get a UUID for this partition?

You can also use: lsblk -f to get UUIDs.

Answer 6

I could also not get the UUID from blkid and sudo file -s /dev/sda1 worked for me and I was able to get a UUID.

Answer 7

Even when the partition uses the whole disk, and the partition is mounted, the UUID may still be missing from /dev/disk/by-uuid and from blkid output.

Ways to see the UUID for such a partition, let's say, /dev/sdc:

• sudo file -s /dev/sdc (see mwfearnley's answer)
• sudo tune2fs -l /dev/sdc | awk '/UUID/ {print $NF}'

Answer 8

Traditionally /dev/disk/by-uuid/ is meant for filesystem UUIDs. With GPT partitioned disks, there is actually a UUID associated with a disk. So if you want your GPT partitioned disk to appear under /dev/disk/by-uuid, you can simply add the following udev rule:

ENV{DEVTYPE}=="disk", ENV{ID_PART_TABLE_UUID}=="*", SYMLINK+="disk/by-uuid/$env{ID_PART_TABLE_UUID}"