Bug 598087 - Traceback in rescue mode when adding zFCP LUN defined in CMS config file.
Summary: Traceback in rescue mode when adding zFCP LUN defined in CMS config file.
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: s390x
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: David Cantrell
QA Contact: Release Test Team
URL:
Whiteboard:
Keywords:
: 597101 (view as bug list)
Depends On:
Blocks: 582286
TreeView+ depends on / blocked
 
Reported: 2010-05-31 12:12 UTC by Jan Stodola
Modified: 2010-11-10 19:46 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-11-10 19:46:26 UTC


Attachments (Terms of Use)

Description Jan Stodola 2010-05-31 12:12:08 UTC
Description of problem:
Traceback (most recent call last):
  File "/usr/bin/anaconda", line 866, in <module>
    rescue.runRescue(anaconda, instClass)
  File "/usr/lib/anaconda/rescue.py", line 327, in runRescue
    storage.storageInitialize(anaconda)
  File "/usr/lib/anaconda/storage/__init__.py", line 103, in storageInitialize
    storage.reset()
  File "/usr/lib/anaconda/storage/__init__.py", line 360, in reset
    self.zfcp.startup()
  File "/usr/lib/anaconda/storage/zfcp.py", line 388, in startup
    self.readConfig()
  File "/usr/lib/anaconda/storage/zfcp.py", line 357, in readConfig
    self.addFCP(fields[0], fields[1], fields[2])
  File "/usr/lib/anaconda/storage/zfcp.py", line 368, in addFCP
    if d.onlineDevice():
  File "/usr/lib/anaconda/storage/zfcp.py", line 186, in onlineDevice
    'devnum': self.devnum}
ValueError: LUN 0x4020400100000000 at WWPN 0x50050763050b073d on zFCP device 0.0.a000 already configured.

Version-Release number of selected component (if applicable):
RHEL6.0-20100527.2
anaconda-13.21.48-1.el6

How reproducible:
always

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

Actual results:
traceback

Expected results:
Error dialog:
LUN 0x4020400100000000 at WWPN 0x50050763050b073d on zFCP device 0.0.a000 already configured.

Comment 1 RHEL Product and Program Management 2010-05-31 12:15:51 UTC
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
inclusion.

Comment 2 Steffen Maier 2010-06-01 21:56:33 UTC
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.)

Comment 3 Steffen Maier 2010-06-01 21:59:02 UTC
Excellent test case, Jan, BTW!

Comment 4 Steffen Maier 2010-06-01 22:10:43 UTC
> 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:

iw/filter_gui.py:FilterWindow.getScreen

Not sure about this one, since none of iscsi, fcoe, dasd pass intf here:
storage/__init__.py:Storage.__init__
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:
kickstart.py:parseKickstart

Comment 5 David Cantrell 2010-06-02 16:06:25 UTC
*** Bug 597101 has been marked as a duplicate of this bug. ***

Comment 7 Jan Stodola 2010-07-02 07:44:28 UTC
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.

Comment 8 releng-rhel@redhat.com 2010-11-10 19:46:26 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.