Bug 1248003 - mount only parses <param>=<value> lines from fstab fs_spec field available from blkid block device
Summary: mount only parses <param>=<value> lines from fstab fs_spec field available fr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: util-linux
Version: 7.1
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Karel Zak
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1289485 1313485
TreeView+ depends on / blocked
 
Reported: 2015-07-29 12:33 UTC by Álvaro Simón
Modified: 2016-11-03 21:25 UTC (History)
6 users (show)

Fixed In Version: util-linux-2.23.2-31.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 21:25:00 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2605 normal SHIPPED_LIVE Low: util-linux security, bug fix, and enhancement update 2016-11-03 12:13:26 UTC
Red Hat Bugzilla 1360849 None None None Never

Internal Links: 1360849

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@redhat.com 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


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