Red Hat Bugzilla – Bug 1269195
AttributeError: 'NoneType' object has no attribute 'name'
Last modified: 2016-11-03 19:16:02 EDT
Description of problem: Trying to install RHEL to iscsi device connected via cxgb4i HBA Version-Release number of selected component: anaconda-21.48.22.53-1 The following was filed automatically by anaconda: anaconda 21.48.22.53-1 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
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