Major Description of problem:
On OpenShift nodes which have been configured as a day 2 operation to use a multipath device as the primary disk, kdump is not running and collecting data when configured. A workaround was suggested to disable friendly names for the multipath device, however when this was applied via a machineconfiguration, and a kernel panic is manually generated to test the changes, the CoreOS Propagate Multipath Configuration service fails with the error: `coreos-propagate-multipath-conf[1004]: cp: cannot create regular file '/sysroot/etc/': Not a directory` and no vmcores are generated in the configured location.
Version-Release number of selected component (if applicable):
The issue was observed on multiple versions of OpenShift 4.14 but probably exists in others
How reproducible:
The customer can reproduce this bug with ease on their OCP 4.14 clusters with RHCOS nodes using multipath for their primary storage device. Replication would require a cluster with a SAN and multipath device configured as the root filesystem
Steps to Reproduce:
1. Install OCP 4.14
2. Configure nodes to use multipath for the primary storage off of a QLogic FC card
3. Enable kdump
4. Adjust the multipath configuration to disable friendly names as a workaround to the kdump issue
5. Trigger a kdump
Actual results:
Errors are observed indicating the `multipath.conf` is not updated and the kdump fails to record any data to the target output location
Expected results:
Expected outcome is that the `multipath.conf` is applied when nodes have a kdump triggered, and vmcores are written to the target output location
Additional info: