Bug 1056019

Created attachment 853184 [details]
File: anaconda-tb

Created attachment 853185 [details]
File: anaconda.log

Created attachment 853186 [details]
File: environ

Created attachment 853187 [details]
File: ks.cfg

Created attachment 853188 [details]
File: lsblk_output

Created attachment 853189 [details]
File: nmcli_dev_list

Created attachment 853190 [details]
File: os_info

Created attachment 853191 [details]
File: program.log

Created attachment 853192 [details]
File: storage.log

Created attachment 853193 [details]
File: syslog

Created attachment 853194 [details]
File: ifcfg.log

Created attachment 853195 [details]
File: packaging.log

Seems to be caused by a change in

commit 6977f898cba63d0f215ca5e2be7c96bd451e8fc1
Author: Samantha N. Bueno <sbueno+anaconda>
Date:   Tue Jan 14 19:44:33 2014 -0500

    Fix up the z Panel in advanced storage. (#1024949)
    
    This just adds functionality to the skeleton z Panel that was created
    ages ago. Once z-specific devices are added (for now, just zFCP), they
    should show up in the filter window. Users should be able to filter
    the list by searching for the device id (CCW), LUN, or WWPN.
    
    Once a device is selected from here, it should show up in the main
    storage spoke under specialized devices.
    
    Resolves: rhbz#1024949

for FCoE devices.

Passing to Samantha for comments.

Patch posted for review.

Patch pushed, commit a858810.

Another user experienced a similar problem:

I clicked on add FCOE disk, I selected the interface (em3) to scan for fcoe disk.  I took about a minute, istead of returning the disk, it crashed with this error.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=RHEL-7.0\x20Server.x86_64  BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.10.0-71.el7.x86_64
package:        anaconda-19.31.48-1
product:        Red Hat Enterprise Linux
reason:         AttributeError: 'FcoeDiskDevice' object has no attribute 'wwid'
release:        Red Hat Enterprise Linux Client release 7.0 Beta (Maipo)
version:        7.0

Another user experienced a similar problem:

1) During FC Boot installation, Click on Add Disk
2)  Click on Add FCOE SAN Disk
3) Select interface from pull down list (em3) and click on add FCOE disk
4) I see this crash message

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=RHEL-7.0\x20Server.x86_64 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.10.0-71.el7.x86_64
package:        anaconda-19.31.48-1
product:        Red Hat Enterprise Linux
reason:         AttributeError: 'FcoeDiskDevice' object has no attribute 'wwid'
release:        Red Hat Enterprise Linux Client release 7.0 Beta (Maipo)
version:        7.0

If it's not too much trouble, would it be possible to create an updates.img for SS3 with the fix?  We're seeing this issue on all of our setups with the SS3 build and it's preventing us from installing the OS onto the FCoE LUN.  Thanks.

(In reply to edwardn from comment #20)
> If it's not too much trouble, would it be possible to create an updates.img
> for SS3 with the fix?  We're seeing this issue on all of our setups with the
> SS3 build and it's preventing us from installing the OS onto the FCoE LUN. 
> Thanks.

Are you sure it's not snapshot 02 (last week's) you're seeing this with? We did a new build of anaconda before snapshot 03 was generated, so it should be included. The corrected version should be anaconda-19.31.51-1 (the anaconda version can be checked at the top of /tmp/anaconda.log).

Apologies if I'm mistaken -- I'm just not sure when the snapshots are distributed is all. I am more than happy to provide an updates.img with the fix if for some reason it did not make it into snapshot three though.

Created attachment 854472 [details]
updates.img w/fix

Ok, I see now that snapshot three is using anaconda-19.31.48-1. I am attaching an updates.img based on this version with the fix included. Make sure to pass the following boot parameter so it gets picked up and applied:

inst.updates=http://url.to/updates.img

(The updates.img is also available at http://sbueno.fedorapeople.org/updates/1056019.img)

Thanks.  The problem is no longer seen with the 1056019.img patch.

Broadcom hasn't seen this problem with the past few snapshots.  We consider this issue fixed.

storage-qe did not see the issue on the snapshot 6 tree. move it to verified.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.