Description of problem:
Anaconda will complain if using
"clearpart --drives disk/by-id/dm-uuid-mpath-360a98000572d574a4e6f63706772594b --all --initlabel"
Specified nonexistent disk disk/by-id/dm-uuid-mpath-360a98000572d574a4e6f63706772594b in clearpart command
I also tried this line but failed with same error.
clearpart --drives /dev/disk/by-id/dm-uuid-mpath-<WWID> --all --initlabel
Version-Release number of selected component (if applicable):
Both RHEL6.3-20120426.2 and RHEL6.2 GA are same error.
Steps to Reproduce:
1. Use "clearpart --drives disk/by-id/dm-uuid-mpath-<WWID> --all --initlabel"
to install OS.
It might be hard for me to get anaconda log for you as "ondisk" option of beaker cannot work with "manual" option.
Let me know if you can only draft out patch with logs.
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Do those files even exist in /dev/? Also, can you somehow grab /tmp/storage.log?
Yes. That file exist in /dev/ folder and it's recommended way for mpath devices in docs.redhat.com.
I removed the console option and get into shell via ALT+F2.
mpath is not assemble yet when anaconda panic.
fix this problem.
So this bug goes to two directions:
1. Please confirm whether /dev/disk/by-id/scsi-<WWID> works for all kickstart option, if so, update documents and request use stick on this.
2. Start multipath before any storage checking and make sure both dm-uuid-mpath and scsi works well.
Which one is acceptable for you?
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release. Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.
This bug will necessitate updates to the Installation Guide, and each of the solutions proposed in Comment 4 will have a different impact. Have you determined which approach you will take?
If the first is taken, I'll state that the /dev/disk/by-id/scsi-<WWID> format works for both LVM and non-LVM multipath devices.
If the second, I'll remove the following: "Multipath devices that use LVM are not assembled until after anaconda has parsed the kickstart file. Therefore, you cannot specify these devices in the format dm-uuid-mpath."
Regardless, is the path /disk/by-id/scsi|dm-uuid-mpath-<WWID> erroneous anyway? Should it not be /dev/disk/by-id/scsi|dm-uuid-mpath-<WWID> ?
[See 'clearpart' at http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html]
Is all this correct?
Jack - for specifying disks in kickstart commands, either the shorter form of "disk/by-id/XXXX" or the longer form of "/dev/disk/by-id/XXXX" ought to work. I've not tested whether or not "/disk/..." would work correctly.
For this bug, I am really hesitant to do anything involving starting multipath in a different place for kickstart. That tends to have some pretty unforseen consequences. Personally, I think we should just modify the documentation to state that the /dev/disk/by-id/scsi-<WWID> format is preferable at least when multipath is involved.
Reassigning to doc-Installation_Guide based on comment #8. The documentation needs to be updated to indicate the preferred way to specify devices in kickstart files.
This bug has been verified and implemented for 6.4, so I am changing the status to CLOSED CURRENTRELEASE.