Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Feature: Change multipath's default blacklist from blacklisting specific device types, to blacklisting all devices types except the ones that multipath supports (scsi, dasd, and nvme). Also users are now able to write inverse matching regexes in the blacklist and blacklist_exceptions sections of multipath.conf
Reason: Previously, multipath's default blacklist specifically listed all the device types that were blacklisted. This cause a problem whenever users encountered a new device type. Multipath would attempt to use these devices, and they would need to be manually blacklisted until the default blacklist could be updated.
Result: Multipath will now only accept the devices is was designed to support by default.
I actually did more work then was necessary to fix this, so that we don't have to keep dealing with this class of bugs going forwards. The multipath blacklist and blacklist exceptions sections now treat their attribute values slightly differently. If a value starts with an exclamation point, "!", it will invert the matching of the rest of the regex. So for instance
blacklist {
devnode "!^sd[a-z]"
}
will now blacklist all devices whose device name doesn't start with "sd[a-z]". The exclamation point can be escaped, "\!", to match a literal exclamation point at the start of the regex. This change will not cause any issues for existing values since, because of a bug, multipath previously didn't recognize quoted strings starting with an exclamation point.
With this new capability, the default blacklist has been changed to:
devnode "!^(sd[a-z]|dasd[a-z]|nvme[0-9])"
which only allows scsi, dasd, and nvme devices as multipath paths. Other device types could be added using the blacklist_exceptions section. This change also should not cause any problems since these are the only device types that multipath currently has code to support, and the multipath udev rules already have the following line
KERNEL!="sd*|dasd*|nvme*", GOTO="end_mpath"
So other device types currently will not be correctly set up by udev.
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 (device-mapper-multipath bug fix and enhancement update), 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://access.redhat.com/errata/RHEA-2020:4540
Description of problem: multipath tried to claim paths from Oracle AFD devices ( This Oracle ASM filter driver is the replacement for the legacy asmlib kernel driver) [root@pos-s-oradb01 ~]# multipathd show paths hcil dev dev_t pri dm_st chk_st dev_st next_check 0:0:0:1 sda 8:0 1 active ready running XX........ 5/20 0:0:0:2 sdb 8:16 1 active ready running XX........ 4/20 0:0:0:3 sdc 8:32 1 active ready running XX........ 4/20 0:0:0:4 sdm 8:192 1 active ready running XX........ 4/20 0:0:0:5 sdq 65:0 1 active ready running XX........ 4/20 0:0:0:6 sdu 65:64 1 active ready running XX........ 4/20 0:0:0:7 sdy 65:128 1 active ready running XX........ 4/20 0:0:1:1 sdd 8:48 1 active ready running XX........ 4/20 0:0:1:2 sde 8:64 1 active ready running XX........ 4/20 0:0:1:3 sdf 8:80 1 active ready running XX........ 4/20 0:0:1:4 sdn 8:208 1 active ready running XX........ 4/20 0:0:1:5 sdr 65:16 1 active ready running XX........ 4/20 0:0:1:6 sdv 65:80 1 active ready running XX........ 4/20 0:0:1:7 sdz 65:144 1 active ready running XX........ 4/20 1:0:0:1 sdg 8:96 1 active ready running XX........ 4/20 1:0:0:2 sdh 8:112 1 active ready running XX........ 4/20 1:0:0:3 sdi 8:128 1 active ready running XX........ 4/20 1:0:0:4 sdo 8:224 1 active ready running XX........ 4/20 1:0:0:5 sds 65:32 1 active ready running XX........ 4/20 1:0:0:6 sdw 65:96 1 active ready running XX........ 4/20 1:0:0:7 sdaa 65:160 1 active ready running XX........ 4/20 1:0:1:1 sdj 8:144 1 active ready running XX........ 5/20 1:0:1:2 sdk 8:160 1 active ready running XX........ 4/20 1:0:1:3 sdl 8:176 1 active ready running XX........ 4/20 1:0:1:4 sdp 8:240 1 active ready running XX........ 4/20 1:0:1:5 sdt 65:48 1 active ready running XX........ 4/20 1:0:1:6 sdx 65:112 1 active ready running XX........ 4/20 1:0:1:7 sdab 65:176 1 active ready running XX........ 4/20 #:#:#:# asm/.asm_ctl_spec 251:0 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vbg0 251:10 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vbg1 251:11 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vbg2 251:12 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vbg3 251:13 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vbg4 251:14 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vbg5 251:15 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vbg6 251:16 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vbg7 251:17 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vbg8 251:18 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vdbg 251:1 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio0 251:20 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio1 251:21 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio10 251:30 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio11 251:31 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio12 251:32 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio13 251:33 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio14 251:34 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio15 251:35 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio16 251:36 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio17 251:37 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio18 251:38 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio19 251:39 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio2 251:22 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio20 251:40 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio21 251:41 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio22 251:42 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio23 251:43 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio24 251:44 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio25 251:45 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio26 251:46 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio27 251:47 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio28 251:48 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio29 251:49 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio3 251:23 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio30 251:50 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio31 251:51 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio4 251:24 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio5 251:25 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio6 251:26 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio7 251:27 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio8 251:28 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vio9 251:29 -1 undef undef unknown orphan #:#:#:# asm/.asm_ctl_vmb 251:2 -1 undef undef unknown orphan #:#:#:# oracleafd/admin 252:0 -1 undef undef unknown orphan #:#:#:# ofsctl 250:0 -1 undef undef unknown orphan Changing the ruleset to this, and restarting multipathd removed these devices as expected: [root@pos-s-oradb01 ~]# cat /etc/multipath.conf defaults { find_multipaths yes user_friendly_names yes } blacklist { devnode "^asm*|oracleafd*|ofsctl*" <-- } So the default blacklist in multipath should include these devices. Additional info: Since the C regex code doesn't allow negative lookahead, we cannot have a blacklist filter that blacklists anything that is *NOT* scsi/nvme/dasd. the blacklist in the default multipath.conf in the multipath repo seems to be # devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" # devnode "^hd[a-z]" Is the required patch to change the multipath.conf in device-mapper-multipath/multipath-tools-0.8.3 like so? # devnode "^(asm|oracleafd|ofsctl|ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"