Bug 1248003

Summary: mount only parses <param>=<value> lines from fstab fs_spec field available from blkid block device
Product: Red Hat Enterprise Linux 7 Reporter: Álvaro Simón <varosim>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.1CC: charlesalva, jscotka, kdreyer, kvolny, mbroz, riehecky
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: util-linux-2.23.2-31.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-03 21:25:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1289485, 1313485    

Description Álvaro Simón 2015-07-29 12:33:51 UTC
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):
util-linux-2.23.2-22


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 14:02:32 UTC
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 06:44:16 UTC
Ok thanks a lot for the info!

Comment 4 Álvaro Simón 2015-07-30 07:17:43 UTC
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
Alvaro

Comment 5 Karel Zak 2015-07-30 07:54:17 UTC
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 22:54:17 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 12 errata-xmlrpc 2016-11-03 21:25:00 UTC
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.

https://rhn.redhat.com/errata/RHSA-2016-2605.html