Bug 1044759

Summary: anaconda segfaults at start of kickstart installation at libiscsi.so on DELL R815
Product: [Fedora] Fedora Reporter: Jonathan Hoser <jonathan>
Component: iscsi-initiator-utilsAssignee: Chris Leech <cleech>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 20CC: agrover, amitpundir, Bert.Deknuydt, cjs, cleech, g.kaviyarasu, hdegoede, jonathan, jonathan, pasik, stefan, vanmeeuwen+fedora, watanabe.yu
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-29 13:37:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screencapture of the tty-4 of the anaconda-tui after segfault happens
none
Used kickstart-file (created from spacewalk, slightly redacted) none

Description Jonathan Hoser 2013-12-18 22:52:15 UTC
Created attachment 838678 [details]
Screencapture of the tty-4 of the anaconda-tui after segfault happens

Description of problem:
Doing a spacewalk-driven kickstart of the new Fedora20 on my Dell R815 servers
provokes instant segfaults in anaconda, as soon as the tui loads.

It will only display "Pane is dead" , tty3 (log) displays only a login-shell,
tty4 (storage) displays the segfault.
True screenshot attached; Short description:
Anaconda is logging the kernel-loading of the Broadcom iscsi-offload drivers (bnx2i) for the onboard NICs,
and after the last (fourth) anaconda segfaults:
anaconda[[pid]]: segfault at 0 ip 00007f792d994490 sp 00007fff0aa68b20 error 4 in libiscsi.so.0[7f792d990000+44000] 

The kickstart is not using iscsi for drive-partitioning or anything,
its just the most rudimentary kickstart that Spacewalk is pretty much able to create.

Version-Release number of selected component (if applicable):
fedora20-release (DVD iso, todays repo sync)



How reproducible:
kickstart F20 on a R815 (!?),
after the initial crash, reruning anaconda on the cli
(ie. 'anaconda -h' will also segfault
# anaconda -h
Starting installer, one moment...
Segmentation fault
#
tought the addresses given in the segfault-logs do differ:
anaconda[2101]: segfault at 0 ip 00007fcca758c490 sp 00007fff7bbb1c0 error 4 in libiscsi.so.0[7fcca7588000+44000]



Steps to Reproduce:
1. Create F20 kickstart in Spacewalk using current ISO-Distro and current package sync
2. Execute the kickstart (attached, slightly redacted) on an Dell PE R815
3. 

Actual results:
See it crash.

Expected results:
Running installation!?


Additional info:
Is there a way to tell anaconda to not even think about thinking about the iscsi-interfaces? Trying to skip that step?

Comment 1 Jonathan Hoser 2013-12-18 22:56:40 UTC
Created attachment 838679 [details]
Used kickstart-file (created from spacewalk, slightly redacted)

Comment 2 Yu Watanabe 2013-12-20 05:51:19 UTC
I have same problem on HP Proliant ML350 G6.

I use iPXE for network install without any iscsi parameters.
However, the installer kernel loads iscsi driver and initialize it.
Then, anaconda crashes.

I tried to install fedora20 both with and without kickstart file.
But the situations seem to be equivalent.

Here is the tail of system log (given by journalctl):
--------------------------------
systemd[1]: Startup finished in 4.515s (kernel) + 6min 39.118s (initrd) + 3.374s (userspace) = 6min 47.009s.
kernel: cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.16 (Dec 05, 2012)
kernel: bnx2 0000:02:00.0 localnet: Added CNIC device
kernel: bnx2 0000:02:00.1 globalnet: Added CNIC device
kernel: Broadcom NetXtreme II iSCSI Driver bnx2i v2.7.2.2 (Apr 25, 2012)
kernel: iscsi: registered transport (bnx2i)
kernel: scsi3 : Broadcom Offload iSCSI Initiator
kernel: bnx2i [02:00.01]: ISCSI_INIT passed
kernel: scsi4 : Broadcom Offload iSCSI Initiator
kernel: bnx2i [02:00.00]: ISCSI_INIT passed
kernel: anaconda[1411]: segfault at 0 ip 00007f2592b38490 sp 00007fff72dffe10 error 4 in libiscsi.so.0[7f2592b34000+44000]
---------------------------------

Are there any workaround to disable iscsi driver?

Comment 3 Jonathan Hoser 2013-12-20 07:36:15 UTC
Hmhm, I think bug #1036881 is actually a duplicate
or the other way 'round

Comment 4 Yu Watanabe 2013-12-25 04:51:14 UTC
Hello!

I found a workaround.
At the kernel command line option, I add modprobe.blacklist=cnic,bnx2i.
Then, anaconda seems to be work fine.

Comment 5 Stefan Agner 2014-02-04 13:07:14 UTC
Same here on HP ProLiant DL380 G6. Another workaround is to unload and blacklist the bnx2i module before starting anaconda.

Comment 6 Bert DeKnuydt 2014-02-07 15:43:11 UTC
Same here on HP ProLiant DL585 G5.

I added 'modprobe.blacklist=bnix2i' to the kernel boot command line.

Comment 7 Amit Pundir 2014-03-06 10:16:54 UTC
Same problem on DELL poweredge T410

added "modprobe.blacklist=cnic,bnx2i" to make it work.

Comment 8 Fedora End Of Life 2015-05-29 10:02:54 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 9 Fedora End Of Life 2015-06-29 13:37:01 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.