Bug 1294571

08:45:26,735 DEBUG anaconda: stage1 device cannot be of type iscsi
08:45:27,809 DEBUG anaconda: new disk order: []
08:45:27,833 DEBUG anaconda: stage1 device cannot be of type lvmvg
08:45:27,833 DEBUG anaconda: stage1 device cannot be of type lvmlv
08:45:27,833 DEBUG anaconda: stage1 device cannot be of type lvmlv
08:45:27,834 DEBUG anaconda: stage1 device cannot be of type lvmlv
08:45:27,834 DEBUG anaconda: stage1 device cannot be of type iscsi
08:45:27,835 DEBUG anaconda: stage1 device cannot be on an iSCSI disk
08:45:27,835 DEBUG anaconda: stage1 device cannot be on an iSCSI disk
08:45:27,835 DEBUG anaconda: stage1 device cannot be on an iSCSI disk
08:45:27,836 ERR anaconda: BootLoader setup failed: failed to find a suitable stage1 device


   def set_stage1_device(self, devices):
        ...     
            if self.is_valid_stage1_device(device):
                if flags.imageInstall and device.isDisk:
                    # GRUB2 will install to /dev/loop0 but not to
                    # /dev/mapper/<image_name>
                    self.stage1_device = device.parents[0]
                else:
                    self.stage1_device = device

                break

        if not self.stage1_device:
            self.reset()
            raise BootLoaderError("failed to find a suitable stage1 device")

    def is_valid_stage1_device(self, device, early=False):
        ...
        constraint = platform.platform.bootStage1ConstraintDict

        if device is None:
            return False

        if not self._device_type_match(device, constraint["device_types"]):
            log.debug("stage1 device cannot be of type %s", device.type)
            return False

        if _is_on_iscsi(device) and not _is_on_ibft(device):
            log.debug("stage1 device cannot be on an iSCSI disk")
            return False

So, the root cause is clear. iSCSI storage can't be stage1 device, why?

I'm not authorized to access bug #1164195. Could you open access to me? Or, you might paste info here. Thanks. 

And, since RHEL6.7 works as expected, why different?

(In reply to Neil from comment #3)
> I'm not authorized to access bug #1164195. Could you open access to me? Or,
> you might paste info here. Thanks. 
> 

You should be able to access it now.

Basically, this is the change in 7.2:
https://bugzilla.redhat.com/show_bug.cgi?id=1164195#c20

> And, since RHEL6.7 works as expected, why different?

The motivation should be given by the bug Description.
We might have gone too far imposing the restriction on /boot partitions by ruling-out some valid use cases?

Yes. I think we should enable customer installing bootloader, /boot, / to iSCSI target even when there is local disk available. That'll make sense.

I found description as below in RHEL7 installation guide: 

The /boot partition cannot be placed on iSCSI targets which have been added manually using this method - an iSCSI target containing a /boot partition must be configured for use with iBFT.

Could you explain details on that? If I configure /boot partition with iBFT, the /boot part should always be placed on that iSCSI target, right? I'm confusing.

We just make the assumption that when placing stage 1 on an iSCSI device, user wants to boot from that device, so the device (iSCSI target) for booting is configured in iBFT table.

(In reply to Neil from comment #5)
> Yes. I think we should enable customer installing bootloader, /boot, / to
> iSCSI target even when there is local disk available. That'll make sense.

This should still be allowed in 7.2 but the device holding stage 1 must be configured (and therefore automatically attached by anaconda) in iBFT.

After appending "ip=ibft" option, bug can be fixed.

So, please close this bug. Thanks.

Trying to sum up the case: per comment #8 the issue here seems to be no network connection available for iscsi target configured in iBFT which resulted in anaconda not being able to automatically attach the target, so the target was added manually in GUI, which prevented placing boot loader on the device (as explained in comment #7). The issue is solved by activating network connection required for iBFT target using ip=ibft boot option.