0

The system is Fedora 23. This occurred after a system upgrade. The issue is duplicate entries in /dev/mapper. As seen by /dev/mapper each partition is represented twice. How can the device based names be removed?

ls /dev/mapper shows:

fedora-home
fedora-root21
fedora-secure
fedora-var
SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142
SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142p1
SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142p2
SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142p3

lsblk shows:

sda                                               8:0    0 238.5G  0 disk  
└─SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142     253:0    0 238.5G  0 mpat
  ├─SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142p1 253:1    0   200M  0 part  
  ├─SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142p2 253:2    0   500M  0 part           
  └─SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142p3 253:3    0 237.8G  0 part
dan sawyer
  • 141
  • 2
  • 11
  • Has this machine been restarted after the upgrades? Also, what did your upgrades affect? If it updated libdevmapper, it may be prudent to reboot if you haven't already. – Spooler Oct 16 '16 at 23:37

1 Answers1

0

While those entries are all in /dev/mapper, only the named ones are from LVM. The others (by drive ID) are from a single device that is having a multipathing abstraction created from it.

Problem:

Your drive was added to the WWID list, as established via the /etc/multipath/wwids file (as printed here):

# Multipath wwids, Version : 1.0 # NOTE: This file is automatically maintained by multipath and multipathd. 
# You should not need to edit this file in normal circumstances.
# # Valid WWIDs: /SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142/ /Samsung_SSD_840_EVO_1TB_mSATA_S1KRNEAFB01255N/ /HGST_HTS721010A9E630_JG40006PG3DADC/

Solution:

Your drive was added to the WWID list, as you've printed there. You should be able to remove it from that file manually to solve this, despite the warnings. Alternatively (and perhaps in addition to), you can just disable multipathd, since you're not using it anyways. That can be accomplished by issuing:

# systemctl disable multipathd.service && systemctl stop multipathd.service

Spooler
  • 7,016
  • 16
  • 29
  • It is the root / boot device. Yes, this occurs after a re-boot. The duplication is occurring with the LVM partition. The boot partition is not affected. How can the multipathing abstraction be removed? This is an ssd device and multipath fails to recognize the LVM partition. Where is the Multipath abstraction saved between boots? – dan sawyer Oct 17 '16 at 00:02
  • Your multipathing abstractions are defined in `/etc/multipath.conf`, as well as `/etc/multipath/*`. Given the output of that multipath.conf file, in addition to any multipathing abstractions defined in the /etc/multipath/ directory, we may see what is causing this device to be addressed as a multipathing device. – Spooler Oct 17 '16 at 00:52
  • Multipath.conf is: #Use Defaults – dan sawyer Oct 17 '16 at 02:19
  • Multipath directory has one file: wwids. Its content is: # Multipath wwids, Version : 1.0 # NOTE: This file is automatically maintained by multipath and multipathd. # You should not need to edit this file in normal circumstances. # # Valid WWIDs: /SAMSUNG_MZMTE256HMHP-000SO_S1F8NYAF201142/ /Samsung_SSD_840_EVO_1TB_mSATA_S1KRNEAFB01255N/ /HGST_HTS721010A9E630_JG40006PG3DADC/ It is the first one that is of interest. – dan sawyer Oct 17 '16 at 02:22
  • Your drive was added to the WWID list, as you've printed there. You should be able to remove it from that file manually to solve this, despite the warnings. Alternatively (and perhaps in addition to), you can just disable multipathd, since you're not using it anyways. That can be accomplished by issuing `# systemctl disable multipathd.service && systemctl stop multipathd.service` – Spooler Oct 17 '16 at 02:35
  • There are entries for the SANSUNG devices in /etc/lvm/cache/.cache. Can those be edited out? – dan sawyer Oct 17 '16 at 04:28
  • Those are for LVM. LVM, while it too uses the device mapper, has nothing to do with multipathing. Leave those entries. – Spooler Oct 17 '16 at 05:36