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?

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

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

Solution 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)

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

Solution 5

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.

View more solutions

Comments

[goldilocks]

You need to clarify which device you are talking about. /dev/sdb will not have a UUID, but /dev/sdb1 should if it has been formatted.

[David Kegyes]

I'm referring to /dev/sdb1 which is under /dev/sdb

[goldilocks]

Post the output of fsck -n /dev/sdb1. You could also try to give it a UUID with tune2fs -U random /dev/sdb1 then see. It doesn't matter what the UUID is.

[David Kegyes]

posted [sorry if this is getting annoying]

[goldilocks]

No problem. The "superblock invalid" bit may explain why there is no UUID. If you need to back up stuff there, try mounting it and doing that, then unmount and fsck -y /dev/sdb1; if you can't mount it, just run the fsck and hopefully nothing is lost. Read man fsck for the difference between -n and -y.

[David Kegyes]

I'm not worried about lost files, this is a newly formated drive.

[David Kegyes]

SDA is my main drive. SDB, SDD, etc are USB drives. I've updated my answer to include fdisk -l to prove that it has a partition.

[goldilocks]

@monksy: and the device node which does not report a UUID is /dev/sdb1 or /dev/sdb? The later should not. Also, fdisk output does not indicate that a partition is formatted, and thus, does not prove that it should have a UUID available. I've added a few short paragraphs above to explain this.

[David Kegyes]

It is formated. When plugged in [pre fstab items] gnome automounter would bring it up. I'm not getting an UUID for sdb1. The fdisk -l is just proof that there is a partition there

[fazy]

I had to reboot before the partition showed up in /dev/disk/by-uuid (Ubuntu 16.04 but probably affects others). So (1) create partition(s) and filesystem(s), (2) reboot. There's probably a non-reboot way but I preferred to check that everything comes up from a cold boot so didn't investigate.

[goldilocks]

@Jay Point taken. The device in the question is MBR formatted, and GPT disks were still quite new in the linux world when this was first written in early 2013 (support for it in fdisk was only added in late 2012: git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commi‌​t/…) but I have added a footnote about this and the PARTUUIDs used on MBR disks.

[Caglayan DOKME]

The same problem occurred while using an SD card with two partitions, FAT and EXT4. The EXT4 partition didn't show up without using sudo prior to blkid. sudo blkid | grep mmc works now. Thanks :)

[TheArchitecta]

Dis you try blkid with sudo? sudo blkid always return the UUIDs for me.