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
The solution given to this question over on SuperUser deserves its own cross-reference here. Note that this answer here is a Community Wiki so none of us get credit for the replication.
How to access a BitLocker-encrypted drive in Linux?
The Github code checkins are recent so - as of May 2016 - this is still an active project.
Best Answer
When setting up a disk or partition there are 2 aspects to doing this. The first is the act of laying down a partition table scheme on the disk using typically either MBR (Master Boot Record) or GPT (GUID Partitioning Table) formats. Both of these lay down a "structure" on the disk.
MBR
If you take a look at the structure of an MBR you'll notice that there is a section allotted for defining a partitions "type".
The valid partition types for MBR:
So in your case the partition is identified as being of type 17.
Filesystem format
The second aspect to this is the formatting of the space within the partition itself (the filesystem). These are the filesystems that most are more familiar with when dealing with EXT3/4, etc.
So in your case you've mixed a partition type and a filesystem that generally don't go together. I should mention here that tools such as
fdisk
are "dumb" in the sense that they'll generally let you do whatever you want whether it makes sense to do so or not.Changing the partition's type
So to resolve your issue you'll need to change the partition type to 83 if it's a bare partition being formatted as EXT4, or 8e if it's an LVM partition. The good news is you can use
fdisk
to change the partitions type through thet
function:After successfully doing this your partitions should looks something like this:
What I would do!
However in your case since the partition type appears to be listed already as 83 and the partition is reported as being HPFS/NTFS, I think I'd be inclined to delete the partition(s) all together and start over with a clean slate.