+++ This bug was initially created as a clone of Bug #581428 +++

Hi,

When doing a harddrive (usb-stick) install on a machine with a NIC with
iscsi firmware, which contains valid iBFT info, loader should configure
the NIC with the settings from iBFT like it does in RHEL-5

Currently it does not do this, which subsequently causes the automatic
onlining of the iscsi disks in stage2 from the iBFT info to fail, as the network
is not up.

Related:
I've also noticed that when doing a network install, on a machine with
a NIC with iBFT info, that loader still asks which NIC to use (even though
the iBFT NIC is the only one with a cable plugged in), and then asks
for IP address, etc. (which can be read from the iBFt info). Let me know if
you want a separate bug for this.

Regards,

Hans

--- Additional comment from hdegoede on 2010-04-12 05:46:28 EDT ---

Created an attachment (id=405918)
logs from install (till stage2) with ksdevice=ibft ip=ibft

--- Additional comment from msivak on 2010-04-12 07:17:56 EDT ---

What I see in the logs is:

09:47:15,657 INFO    : iBFT is not present

it means, that iBFT related API functions return errors, so this doesn't look like anaconda problem per se, it could be API change, wrong library version or bug somewhere else...

--- Additional comment from hdegoede on 2010-04-12 07:40:19 EDT ---

(In reply to comment #2)
> What I see in the logs is:
> 
> 09:47:15,657 INFO    : iBFT is not present
> 
> it means, that iBFT related API functions return errors, so this doesn't look
> like anaconda problem per se, it could be API change, wrong library version or
> bug somewhere else...    

Well later on in stage2 the python code (which uses the same libiscsi functions through python bindings) does find the iBFT code. So maybe there is a "modprobe ibft" missing in loader or done too late ? Or is the Fedora / RHEL-6 code still using the old libfwparam library?

--- Additional comment from msivak on 2010-04-13 03:51:55 EDT ---

Syslog mentions the following line early, right next to other device detected lines:

<6>FDC 0 is a post-1991 82077
<6>BIOS EDD facility v0.16 2004-Jun-25, 6 devices found
<6>input: PC Speaker as /devices/platform/pcspkr/input/input5
<6>iBFT detected at 0xcfb50.

The equivalent anaconda code is:

mlLoadModuleSet("floppy:edd:pcspkr:iscsi_ibft");

So the iBFT should be initialized and working when I try to access it.

But loader then reports:

09:47:15,657 INFO    : iBFT is not present

from the code which calls:

char *devmacaddr = iface_mac2str(loaderData->netDev);
if(!devmacaddr || !ibft_present()){
  iface->ipv4method = IPV4_DHCP_METHOD;
  logMessage(INFO, "iBFT is not present");
}

So the next check I'm going to make is whether iface_mac2str is working.

--- Additional comment from hdegoede on 2010-04-13 05:46:50 EDT ---

Created an attachment (id=406191)
logs from install (till stage2) with ksdevice=link ip=ibft

--- Additional comment from msivak on 2010-05-07 10:36:56 EDT ---

Ok our current findings with somewhat debug enabled loader:

14:20:32,521 00091 DEBUG   : iBFT initialized with present value 0

this log was from this following code snippet:

int ibft_init(void)
{
  int ret;

  memset(&ibft_context, 0, sizeof(ibft_context));

  ret = libiscsi_get_firmware_network_config(&ibft_context);

  /* ret == 0 -> OK */
  ibft_ispresent = !ret;
  ibft_initialized = 1;

  logMessage(DEBUGLVL, "iBFT initialized with present value %d", ibft_ispresent);

  return ibft_initialized;
}

What that means is that libiscsi_get_firmware_network_config returned nonzero value and that (according to the docs used to) equal "no iBFT is installed".

--- Additional comment from msivak on 2010-05-10 10:43:17 EDT ---

The fix will be present in anaconda-13.21.38-1.

--- Additional comment from pm-rhel on 2010-05-10 10:43:45 EDT ---

Since this bug is proposed for the current release and its status has
changed to MODIFIED, the devel_ack flag has been set to +.

--- Additional comment from releng-rhel on 2010-05-13 07:54:57 EDT ---

Fixed in 'anaconda-13.21.38-1'. 'anaconda-13.21.39-1.el6' included in compose 'RHEL6.0-20100512.0'.
Moving to ON_QA.

--- Additional comment from mganisin on 2010-05-19 07:55:40 EDT ---

Created an attachment (id=415093)
anaconda.log - testing ibft in kvm

Hello, I tried to verify this issue in KVM, however it failed. ibft is available "stage2" is trying to connect to configured target, but the network is down.

--- Additional comment from hdegoede on 2010-05-19 08:09:58 EDT ---

(In reply to comment #10)
> Created an attachment (id=415093) [details]
> anaconda.log - testing ibft in kvm
> 
> Hello, I tried to verify this issue in KVM, however it failed. ibft is
> available "stage2" is trying to connect to configured target, but the network
> is down.    

That is to be expected, this also needs bug 590581 fixed, please retest once the fix for that is available in the nightlies.

--- Additional comment from mganisin on 2010-05-19 09:42:33 EDT ---

Created an attachment (id=415109)
anaconda.log - testing ibft in kvm, round 2

I tried to force network usage by ks= set on commandline. stage1 started network without question (dhcp request sent), log said "read of iBFT failed". stage2 connected to target based on iBFT record.

--- Additional comment from mganisin on 2010-05-19 09:42:57 EDT ---

Created an attachment (id=415110)
syslog

--- Additional comment from msivak on 2010-05-19 09:54:06 EDT ---

That is exactly what should have happened. Stage1 ibft stuff requires the bug Hans mentioned to be fixed first.

--- Additional comment from borgan on 2010-05-21 14:01:30 EDT ---

To the QE engineer:

This bug should be in a state where we can verify it is resolved for pbeta2, or ping the customer/reporter and verify they are happy with the resolution ... Please verify this bug so that we can know the pbeta2 milestone will have this issue resolved.

Thanks and Regards,

Brock

--- Additional comment from borgan on 2010-06-06 18:14:34 EDT ---


For the QE engineer,

This issue is in ON_QA status, and presumably fixed for RHEL6 beta2 ... in order to address the issue in the highest quality manner, it is important for the individual QE engineer to VERIFY this issue in the best manner possible.

If the issue is directly testable and verifiable, please re-test and verify the bug is properly addressed ... if the issue requires partner or other 3rd party acceptance, please check with them to see if they've been able to verify the fix to their satisfaction ...

We are looking to have this issue (and others) addressed in time for the June 21 QE acceptance for pbeta2 ... please give verification of this issue a high priority in your testing ...

Thanks and Best Regards,

Brock

--- Additional comment from mganisin on 2010-06-17 07:37:11 EDT ---

I tested this with RHEL6.0-20100615.0 (anaconda 13.21.50), it is working as expected, network is configured in accordance to  iBFT record.

However this happens only in case of required network during stage1 (vnc, remote installation source, etc.). In other case network is not started and iSCSI target(s) is not available (even if stage2 is trying to connect to it, obviously). I suppose it is not best behavior, is it?

----
Just a note to my configuration. I am using just one NIC (it doesn't seem to be most common configuration for iSCSI in real life), I have no idea, what will happen if dedicated card(s) will be used for iSCSI.

--- Additional comment from atodorov on 2010-07-21 08:48:02 EDT ---

Martin,
can you answer comment #17?

--- Additional comment from msivak on 2010-07-21 08:58:09 EDT ---

We are configuring the NICs only when we are also asked to enable networking. When in offline mode we are not doing it.

Please create another bug if you want that, it should be easy to fix, I only have to know if starting the network without user knowing it at all is wise idea.

--- Additional comment from hdegoede on 2010-07-24 09:51:58 EDT ---

Hi,

(In reply to comment #19)
> We are configuring the NICs only when we are also asked to enable networking.
> When in offline mode we are not doing it.
>

When there is ibft info we should always configure the relevant NIC according to that info *as we are doing in RHEL-5*, otherwise activating of the iscsi targets in the iBFT info will fail in stage2. I'll clone this bug to track this.

Regards,

Hans