-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
4.18
When a (Fibre Channel) multipath disk is discovered by the assisted-installer-agent, the wwn field is not included:
{
"bootable": true,
"by_id": "/dev/disk/by-id/wwn-0xdeadbeef",
"drive_type": "Multipath",
"has_uuid": true,
"holders": "dm-3,dm-5,dm-7",
"id": "/dev/disk/by-id/wwn-0xdeadbeef",
"installation_eligibility": {
"eligible": true,
"not_eligible_reasons": null
},
"name": "dm-2",
"path": "/dev/dm-2",
"size_bytes": 549755813888
},
Thus there is no way to match this disk with a wwn: root device hint. Since assisted does not allow installing directly to a fibre channel disk (without multipath) until 4.19 with MGMT-19631, and there is no /dev/disk/by-path/ symlink for a multipath device, this means that when there are multiple multipath disks in the system there is no way to select between them other than by size.
When ghw lists the disks, it fills in the WWN field from the ID_WWN_WITH_EXTENSION or ID_WWN udev values. It's not clear to me how udev is creating the /dev/disk/by-id/ symlink without those fields. There is a separate DM_WWN field (DM = Device Mapper), but I don't see it used in udev rules for whole disks, only for partitions. I don't have access to any hardware so it's impossible to say what the data in /run/udev/data looks like.
- blocks
-
-
- New
-
- is cloned by
-
-
- New
-
- links to
- mentioned on
[OCPBUGS-52994] Can't use WWN to select between multipath disks
OpenShift Jira Bot
added a comment - Bugs should not be moved to Verified without first providing a Release Note Type("Bug Fix" or "No Doc Update") and for type "Bug Fix" the Release Note Text must also be provided. Please populate the necessary fields before moving the Bug to Verified.
OpenShift Jira Bot
added a comment - Hi ppinjark@redhat.com ,
Bugs should not be moved to Verified without first providing a Release Note Type("Bug Fix" or "No Doc Update") and for type "Bug Fix" the Release Note Text must also be provided. Please populate the necessary fields before moving the Bug to Verified. rhn-support-shupadhy The other part of the fix is yet to merged https://github.com/openshift/assisted-installer-agent/pull/936
zabitter How far this bug should be back-ported other than 4.18?
0.16.0 is available now https://github.com/jaypipes/ghw/releases/tag/v0.16.0
No, I'll leave it to you to make a PR to upgrade ghw to 0.16.0 in assisted-installer-agent.
Zane Bitter
added a comment - - edited No, I'll leave it to you to make a PR to upgrade ghw to 0.16.0 in assisted-installer-agent. zabitter Is there a PR in assisted-installer-agent being worked to upgrade the dependecy (https://github.com/openshift/assisted-installer-agent/blame/d4298075179da48108540fc2a716717dd91fd0b1/go.mod#L15) as the PR for jaypipes is merged
Zane Bitter
added a comment - https://github.com/jaypipes/ghw/pull/409 After obtaining an sosreport, we can see that on the multipath device DM_WWN is set (with the same value as ID_WWN_WITH_VENDOR_EXTENSION from the underlying Fibre Channel disks). As expected given the symptoms, ID_WWN and ID_WWN_WITH_VENDOR_EXTENSION are not set.
So a potential fix here is to modify ghw to fall back to populating the WWN field with DM_WWN.
Zane Bitter
added a comment - - edited After obtaining an sosreport, we can see that on the multipath device DM_WWN is set (with the same value as ID_WWN_WITH_VENDOR_EXTENSION from the underlying Fibre Channel disks). As expected given the symptoms, ID_WWN and ID_WWN_WITH_VENDOR_EXTENSION are not set.
So a potential fix here is to modify ghw to fall back to populating the WWN field with DM_WWN . 
CPaaS Service Account mentioned this issue in merge request !910 of rh-ecosystem-edge / assisted-installer / assisted installer projects on branch rhai-1.0-rhel-8_upstream_47a1cee7f064577d39be6f9e1fcda3aa: