Bug 1294571 - Can not install 7.2 to iSCSI target in UEFI mode
Can not install 7.2 to iSCSI target in UEFI mode
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda (Show other bugs)
7.2
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-28 22:31 EST by Neil
Modified: 2016-02-19 10:40 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-20 03:50:47 EST
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)
Logs in Anaconda. (47.25 KB, application/x-gzip)
2015-12-28 22:31 EST, Neil
no flags Details

  None (edit)
Description Neil 2015-12-28 22:31:55 EST
Created attachment 1110074 [details]
Logs in Anaconda.

Description of problem:
RHEL 7.2 can not be installed to iSCSI target.

Version-Release number of selected component (if applicable):
RHEL7.2

How reproducible:
Always.


Steps to Reproduce:
1.Boot system in UEFI mode.
2.Install Linux iSCSI service to another server. 
3.Install RHEL7.2 with ISO image to iSCSI target. 
4.During installing, partition iSCSI disk in auto mode. 
5.Anaconda crash then. 

Actual results:
Can not install OS.


Expected results:
Install OS to iSCSI target. 

Additional info:
RHEL6.7 works fine.
Bug can be seen on VM also. 

Oracle bug ID: 22382171 for reference.
Comment 1 Neil 2015-12-29 02:38:39 EST
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?
Comment 3 Neil 2016-01-12 21:33:16 EST
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?
Comment 4 Radek Vykydal 2016-01-13 08:23:39 EST
(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?
Comment 5 Neil 2016-01-14 21:37:29 EST
Yes. I think we should enable customer installing bootloader, /boot, / to iSCSI target even when there is local disk available. That'll make sense.
Comment 6 Neil 2016-01-15 01:42:42 EST
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.
Comment 7 Radek Vykydal 2016-01-15 06:34:47 EST
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.
Comment 8 Neil 2016-01-20 01:29:39 EST
After appending "ip=ibft" option, bug can be fixed.
Comment 9 Neil 2016-01-20 01:30:22 EST
So, please close this bug. Thanks.
Comment 10 Radek Vykydal 2016-01-20 03:50:47 EST
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.

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