Problem Overview
The issue stemmed from a conflict with the multipath device /dev/mapper/mpathch. The kernel assigned identical paths (e.g., sdmg, sdfl, sdmd, sdft) to a new LUN, resulting in duplicate device mappings and access conflicts. This caused errors during device scans and prevented the cleanup of the mpathch device.
Errors Observed
During
pvscan, errors were encountered when reading the device:These errors indicated that the device could not be properly accessed or read by the system, likely due to the path conflicts.
dmsetup info -crevealed that:- The device 
/dev/mapper/mpathchwas still active with paths assigned. - The logical volume 
vgexport-lvexportwas in use, blocking further actions onmpathch. 
- The device 
 
Resolution Steps
Checked Active Devices:
- Used 
dmsetup info -cto identify active devices and locatempathchand associated logical volumes. 
- Used 
 Removed the Blocking Logical Volume:
- Identified and removed the logical volume 
vgexport-lvexport, which was preventing the unmapping ofmpathch. 
- Identified and removed the logical volume 
 Forcefully Removed the Multipath Device:
- Used 
dmsetup remove -fto forcibly delete thempathchdevice from the device-mapper layer. 
- Used 
 
Validation
- Verified that 
mpathchand its associated paths were no longer present using: - Confirmed the system was no longer referencing the conflicting LUN and informed the storage team for reassignment or cleanup.
 
- After the reload, the new LUN became visible in the system.
 
Conclusion
The problem was caused by duplicate kernel path assignments for a new LUN, which conflicted with existing device mappings and caused read errors during device scans. By removing the blocking logical volume and forcefully unmapping the multipath device, the issue was resolved, and the system was returned to a clean state.