+++ This bug was initially created as a clone of Bug #1324435 +++

Description of problem:
Anaconda exception occurs on iscsi machine

Version-Release number of selected component (if applicable):
ovirt-node-ng-installer-master-20160405.iso
squashfs.20160405
ovirt-node-ng-image-update-placeholder-4.0.0-0.2.alpha1.20160405123556.gitbd184ec.el7.noarch
imgbased-0.5-0.201604040928gitd6a85f8.el7.centos.noarch
ovirt-release-host-node-4.0.0-0.2.alpha1.20160405123556.gitbd184ec.el7.noarch


How reproducible:
100%

Steps to Reproduce:
1. Boot from PXE and manual install ngn 4.0.
2. Try to finish the installation with correct steps.
3. Focus on the installation process.
4. Please see the attachment for more detail.

Actual results:
Anaconda exception occurs on iscsi machine

Expected results:


Additional info:
No such issue on FC/local machine.

--- Additional comment from shaochen on 2016-04-06 12:42 CEST ---



--- Additional comment from Fabian Deutsch on 2016-04-06 22:52:03 CEST ---

From comment 1 's anaconda.log:

14:13:00,548 INFO anaconda: Installing boot loader
14:13:00,549 DEBUG anaconda: running handleException
14:13:00,550 CRIT anaconda: Traceback (most recent call last):

  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, in run
    threading.Thread.run(self, *args, **kwargs)

  File "/usr/lib64/python2.7/threading.py", line 764, in run
    self.__target(*self.__args, **self.__kwargs)

  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 254, in doInstall
    writeBootLoader(storage, payload, instClass, ksdata)

  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2383, in writeBootLoader
    log.info("boot loader stage1 target device is %s", stage1_device.name)

AttributeError: 'NoneType' object has no attribute 'name'

14:13:00,551 DEBUG anaconda: Gtk running, queuing exception handler to the main loop

Looks like a bug in anaconda.

Any idea, anaconda team?

--- Additional comment from Red Hat Bugzilla Rules Engine on 2016-04-06 22:52:31 CEST ---

This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

--- Additional comment from Radek Vykydal on 2016-04-07 12:01:48 CEST ---

14:09:38,712 DEBUG anaconda: stage1 device cannot be on an iSCSI disk
14:09:40,759 DEBUG anaconda: new disk order: []
14:09:40,809 DEBUG anaconda: stage1 device cannot be of type lvmvg
14:09:40,810 DEBUG anaconda: stage1 device cannot be of type lvmthinlv
14:09:40,810 DEBUG anaconda: stage1 device cannot be of type lvmthinpool
14:09:40,811 DEBUG anaconda: stage1 device cannot be of type lvmthinlv
14:09:40,812 DEBUG anaconda: stage1 device cannot be of type lvmlv
14:09:40,813 DEBUG anaconda: stage1 device cannot be on an iSCSI disk
14:09:40,814 DEBUG anaconda: stage1 device cannot be of type partition
14:09:40,814 DEBUG anaconda: stage1 device cannot be of type partition
14:09:40,815 ERR anaconda: BootLoader setup failed: failed to find a suitable stage1 device

Seems like duplicate of bug 1269195, see esp.
https://bugzilla.redhat.com/show_bug.cgi?id=1269195#c23

--- Additional comment from Radek Vykydal on 2016-04-07 12:22:12 CEST ---

Perhaps we are incorrectly disallowing installing bootloader on offload iSCSI disks.

--- Additional comment from Fabian Deutsch on 2016-04-07 13:02:16 CEST ---

Thanks Rdaek.

Let's keep this bug for tracking prupose on the RHEV-H side.

--- Additional comment from Radek Vykydal on 2016-04-07 14:23:43 CEST ---

Would you be able to test this updates image (for RHEL 7.2) with fix?

It can be applied either by boot option:

updates https://rvykydal.fedorapeople.org/updates.iscsioffload.img

or by kickstart command

updates=https://rvykydal.fedorapeople.org/updates.iscsioffload.img

I think if the case is (as I assume from the logs) an installation to a single (partial?) offload iSCSI device we can reassign the bug to Anaconda. I'm asking for assistance with checking the fix as it is not easy to get to the hw.

--- Additional comment from Radek Vykydal on 2016-04-07 15:52:48 CEST ---

(In reply to Radek Vykydal from comment #7)

Oh sorry,

> Would you be able to test this updates image (for RHEL 7.2) with fix?
> 
> It can be applied either by boot option:
> 
> updates https://rvykydal.fedorapeople.org/updates.iscsioffload.img
> 

this is kickstart command

> or by kickstart command
> 
> updates=https://rvykydal.fedorapeople.org/updates.iscsioffload.img
> 

this is boot option

--- Additional comment from shaochen on 2016-04-08 08:37:44 CEST ---

(In reply to Radek Vykydal from comment #8)
> (In reply to Radek Vykydal from comment #7)
> 
> Oh sorry,
> 
> > Would you be able to test this updates image (for RHEL 7.2) with fix?
> > 
> > It can be applied either by boot option:
> > 
> > updates https://rvykydal.fedorapeople.org/updates.iscsioffload.img
> > 
> 
> this is kickstart command
> 
> > or by kickstart command
> > 
> > updates=https://rvykydal.fedorapeople.org/updates.iscsioffload.img
> > 
> 
> this is boot option

The update image work well on single path iscsi machine, the installation can successful. Please see the attachment "complete-iscis.png" for more detail. 

updates=https://rvykydal.fedorapeople.org/updates.iscsioffload.img

--- Additional comment from shaochen on 2016-04-08 08:38 CEST ---



--- Additional comment from Radek Vykydal on 2016-04-08 09:24:54 CEST ---

Should I create a clone for anaconda or are you OK with reassigning the BZ?

--- Additional comment from Radek Vykydal on 2016-04-08 09:31:26 CEST ---

Also reproducible on storageqe-81.lab.eng.brq.redhat.com.

--- Additional comment from Fabian Deutsch on 2016-04-08 13:27:47 CEST ---

I'll clone it Radek, because we need to track it from the RHEV side.