Bug 1269195

Summary: AttributeError: 'NoneType' object has no attribute 'name'
Product: Red Hat Enterprise Linux 7 Reporter: Martin Hoyer <mhoyer>
Component: anacondaAssignee: Brian Lane <bcl>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team>
Severity: high Docs Contact: Clayton Spicer <cspicer>
Priority: high    
Version: 7.2CC: aheverle, bcl, chorn, fdeutsch, josef.moellers, mbanas, mhoyer, rvykydal
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: abrt_hash:32191120fa73a98a724c85f9a88618d1ecf3675437b841d20619e86d811f8384
Fixed In Version: anaconda- Doc Type: Bug Fix
Doc Text:
Errors in custom partitioning are correctly detected Previously, errors in custom partitioning were not displayed to the user properly, allowing the installation to continue with an invalid custom partition configuration, leading to unexpected behavior. This bug has been fixed and errors in custom partitioning are now correctly reported to the user so they can be adjusted before continuing the installation.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-03 23:16:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1203710, 1313485, 1245518, 1295926, 1324435, 1325134, 1353495, 1364088    
Description Flags
File: anaconda-tb
File: anaconda.log
File: environ
File: ks.cfg
File: lsblk_output
File: nmcli_dev_list
File: os_info
File: program.log
File: storage.log
File: syslog
File: ifcfg.log
File: packaging.log
mbanas: anaconda.log
mbanas: ifcfg.log
mbanas: packaging.log
mbanas: program.log
mbanas: storage.log
mbanas: storage.state
mbanas: syslog none

Description Martin Hoyer 2015-10-06 15:22:03 UTC
Description of problem:
Trying to install RHEL to iscsi device connected via cxgb4i HBA

Version-Release number of selected component:

The following was filed automatically by anaconda:
anaconda exception report
Traceback (most recent call first):
  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)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 254, in doInstall
    writeBootLoader(storage, payload, instClass, ksdata)
  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/threads.py", line 227, in run
    threading.Thread.run(self, *args, **kwargs)
AttributeError: 'NoneType' object has no attribute 'name'

Additional info:
addons:         com_redhat_kdump, org_fedora_oscap
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=/images/storageqe-80.lab.eng.brq.redhat.com/initrd console=ttyS1,115200n81 ks=http://beaker.engineering.redhat.com/kickstart/1601350 ksdevice=bootif serial vnc netboot_method=pxe BOOT_IMAGE=/images/storageqe-80.lab.eng.brq.redhat.com/kernel BOOTIF=01-e8-39-35-f0-5d-84 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.10.0-320.el7.x86_64
product:        Red Hat Enterprise Linux 7
release:        Red Hat Enterprise Linux Workstation release 7.2 Beta (Maipo)
release_type:   pre-release
type:           anaconda
uid:            0
version:        7.2

Comment 1 Martin Hoyer 2015-10-06 15:22:10 UTC
Created attachment 1080278 [details]
File: anaconda-tb

Comment 2 Martin Hoyer 2015-10-06 15:22:12 UTC
Created attachment 1080279 [details]
File: anaconda.log

Comment 3 Martin Hoyer 2015-10-06 15:22:14 UTC
Created attachment 1080280 [details]
File: environ

Comment 4 Martin Hoyer 2015-10-06 15:22:15 UTC
Created attachment 1080281 [details]
File: ks.cfg

Comment 5 Martin Hoyer 2015-10-06 15:22:17 UTC
Created attachment 1080282 [details]
File: lsblk_output

Comment 6 Martin Hoyer 2015-10-06 15:22:18 UTC
Created attachment 1080283 [details]
File: nmcli_dev_list

Comment 7 Martin Hoyer 2015-10-06 15:22:20 UTC
Created attachment 1080284 [details]
File: os_info

Comment 8 Martin Hoyer 2015-10-06 15:22:22 UTC
Created attachment 1080285 [details]
File: program.log

Comment 9 Martin Hoyer 2015-10-06 15:22:25 UTC
Created attachment 1080286 [details]
File: storage.log

Comment 10 Martin Hoyer 2015-10-06 15:22:28 UTC
Created attachment 1080287 [details]
File: syslog

Comment 11 Martin Hoyer 2015-10-06 15:22:30 UTC
Created attachment 1080288 [details]
File: ifcfg.log

Comment 12 Martin Hoyer 2015-10-06 15:22:33 UTC
Created attachment 1080289 [details]
File: packaging.log

Comment 14 Brian Lane 2015-10-07 00:39:33 UTC
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

Comment 15 David Lehman 2015-10-07 13:42:35 UTC
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.

Comment 16 Martin Hoyer 2015-10-07 16:18:10 UTC
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).

Comment 17 Christian Horn 2015-12-10 09:23:30 UTC
One of our partners is hitting this now.  Also with a pure linux software iSCSI target.

Comment 19 Josef Möllers 2015-12-11 11:50:57 UTC
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!

Comment 20 Josef Möllers 2015-12-11 14:38:17 UTC
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."""
    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
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?

Comment 21 Josef Möllers 2015-12-14 11:25:47 UTC
Re comment #20:
Apparently it is set in the python-blivet package.
Continuing investigation.

Comment 22 Christian Horn 2015-12-15 12:41:43 UTC
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.

Comment 23 Radek Vykydal 2016-02-19 15:40:07 UTC
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
is not true for 7.2 GA.

Comment 24 Josef Möllers 2016-02-29 10:45:26 UTC
Picking up the thread ...
I got sidetracked from further investigation.
Again: The iSCSI target has a valid iBFT:


Yet I get bitten by this bug!

Any news on this issue?

Comment 25 Josef Möllers 2016-02-29 11:54:36 UTC
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!

Comment 27 Radek Vykydal 2016-03-09 09:59:50 UTC
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?


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

Comment 28 Josef Möllers 2016-03-09 12:53:05 UTC
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 (-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>:...".

Comment 29 Radek Vykydal 2016-03-09 14:00:54 UTC
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

Comment 30 Brian Lane 2016-05-09 22:20:44 UTC
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.


Comment 33 Martin Banas 2016-07-12 15:03:56 UTC
Created attachment 1178940 [details]
mbanas: anaconda.log

Comment 34 Martin Banas 2016-07-12 15:04:00 UTC
Created attachment 1178941 [details]
mbanas: ifcfg.log

Comment 35 Martin Banas 2016-07-12 15:04:06 UTC
Created attachment 1178942 [details]
mbanas: packaging.log

Comment 36 Martin Banas 2016-07-12 15:04:11 UTC
Created attachment 1178943 [details]
mbanas: program.log

Comment 37 Martin Banas 2016-07-12 15:04:17 UTC
Created attachment 1178944 [details]
mbanas: storage.log

Comment 38 Martin Banas 2016-07-12 15:04:23 UTC
Created attachment 1178945 [details]
mbanas: storage.state

Comment 39 Martin Banas 2016-07-12 15:04:29 UTC
Created attachment 1178946 [details]
mbanas: syslog

Comment 42 Martin Banas 2016-07-12 15:55:59 UTC
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.

Comment 47 errata-xmlrpc 2016-11-03 23:16:02 UTC
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.