RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1319853 - -c option exits with 'requires a path to check' error, but path is there
Summary: -c option exits with 'requires a path to check' error, but path is there
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: device-mapper-multipath
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ben Marzinski
QA Contact: Lin Li
Steven J. Levine
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-21 16:30 UTC by mulhern
Modified: 2021-09-03 11:57 UTC (History)
7 users (show)

Fixed In Version: device-mapper-multipath-0.4.9-89.el7
Doc Type: Bug Fix
Doc Text:
Multipath now states that a path is `not a valid argument` for paths that do not belong to block devices Previously, if you used a path to something that is not a valid block device, multipath would tell you that it `requires a path to check`, which is unhelpful. This is because multipath considered anything that is not a block device path or major:minor number to be a multipath alias. With this fix, multipath will not treat fully qualified paths to anything that is not a block devices as a multipath alias. As a result, multipath will state the that path is `not a valid argument` for paths that do not belong to block devices.
Clone Of:
Environment:
Last Closed: 2016-11-04 08:19:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1319819 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 1319870 0 unspecified CLOSED udevadm info fails to display some partition devices when specified by name 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1323806 0 unspecified CLOSED kpartx creates linear devices corresponding to partitions which have no device file 2021-09-03 12:11:20 UTC
Red Hat Product Errata RHBA-2016:2536 0 normal SHIPPED_LIVE device-mapper-multipath bug fix and enhancement update 2016-11-03 14:18:10 UTC

Internal Links: 1319819 1319870 1323806

Description mulhern 2016-03-21 16:30:57 UTC 
Description of problem:

multipath -c /dev/<partition device> gets error

gets error:

the -c option requires a path to check

but path is there.

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

Installed Packages
Name        : device-mapper-multipath
Arch        : x86_64
Version     : 0.4.9
Release     : 85.el7
Size        : 178 k
Repo        : installed
From repo   : RHEL-7.2
Summary     : Tools to m

How reproducible:

Consistently.
[root@megadeth pydevDAG]# multipath -c /dev/sde1
Mar 21 12:22:05 | the -c option requires a path to check

Steps to Reproduce:
1. multipath -c /dev/<partition device>

Note that due to a related bug (bz#1319819), there is no corresponding multipath device for this partition. The two paths to the physical disk are correctly multipathed.

Actual results:

[root@megadeth pydevDAG]# multipath -c /dev/sde1
Mar 21 12:22:05 | the -c option requires a path to check

Expected results:

Something more informative, since device file '/dev/sde1' does exist.

Additional info:

This:

[root@megadeth pydevDAG]# multipath -c /dev/sde
/dev/sde is a valid multipath device path

works.
Comment 2 mulhern 2016-03-21 17:21:55 UTC 
Update:

The real root of the problem may be a confusion about whether the partition is a character or a block device.

[mulhern-journal@megadeth pydevDAG]$ file /dev/sde*
/dev/sde:  block special
/dev/sde1: character special

[mulhern-journal@megadeth pydevDAG]$ ls /sys/class/block/sde* -d
/sys/class/block/sde  /sys/class/block/sde1

[mulhern-journal@megadeth pydevDAG]$ ls /sys/block/sde* -d
/sys/block/sde

For the record, I never took any action that should have resulted in these partitions being considered character devices.
Comment 3 mulhern 2016-03-21 17:26:12 UTC 
the device's subsytem value in udev is block.
Comment 4 mulhern 2016-03-21 17:50:42 UTC 
It may be that it is libudev that is causing this behavior, see related bz#1319870.
Comment 5 mulhern 2016-03-21 18:25:22 UTC 
Relevant entry in journal:

Mon 2016-03-21 13:10:52.002159 EDT [s=07d0dd3e450e447b8176fae6f6ca2172;i=26b1e9;b
=4a123904d9fd4e27883b8169b32e4f8b;m=115a15395e6;t=52e922dcc0b7e;x=e1915c976deb100
]
    SYSLOG_FACILITY=3
    _UID=0
    _GID=0
    _CAP_EFFECTIVE=1fffffffff
    _BOOT_ID=4a123904d9fd4e27883b8169b32e4f8b
    _MACHINE_ID=c2a1a2c9555048fab5453a08361c43dc
    _HOSTNAME=megadeth.lab.bos.redhat.com
    _TRANSPORT=syslog
    _SYSTEMD_SLICE=system.slice
    SYSLOG_IDENTIFIER=multipathd
    _PID=47585
    _COMM=multipathd
    _EXE=/usr/sbin/multipathd
    _CMDLINE=/sbin/multipathd
    _SYSTEMD_CGROUP=/system.slice/multipathd.service
    _SYSTEMD_UNIT=multipathd.service
    PRIORITY=3
    MESSAGE=sde1: failed to get path uid
    _SOURCE_REALTIME_TIMESTAMP=1458580252002159

on calling:

multipathd add path /dev/sde1

> rm /dev/sde1
> partprobe /dev/sde

turns the partition device into a block device, but "multipathd add path /dev/sde1" has the same error as before.
Comment 6 mulhern 2016-03-21 18:51:00 UTC 
Should have partprobed the multipath device /dev/dm-13. After that, was able to add both paths succesfully.
Comment 7 mulhern 2016-03-21 19:06:43 UTC 
However, the sysfs holders directory for the partition is still empty.
Comment 8 mulhern 2016-03-22 12:52:14 UTC 
Comment #7 was misleading. The partition device's holders directory should be empty, and is. The multipath device's holders directory should contain a single dm device corresponding to the partition on the device and it does. The entries in the udev database for these devices seem correct.

So, the only problem that really exists, AFAICT, is that

multipath -c /dev/<partition device>

should do better than report 

the -c option requires a path to check

when the path does, in fact, exist,
even if that particular device file
has somehow mutated and appears to be
a character device file. The solution to this
problem may or may not depend on a libudev solution
(bz#1319870).
Comment 9 Ben Marzinski 2016-03-22 18:26:16 UTC 
You are correct that the issue is that the device isn't a block device. Multipath assumes that anything you pass it that is not a valid block device is an alias for a multipath device. Since aliases can't have "/" in them, there's no reason to worry about possible confusion here. I can make multipath return a more helpful error message in this case.
Comment 10 Ben Marzinski 2016-04-20 18:06:36 UTC 
Multipath now does more checking here, and will print

'<string>' is not a valid argument

if the argument is not valid.
Comment 11 Lin Li 2016-04-23 07:06:03 UTC 
Rerpoduced on device-mapper-multipath-0.4.9-85.el7
# multipath -c /dev/sde1
Apr 23 14:49:00 | the -c option requires a path to check



Verified on device-mapper-multipath-0.4.9-89.el7
# multipath -c /dev/sde1
Apr 23 08:55:32 | '/dev/sde1' is not a valid argument

# multipath -l
mpatha (360fff19abdd9552f8a36e5355226ba27) dm-0 EQLOGIC ,100E-00         
size=50G features='0' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| `- 3:0:0:0 sdb 8:16 active undef running
`-+- policy='service-time 0' prio=0 status=enabled
  `- 4:0:0:0 sdc 8:32 active undef running
[root@storageqe-84 device-mapper-multipath-0.4.9]# multipath -c /dev/sdb
/dev/sdb is a valid multipath device path
[root@storageqe-84 device-mapper-multipath-0.4.9]# multipath -c /dev/sdc
/dev/sdc is a valid multipath device path


test result: multipath will state the that path is "not a valid argument" for paths that don't belong to block devices.
Comment 14 errata-xmlrpc 2016-11-04 08:19: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/RHBA-2016-2536.html
Note You need to log in before you can comment on or make changes to this bug.