|Summary:||AttributeError: 'NoneType' object has no attribute 'name'|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Martin Hoyer <mhoyer>|
|Component:||anaconda||Assignee:||Brian Lane <bcl>|
|Status:||CLOSED ERRATA||QA Contact:||Release Test Team <release-test-team>|
|Severity:||high||Docs Contact:||Clayton Spicer <cspicer>|
|Version:||7.2||CC:||aheverle, bcl, chorn, fdeutsch, josef.moellers, mbanas, mhoyer, rvykydal|
|Fixed In Version:||anaconda-188.8.131.52-1||Doc Type:||Bug Fix|
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.
|Last Closed:||2016-11-03 23:16:02 UTC||Type:||---|
|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 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: anaconda-184.108.40.206-1 The following was filed automatically by anaconda: anaconda 220.127.116.11-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
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 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 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 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.""" 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?
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 https://bugzilla.redhat.com/show_bug.cgi?id=1164195#c19 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: /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?
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? /tmp/anaconda.log /tmp/syslog /tmp/program.log /tmp/ifcfg.log /tmp/storage.log 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 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>:...".
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. https://github.com/rhinstaller/anaconda/pull/624
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 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. https://rhn.redhat.com/errata/RHEA-2016-2158.html