Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 617860 - loader needs to configure iBFT nics even when no network is needed otherwise
loader needs to configure iBFT nics even when no network is needed otherwise
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Ales Kozumplik
Release Test Team
:
Depends On: 581428 590580
Blocks: 590719
  Show dependency treegraph
 
Reported: 2010-07-24 09:54 EDT by Hans de Goede
Modified: 2016-02-10 04:58 EST (History)
7 users (show)

See Also:
Fixed In Version: anaconda-13.21.67-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 581428
Environment:
Last Closed: 2010-11-10 14:52:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2010-07-24 09:54:47 EDT
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2010-05-10 10:43:17 EDT ---

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

--- Additional comment from pm-rhel@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2010-05-19 09:42:57 EDT ---

Created an attachment (id=415110)
syslog

--- Additional comment from msivak@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2010-07-21 08:48:02 EDT ---

Martin,
can you answer comment #17?

--- Additional comment from msivak@redhat.com 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@redhat.com 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
Comment 1 Ales Kozumplik 2010-08-02 07:01:28 EDT
Patch posted on a-d-l, verified by hansg.
Comment 2 Hans de Goede 2010-08-03 02:49:19 EDT
I verified this using http://download.devel.redhat.com/rel-eng/RHEL6.0-20100730.5/6/Workstation/i386/os + a patched loader compiled the latest rhel6-branch anaconda code + Ales' patch.
Comment 4 Martin Sivák 2010-08-09 05:37:49 EDT
As I told Marian already, I do not agree with this behaviour.

When network is asked for, iBFT will configure it.

But when not and some iBFT is detected (on some archs iBFT is reported even when network boot was not performed) this will start networking.. and there is _no way_ to override it.

So we either document it and add override cmdline arguments, or we revert this.
Comment 6 Hans de Goede 2010-08-13 09:09:10 EDT
(In reply to comment #4)
> As I told Marian already, I do not agree with this behaviour.
> 
> When network is asked for, iBFT will configure it.
> 
> But when not and some iBFT is detected (on some archs iBFT is reported even
> when network boot was not performed) this will start networking.. and there is
> _no way_ to override it.

When there is iscsi firmware info available anaconda will automatically connect to any iscsi targets described in the firmware tables. This requires networking to be configured according to the ibft settings. The reason to do this in loader is because loader already has the code for this anyway.

If this is not done by loader (even when booting from ie a DVD), then stage2 needs to start doing this and the end result will be the same.

We had a bug against RHEL-5 exactly because of this, RHEL-5 loader did not always bring up the interface according to the ibft info and stage2 would not find the iscsi disks as the stage2 code assumes that the interface is already up.

So not bringing up the interface according to the ibft info would lead to a regression compared to RHEL-5, as this will cause stage2 to not automatically find the iscsi disks when starting from dvd.
Comment 7 Ales Kozumplik 2010-08-13 09:20:55 EDT
Guys,

a verified bug is verified.
Comment 8 releng-rhel@redhat.com 2010-11-10 14:52:06 EST
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.