Bug 1269195

Created attachment 1080278 [details]
File: anaconda-tb

Created attachment 1080279 [details]
File: anaconda.log

Created attachment 1080280 [details]
File: environ

Created attachment 1080281 [details]
File: ks.cfg

Created attachment 1080282 [details]
File: lsblk_output

Created attachment 1080283 [details]
File: nmcli_dev_list

Created attachment 1080284 [details]
File: os_info

Created attachment 1080285 [details]
File: program.log

Created attachment 1080286 [details]
File: storage.log

Created attachment 1080287 [details]
File: syslog

Created attachment 1080288 [details]
File: ifcfg.log

Created attachment 1080289 [details]
File: packaging.log

Did you ignore an error in the storage spoke?

15:12:55,670 DEBUG anaconda: stage1 device cannot be on an iSCSI disk
15:12:55,909 DEBUG anaconda: new disk order: []
15:12:55,940 DEBUG anaconda: stage1 device cannot be of type lvmvg
15:12:55,941 DEBUG anaconda: stage1 device cannot be of type lvmlv
15:12:55,941 DEBUG anaconda: stage1 device cannot be of type lvmlv
15:12:55,941 DEBUG anaconda: stage1 device cannot be on an iSCSI disk
15:12:55,942 DEBUG anaconda: stage1 device cannot be of type partition
15:12:55,942 DEBUG anaconda: stage1 device cannot be of type partition
15:12:55,943 ERR anaconda: BootLoader setup failed: failed to find a suitable stage1 device

The iscsi disk does not appear to be detected by the firmware, so you will not be able to boot from it. Anaconda should detect that, which it seems to have done, but I don't see how you got past that.

I've got no error until this one.
I had to detect the iscsi disk manually, which is weird, since it was detected in bios, and when I'm installing RHEL-6-7 in same way, anaconda detects it (however it does have similar problem).

One of our partners is hitting this now.  Also with a pure linux software iSCSI target.

In comment #15,  David Lehman writes:
> The iscsi disk does not appear to be detected by the firmware, so you will not be able to boot from it. Anaconda should detect that, which it seems to have done, but I don't see how you got past that.

In my case, at least, this is not true: the firmware detects the disk, logs into the target and does a READ CAPACITY. The firmware supports iSCSI boot.

This BIOS extension is purely software too, the NIC does not have any hardware support for iSCSI.

Again: 7.1 installed properly and runs like a charm on this system. I cannot recall any problems during installation!

My 2cts ...

I have taken a look at the pyanaconda modules and found this:
    124 def _is_on_ibft(device):
    125     """Tells whether a given device is ibft disk or not."""
    126
    127     return all(getattr(disk, "ibft", False) for disk in device.disks)
      :
    592         if _is_on_iscsi(device) and not _is_on_ibft(device):
    593             log.debug("stage1 device cannot be on an iSCSI disk")
    594             return False
[bootloader.py]
but I don't find the place where the "ibft"-attribute is set!?!
But then ... it would not work on any iSCSI target?

The /sys/firmware/ibft is populated, the iscsi_ibft.ko module is loaded.

Where is the "ibft"-attribute set?

Re comment #20:
Apparently it is set in the python-blivet package.
Continuing investigation.

anaconda team, did you succeed in reproducing this?

This works for me:
- setup iscsi target on a fedora23 system, i.e. 10GB sparse file
- verify from a rhel7 VM that the iscsi target can be accessed
- start a KVM guest, boot from 7.2 media, activate network
- log into the iscsi target, installation proceeds until until "installing bootloader"

No ibft table is configured at that time.

So we disallowed /boot (and bootloader stage1) on iSCSI disks that are not attached from iBFT configuration in bug 1164195. I am not completely sure about not ruling-out some valid use cases (I can think only of two: configuring ibft during first reboot into installed system, or case when for some reason target configured in iBFT is not recognized and autoattached in anaconda so it has to be attached manually, but installed system boots from the iBFT target fine.)

The problem we should fix is that Anaconda does not warn about the bootloader placement not being allowed during partitioning configuration. It tracebacks at the end of installation when installing bootloader. Ie the
https://bugzilla.redhat.com/show_bug.cgi?id=1164195#c19
is not true for 7.2 GA.

Picking up the thread ...
I got sidetracked from further investigation.
Again: The iSCSI target has a valid iBFT:

/sys/firmware/ibft/ethernet0/dhcp:172.17.92.210
/sys/firmware/ibft/ethernet0/flags:3
/sys/firmware/ibft/ethernet0/gateway:172.17.92.254
/sys/firmware/ibft/ethernet0/hostname:DMC-RX300S8-17
/sys/firmware/ibft/ethernet0/index:0
/sys/firmware/ibft/ethernet0/ip-addr:172.17.92.114
/sys/firmware/ibft/ethernet0/mac:90:1b:0e:0d:07:15
/sys/firmware/ibft/ethernet0/origin:3
/sys/firmware/ibft/ethernet0/primary-dns:172.17.92.228
/sys/firmware/ibft/ethernet0/secondary-dns:172.17.92.229
/sys/firmware/ibft/ethernet0/subnet-mask:255.255.255.0
/sys/firmware/ibft/ethernet0/vlan:0
/sys/firmware/ibft/initiator/flags:3
/sys/firmware/ibft/initiator/index:0
/sys/firmware/ibft/initiator/initiator-name:iqn.2014-10.qanet.ro.dmc1:lun00
/sys/firmware/ibft/target0/chap-type:0
/sys/firmware/ibft/target0/flags:3
/sys/firmware/ibft/target0/index:0
/sys/firmware/ibft/target0/ip-addr:172.17.92.212
/sys/firmware/ibft/target0/lun:00000000
/sys/firmware/ibft/target0/nic-assoc:0
/sys/firmware/ibft/target0/port:3260
/sys/firmware/ibft/target0/target-name:iqn.2014-01.qanet.ro.dmc1:c0p0

Yet I get bitten by this bug!

Any news on this issue?

Question: As the target *is* detected and reported through the iBFT, how do I specify this in the installer? It is not auto-detected and I cannot find anything to mark the target as bing identifyable through iBFT!

Josef, could you please attach installation logs for your case from comment #24 so we can see whether and why Anaconda doesn't see the iBFT target or doesn't consider it as such?

/tmp/anaconda.log
/tmp/syslog
/tmp/program.log
/tmp/ifcfg.log
/tmp/storage.log

Also output of "iscsiadm -m fw" would be handy.

I'm afraid I can't.

1) The system that I first tried to install 7.2 on (a BX924S2 blade server) is now happily running 7.2. My notes do not reveal what exactly I did to deserve this: they just say "sh*t, I cannot install 7.2 as it does not recognize the target" and then "installing source packages to anaylze an SNMP problem".

2) The system that I copied the iBFT data in comment #24 has problems booting 7.1 in a certain configuration (iSCSI boot network configuration through DHCP *and* "rd.iscsi.ibft" *) booting fails with "iscsistart: cannot make a connection to 172.17.92.212:3260 (-1,101)".
I am unsure whether this is the same issue. I'm still analyzing the 7.1 boot failure and I am hesitant to make a 7.2 installation on the target before coming to a conclusion wrt the 7.1 failure.

(*) static network configuration is OK as is explicit "ip=<IP addres>:...".

I see. If you happen to hit the issue with 7.2 some time and attach the logs, we can investigate more.
For now I'll stick with comment #23 for this BZ.

BTW, the ibft targets are identified in https://github.com/rhinstaller/blivet/blob/rhel7-branch/blivet/iscsi.py#L201

Backport of an upstream patch to actually display the error instead of just logging it. The error was being logged, but then overwritten by another disk check so it was never shown to the user.

https://github.com/rhinstaller/anaconda/pull/624

Created attachment 1178940 [details]
mbanas: anaconda.log

Created attachment 1178941 [details]
mbanas: ifcfg.log

Created attachment 1178942 [details]
mbanas: packaging.log

Created attachment 1178943 [details]
mbanas: program.log

Created attachment 1178944 [details]
mbanas: storage.log

Created attachment 1178945 [details]
mbanas: storage.state

Created attachment 1178946 [details]
mbanas: syslog

ok, so the issue was that I didn't use ip=ibft parameter on cmdline. With this parameter installation on storage80 works as expected. So I'm moving this bug to VERIFIED and removing FailedQA keyword.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-2158.html