Description of problem:
Traceback (most recent call last):
File "/usr/bin/anaconda", line 866, in <module>
File "/usr/lib/anaconda/rescue.py", line 327, in runRescue
File "/usr/lib/anaconda/storage/__init__.py", line 103, in storageInitialize
File "/usr/lib/anaconda/storage/__init__.py", line 360, in reset
File "/usr/lib/anaconda/storage/zfcp.py", line 388, in startup
File "/usr/lib/anaconda/storage/zfcp.py", line 357, in readConfig
self.addFCP(fields, fields, fields)
File "/usr/lib/anaconda/storage/zfcp.py", line 368, in addFCP
File "/usr/lib/anaconda/storage/zfcp.py", line 186, in onlineDevice
ValueError: LUN 0x4020400100000000 at WWPN 0x50050763050b073d on zFCP device 0.0.a000 already configured.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. edit CMS config file, define zFCP LUN, for example:
FCP_1="0.0.A000 0x50050763050B073D 0x4020400100000000"
2. start rescue mode
3. use Advanced button to add the same zFCP LUN defined in CMS config file in step 1
4. select Continue
LUN 0x4020400100000000 at WWPN 0x50050763050b073d on zFCP device 0.0.a000 already configured.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Every caller (direct or indirect) of ZFCP.addFCP in storage/zfcp.py must catch ValueError exceptions and either display an error dialog box (if there is a UI) or log the error (otherwise).
Apparently this rule even applies to zfcp.py itself. :-)
ZFCP.readConfig calls addFCP without catching ValueError.
Maybe we should pass self.anaconda.intf to zfcp.startup as we do with dasd, iscsi, and fcoe. Then ZFCP.readConfig can use it to decide between displaying an error dialog box or logging a caught ValueError.
I suppose we have never seen this case before, since rescue now seems to perform the add drive dialog _before_ initializing storage, whereas anaconda does it the other way round and the user would have gotten an error dialog on trying to add the same lun with the add drive dialog (iw/advanced_storage.py, textw/add_drive_text.py).
(Besides addFCP, the same goes for most methods of ZFCPDevice although these are not meant to be public interfaces outside of zfcp.py.)
Excellent test case, Jan, BTW!
> Maybe we should pass self.anaconda.intf to zfcp.startup as we do with dasd,
> iscsi, and fcoe. Then ZFCP.readConfig can use it to decide between displaying
> an error dialog box or logging a caught ValueError.
Bug 597101 (which seems a dup of this one here) reminded me of the fact that there might be multiple callers of ZFCP.startup that would have to be modified to pass in anaconda.intf:
Not sure about this one, since none of iscsi, fcoe, dasd pass intf here:
I guess it's a matter of we want users to get dialogs or have them dig in /tmp/anaconda.log if something went wrong which they might not even notice if we just log.
The following callers don't seem to have intf anyway so they don't need any change:
*** Bug 597101 has been marked as a duplicate of this bug. ***
There is no traceback when adding the same zFCP LUN that was defined in CMS config file, user see error message:
┌─────────────────────┤ Error ├─────────────────────┐
│ LUN 0x4020400100000000 at WWPN 0x500507630503c73d │
│ on zFCP device 0.0.a000 already configured. │
│ ┌────┐ │
│ │ OK │ │
│ └────┘ │
Tested on build RHEL6.0-20100701.0 with anaconda-13.21.56-1.el6.
Moving to VERIFIED.
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.