Bug 632373

Summary:	util-linux-ng does not recognize the UUID in a GFS2 partition
Product:	[Fedora] Fedora	Reporter:	Madison Kelly <mkelly>
Component:	util-linux-ng	Assignee:	Karel Zak <kzak>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	13	CC:	kzak, lhh
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-09-13 09:23:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Madison Kelly 2010-09-09 19:13:06 UTC

Description of problem:

If you create a GFS2 partition and then try to add it to '/etc/fstab' using it's 'UUID=...', it fails to find the underlying device path. Same if you try to find it with 'findfs'.

Version-Release number of selected component (if applicable):

util-linux-ng-2.17.2-8.fc13.x86_64
gfs2-utils-3.0.14-1.fc13.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Create a GFS2 partition
2. Run 'gfs2_edit -p sb /dev/drbd_vg0/xen_store | grep sb_uuid'
3. Run 'findfs UUID=<uuid returned in step 2>
  
Actual results:

# gfs2_edit -p sb /dev/drbd_vg0/xen_store | grep sb_uuid
  sb_uuid               A1487063-2A3F-43B1-3A36-44936B0B4D1E
# findfs UUID=A1487063-2A3F-43B1-3A36-44936B0B4D1E
findfs: unable to resolve 'UUID=A1487063-2A3F-43B1-3A36-44936B0B4D1E'

Expected results:

That 'findfs' it would return the device path. In turn, that gfs2 could find the device path when /etc/fstab has a 'UUID=A1487063-2A3F-43B1-3A36-44936B0B4D1E' device entry (using the UUID from the above example).

Additional info:

Comment 1 Lon Hohberger 2010-09-09 19:34:17 UTC

I did a little more investigation.  It turns out that findfs (and likely mount) simply expects lower case lettering for hexadecimal UUIDs:

[root@snap ~]# findfs UUID=5CFE530C-E298-EF20-711B-48AA5039B62D
findfs: unable to resolve 'UUID=5CFE530C-E298-EF20-711B-48AA5039B62D'
[root@snap ~]# findfs UUID=`echo 5CFE530C-E298-EF20-711B-48AA5039B62D | tr A-Z a-z`
/dev/vdb3

According to http://www.ietf.org/rfc/rfc4122.txt - UUID inputs are not supposed to be case sensitive.

Comment 2 Karel Zak 2010-09-13 09:23:04 UTC

(In reply to comment #1)
> According to http://www.ietf.org/rfc/rfc4122.txt - UUID inputs are not supposed
> to be case sensitive.

More precisely: The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.

The libblkid uses conversion from internal binary UUID representation to lower-case string when it reads uuid from a filesystem superblock. 

All the others operations are based on these strings. So mount, fsck and findfs use tags (e.g. UUID= or LABEL=) as strings. It does not convert UUID= from fstab or command line to the binary representation

It seems that this behaviour is not properly documented. I'll update mount and fstab man pages. Thanks for your report.

Comment 3 Lon Hohberger 2010-09-13 15:06:10 UTC

Shouldn't findfs, mount, etc. should be simply lower-casing things when it gets UUID= then?

There is not a lot of magic required to make this work correctly.

Comment 4 Madison Kelly 2010-09-13 15:23:17 UTC

Updating the docs is good, but as Lon mentioned, it shouldn't be hard to implement case insensitive input strings. This would be in-line with the RFC and solve the problem of us pesky users who don't read the fine manuals in close detail. :)

Comment 5 Karel Zak 2010-09-15 08:51:49 UTC

(In reply to comment #3)
> Shouldn't findfs, mount, etc. should be simply lower-casing things when it 
> gets UUID= then?

Some filesystem (exfat, vfat, hpfs, ntfs, ...) use convention that the ID is upper-case string...

(In reply to comment #4)
> Updating the docs is good, but as Lon mentioned, it shouldn't be hard to
> implement case insensitive input strings. This would be in-line with the RFC

The problem is that UUID= tag does not mean the standard (DCE) UUIDs. Some filesystems use non-standard IDs or store the ID in superblock as a string.

> and solve the problem of us pesky users who don't read the fine manuals in
> close detail. :)

I understand your point of view... and I'll think about it ;-)