Description of problem: When installing on disks with previous installation of RHEL6, anaconda throws a traceback: Traceback (most recent call first): File "/usr/lib/anaconda/partRequests.py", line 811, in getDevice if (r.size > 0) or (r.device is not None): File "/usr/lib/anaconda/partRequests.py", line 202, in toEntry device = self.getDevice(partitions) File "/usr/lib/anaconda/partitioning.py", line 124, in partitioningComplete entry = request.toEntry(anaconda.id.partitions) File "/usr/lib/anaconda/dispatch.py", line 201, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 124, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1156, in nextClicked self.anaconda.dispatch.gotoNext() AttributeError: 'NoneType' object has no attribute 'size' Partitioning of RHEL6 installation is the default created by anaconda: [root@jake ~]# pvs PV VG Fmt Attr PSize PFree /dev/dasda2 vg_jake lvm2 a- 2.09G 0 /dev/dasdb1 vg_jake lvm2 a- 2.29G 0 /dev/dasdc1 vg_jake lvm2 a- 2.29G 0 [root@jake ~]# vgs VG #PV #LV #SN Attr VSize VFree vg_jake 3 2 0 wz--n- 6.67G 0 [root@jake ~]# lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert lv_root vg_jake -wi-ao 5.45G lv_swap vg_jake -wi-ao 1.22G [root@jake ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_jake-lv_root 5.4G 834M 4.3G 16% / /dev/dasda1 194M 38M 147M 21% /boot tmpfs 307M 0 307M 0% /dev/shm vg_jake-lv_root is ext4 /dev/dasda1 is ext3 Version-Release number of selected component (if applicable): RHEL5.4 anaconda-11.1.2.195-1 How reproducible: always, discovered on s390x architecture Steps to Reproduce: 1. install RHEL6.0, use default partitioning 2. start new vnc installation of RHEL5.4 3. at partitioning screen select only two last dasd disks to use 4. click on Next Actual results: AttributeError: 'NoneType' object has no attribute 'size' Expected results: no traceback, user is able to finish installation
This is very probably a duplicate of bug #532536 for which I have a patch ready.
(In reply to comment #2) > This is very probably a duplicate of bug #532536 for which I have a patch > ready. Here is updates image with the patch for testing: http://rvykydal.fedorapeople.org/updates.545869.img
With RHEL5.4 and updates image from comment 3, I was able to finish installation using steps described in comment 0. Tested on s390x architecture.
To summarize descriptions/reproducers from duplicate bugs, the bug is platform-independent and happens during autopartition install on system with: * preexisting VG having PVs on 2 or more drives * with one of the drives holding the PVs deselected for installation.
*** Bug 532536 has been marked as a duplicate of this bug. ***
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
(In reply to comment #5) > To summarize descriptions/reproducers from duplicate bugs, the bug is > platform-independent and happens during autopartition install on system with: > * preexisting VG having PVs on 2 or more drives > * with one of the drives holding the PVs deselected for installation. More accurate description of contitions triggering traceback is: Traceback occurs in this case: * have VG with PVs on 2 or more drives * do clearpart (e.g. via UI auto "Remove..." partitioning) on only some of the drives (e.g. one of drives containing a PV of the VG is deselected in UI)
Should be fixed in anaconda-11.1.2.199-1.
VERIFIED with anaconda-11.1.2.199. Installing with partitioning option "Remove all partitions and use all available space" on the first disk (2nd is unselected) doesn't cause a back-trace and installation completes successfully.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0194.html