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!