Bug 1317459 - Connection lost to iSCSI target
Connection lost to iSCSI target
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dracut (Show other bugs)
7.1
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Lukáš Nykrýn
Release Test Team
SA233563135
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-14 06:08 EDT by Josef Möllers
Modified: 2017-07-10 11:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of journactl in case of error (353.14 KB, text/x-vhdl)
2016-03-14 06:08 EDT, Josef Möllers
no flags Details

  None (edit)
Description Josef Möllers 2016-03-14 06:08:12 EDT
Created attachment 1136107 [details]
Output of journactl in case of error

Description of problem:
After having installed RHEL7.1 on an iSCSI target using a software initiator (i.e. no offloading of iSCSI functionality to the NIC), a reboot fails.

Version-Release number of selected component (if applicable):
dracut-033-240.el7

How reproducible:
Often, not always, ~once in 3 reboots.

Steps to Reproduce:
1.configure the iSCSI boot to obtain the network configuration to use DHCP
2.Install RHEL7.1 on an iSCSI target using a software initiator
3.reboot

Actual results:
iscsistart: cannot make a connection to xxx.xxx.xxx.xxx:3260 (-1,101)

Expected results:
System boots

Additional info:
This only happens if
1) the initiator network configuration for iSCSI boot was obtained using DHCP (i.e. when "/sys/firmware/ibft/ethernet0/dhcp" exists)
*AND*
2) "rd.iscsi.ibft" was given on the kernel cmdline.

It does not happen if
1) the initaitor network configuration for iSCSI boot is STATIC
*OR*
2) the ip-information was explicitly given on the kernel cmdline (ip=<addres>::<gateway>:<netmask>:<nameserver>:<portname>:none)

In the emergency shell, analysis shows that the NIC has no IP address, although an IP address was assigned previously (see attached journalctl output lines 2920ff):
dhclient[711]: DHCPDISCOVER on ibft0 to 255.255.255.255 port 67 interval 4 (xid=0x608459f7)
dhclient[711]: DHCPREQUEST on ibft0 to 255.255.255.255 port 67 (xid=0x608459f7)
dhclient[711]: DHCPOFFER from 172.17.92.210
dhclient[711]: DHCPACK from 172.17.92.210 (xid=0x608459f7)
dhclient[711]: bound to 172.17.92.114 -- renewal in 1582 seconds.

"ip a" shows:
3: ibft0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 90:1b:0e:0d:07:15 brd ff:ff:ff:ff:ff:ff
    inet6 fd7d:d06b:8660:1792:921b:eff:fe0d:715/64 scope global dynamic
       valid_lft 2591945sec preferred_lft 604745sec
    inet6 fe80::921b:eff:fe0d:715/64 scope link
       valid_lft forever preferred_lft forever
=> The IP address which was set is now lost.

This looks like a race condition:
* If CR is hit while grub2 waits for the timeout, the error occurs more often
* If the timeout expires in grub2, the error occurs less frequently.

I have attached the output of "journalctl" while in the emergency shell.

NB RedHat 7.2. has other issues: see bz 1269195, so "try using 7.2" is not an option as it might work but also might not!
Comment 1 Josef Möllers 2016-03-14 06:09:18 EDT
Added FTS internal bug ID.
Comment 2 Josef Möllers 2016-03-14 06:09:49 EDT
Added chorn to list of cc.
Comment 4 Josef Möllers 2016-05-25 03:11:34 EDT
As I will be moving on to pastures new in a few weeks time, I will not be able to provide any assistance. Somebody else will hopefully follow up.

So long,

Josef
Comment 5 Harald Hoyer 2016-07-22 08:44:59 EDT
might be fixed already with the RHEL-7.3 candidate:

http://people.redhat.com/harald/downloads/dracut/dracut-033-436.el7/

Note You need to log in before you can comment on or make changes to this bug.