Bug 632373 - util-linux-ng does not recognize the UUID in a GFS2 partition
Summary: util-linux-ng does not recognize the UUID in a GFS2 partition
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux-ng
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-09 19:13 UTC by Madison Kelly
Modified: 2010-09-15 08:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-13 09:23:04 UTC
Type: ---


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.