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?
Created attachment 838679 [details] Used kickstart-file (created from spacewalk, slightly redacted)
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?
Hmhm, I think bug #1036881 is actually a duplicate or the other way 'round
Hello! I found a workaround. At the kernel command line option, I add modprobe.blacklist=cnic,bnx2i. Then, anaconda seems to be work fine.
Same here on HP ProLiant DL380 G6. Another workaround is to unload and blacklist the bnx2i module before starting anaconda.
Same here on HP ProLiant DL585 G5. I added 'modprobe.blacklist=bnix2i' to the kernel boot command line.
Same problem on DELL poweredge T410 added "modprobe.blacklist=cnic,bnx2i" to make it work.
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.
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.