Bug 1248003 - mount only parses <param>=<value> lines from fstab fs_spec field available from blkid block device
mount only parses <param>=<value> lines from fstab fs_spec field available fr...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: util-linux (Show other bugs)
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Karel Zak
Depends On:
Blocks: 1289485 1313485
  Show dependency treegraph
Reported: 2015-07-29 08:33 EDT by Álvaro Simón
Modified: 2016-11-03 17:25 EDT (History)
6 users (show)

See Also:
Fixed In Version: util-linux-2.23.2-31.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-11-03 17:25:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Álvaro Simón 2015-07-29 08:33:51 EDT
Description of problem:
This issue affects Ceph fuse (http://ceph.com/docs/master/cephfs/fstab/) but it can also affect many other filesystems.

I have tested a bit this with different ceph-fuse versions and linux
distros and it seems a mount issue in RHEL7. The problem is that mount
tries to find first the <param>=<value> from fstab fs_spec field into
the blkid block device attributes and of course this flag is not there
and you always get an error like this:

mount: can't find <param>=<value>

and stops here, the mount values are never parsed by
/sbin/mount.fuse.ceph helper...

The only workaround that I found without change mount version is to
change the "spurious" = by another special character like a colon in our fstab file, as example:

id:admin  /mnt/ceph fuse.ceph defaults 0 0

but you also have to change /sbin/mount.fuse.ceph parser:

# convert device string to options
fs_spec=`echo $1 | sed 's/:/=/g'`
cephargs='--'`echo $fs_spec | sed 's/,/ --/g'`

This issue affects RHEL7 (is working fine in RHEL6)

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

How reproducible:
Include into fstab a <param>=<value>.. into fs_spec field that is not available from blkid block device list.

Steps to Reproduce:
1. Ceph example (http://ceph.com/docs/master/cephfs/fstab/), insert into /etc/fstab:

id=admin  /mnt/ceph fuse.ceph defaults 0 0

2. Try to mount the directory:
# mount /mnt/ceph

Actual results:
mount: can't find id=admin

Expected results:
ceph-fuse: starting fuse

Additional info:
Comment 2 Karel Zak 2015-07-29 10:02:32 EDT
Fixed by upstream commit 2c6b25f01802808b142d450af3352605720899da (already available in >= v2.24, RHEL7 uses v2.23).

Just for the record:

  id=myuser,conf=/etc/ceph/cluster.conf  /mnt/ceph2  fuse.ceph defaults 0 0

Yes, mount(2) syscall and userspace assume that FS identifier (1st column) is arbitrary string and it's fine to use it for things like //server.com/path or so,
but use the 1st column to configure your FS stuff by name=value list is *ugly* and it's obvious that author of this brain dead idea has zero sense for system stuff.

We have 4th column for configuration, if you need to configure multiple things then you can use namespaces (e.g "ceph."), like "foo=bar,ceph.id=myuser,cept.conf=/path".
Comment 3 Álvaro Simón 2015-07-30 02:44:16 EDT
Ok thanks a lot for the info!
Comment 4 Álvaro Simón 2015-07-30 03:17:43 EDT
Just for the record, we have included the patch and generated a new rpm, everything is working now! the *ugly* name=value is parsed correctly :-)

It would be possible to include this patch in the next RHEL7 update?

Cheers and thanks
Comment 5 Karel Zak 2015-07-30 03:54:17 EDT
Well, Red Hat bugzilla is not the right place to ask for RHEL support and I don't want to promise anything here. From my point of view it's too late for RHEL7.2, it seems more promising to have it in 7.3.

Please, contact official support.redhat.com if you want to discus this topic. Thanks.
Comment 7 Mike McCune 2016-03-28 18:54:17 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 12 errata-xmlrpc 2016-11-03 17:25:00 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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