Red Hat Bugzilla – Full Text Bug Listing
|Summary:||AttributeError: 'NoneType' object has no attribute 'name'|
|Product:||[Fedora] Fedora||Reporter:||Frantisek Hanzlik <franta>|
|Component:||python-pyblock||Assignee:||David Lehman <dlehman>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||13||CC:||alf, anaconda-maint-list, awilliam, dcantrell, donchurch, dzrudy, fedora, giles, hdegoede, jlaska, joel.granados, jonathan, nirvana21, pgp, pjones, reub2000, rhe, tcallawa, vanmeeuwen+fedora|
|Target Milestone:||---||Keywords:||CommonBugs, Triaged|
|Whiteboard:||https://fedoraproject.org/wiki/Common_F14_bugs#bios_raid_exception anaconda_trace_hash:1c9d6ac6d84cd602fb6c6edd6aca61c5e60712e844a01a7ec8f96e430c6ecb6d AcceptedBlocker|
|Fixed In Version:||python-pyblock-0.52-1.fc14||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||639138 641476 (view as bug list)||Environment:|
|Last Closed:||2010-10-20 19:06:28 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||641474, 641476|
|Bug Blocks:||639138, 641108|
Description Frantisek Hanzlik 2010-04-21 08:17:51 EDT
The following was filed automatically by anaconda: anaconda 13.37.2 exception report Traceback (most recent call first): File "/usr/lib/anaconda/iw/partition_gui.py", line 1066, in populate devstring = device.name File "/usr/lib/anaconda/iw/partition_gui.py", line 1836, in getScreen self.populate(initial = 1) File "/usr/lib/anaconda/gui.py", line 1393, in setScreen new_screen = self.currentWindow.getScreen(anaconda) File "/usr/lib/anaconda/gui.py", line 1314, in nextClicked self.setScreen () AttributeError: 'NoneType' object has no attribute 'name'
Comment 1 Frantisek Hanzlik 2010-04-21 08:17:58 EDT
Created attachment 408050 [details] Attached traceback automatically from anaconda.
Comment 2 Chris Lumens 2010-04-21 23:40:02 EDT
What steps did you take to get to this traceback?
Comment 3 Frantisek Hanzlik 2010-04-22 04:59:03 EDT
I was not satisfied with partitiong ordering as designated by anaconda, then I switch from graphical installer to shell, divide disks by fdisk as I was imagined, then switch back to anaconda GUI, and with several (two or three) use "Back" button I return before block device section. Then I want normally continue, but probably during block devices discovery phase anaconda crashed - maybe there remaind some uninitialized objects etc. I think this problem was in older Fedora versions, then in latest (at minimal F11 and F12 I think) this practice was possible. In F13 anaconda disk dividing section seems heavily reworked, but possibility of partition ordering determination probably isn't possible (when not counting primary partition enforcing). I wery often install Fedora on PCs with several disks arranged as SW RAID (md) devices, and almost allways I want by hand determined disk splitting (and e.g. one disk division and then dd MBR to other same disks and eventually enforcing kernel PT rereading by blockdev or fdisk on those other disks).
Comment 4 Chris Lumens 2010-06-24 10:52:43 EDT
*** Bug 607679 has been marked as a duplicate of this bug. ***
Comment 5 alien_life_form 2010-07-22 03:15:33 EDT
I have this issue with anaconda 13.42/i386 System (Dell XPS) has BIOS RAID, with three WIN partions (factory tools, factory restore, win7). Any partitioning scheme (manual w/standard partions (no lvm), lvm auto, lvm review fails, fails with "too many primary partions". (report failed in bug# 568219) I tried to pre-partition the disk, telling anaconda to replace existing partitions, which led to what follows: Traceback (most recent call first): File "/usr/lib/anaconda/iw/partition_gui.py", line 1070, in populate devstring = device.name File "/usr/lib/anaconda/iw/partition_gui.py", line 1844, in getScreen self.populate(initial = 1) File "/usr/lib/anaconda/gui.py", line 1393, in setScreen new_screen = self.currentWindow.getScreen(anaconda) File "/usr/lib/anaconda/gui.py", line 1405, in setScreen return self.setScreen() File "/usr/lib/anaconda/gui.py", line 1314, in nextClicked self.setScreen () AttributeError: 'NoneType' object has no attribute 'name' (full traceback had separately been reported here: [http://www.google.it/url?sa=t&source=web&cd=1&ved=0CBcQFjAA&url=http%3A%2F%2Fforums.fedoraforum.org%2Fattachment.php%3Fattachmentid%3D19742%26d%3D1277495147&ei=Fj08TIzkD47-OdvG5MQP&usg=AFQjCNESY6NU1mDaHd7ic2N9WNVFL4Pr3A&sig2=a9sl-DTePlck5vAxRunNXQ])
Comment 6 Chris Lumens 2010-07-28 09:55:29 EDT
*** Bug 618853 has been marked as a duplicate of this bug. ***
Comment 7 Dawid Zamirski 2010-08-17 22:36:13 EDT
Created an attachment (id=439281) Attached traceback automatically from anaconda.
Comment 8 Dawid Zamirski 2010-08-17 22:49:29 EDT
The traceback that I got was generated from F14 Apha RC3 Live x86_64 with all updates installed via yum (I'm using Live USB). After starting anaconda, when I got to the storage section I did the following: 1. Choose Basic Storage 2. Choose Custom Layout 3. Select one of the drives (in my case RAID 0 strip) as the one to install the system on and mark to intall bootloader on it. 4. Click Next => Crash I can reproduce it every time and I'm unable to install the F14 alpha because of that - I need custom layout as I don't want to format my /home partition.
Comment 9 Manuel Faux 2010-08-19 17:33:26 EDT
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 10 Reuben W. Perelman 2010-08-24 13:23:37 EDT
Created an attachment (id=440705) Attached traceback automatically from anaconda.
Comment 11 Reuben W. Perelman 2010-08-24 13:42:58 EDT
This traceback is from the Fedora 14 Alpha KDE Live CD. I start the installer, fill in information like timezone, etc. I select basic storage, then select custom layout. On the next screen I select the hard drive I want to use, click next and I get an error.
Comment 12 Reuben W. Perelman 2010-09-06 18:25:09 EDT
Tested again in the Septermber 5th nightly compose. Same bug. Will wait until beta images are released to retest unless there is activity in this thread.
Comment 13 James Laska 2010-09-16 09:48:50 EDT
Created an attachment (id=447749) Attached traceback automatically from anaconda.
Comment 14 James Laska 2010-09-16 12:24:05 EDT
Created an attachment (id=447788) Attached traceback automatically from anaconda.
Comment 15 David Lehman 2010-09-17 12:49:05 EDT
Just a note: as of F14 development this appears to be a live-only, biosraid-only bug.
Comment 16 James Laska 2010-09-21 13:28:14 EDT
Created attachment 448755 [details] Attached traceback automatically from anaconda.
Comment 17 James Laska 2010-09-21 13:29:07 EDT
(In reply to comment #15) > Just a note: as of F14 development this appears to be a live-only, > biosraid-only bug. See comment#16 (attachment#448755 [details]) for an NFSISO installation that encountered this issue.
Comment 18 James Laska 2010-09-21 14:04:28 EDT
Created attachment 448764 [details] Attached traceback automatically from anaconda.
Comment 19 David Lehman 2010-09-27 12:34:32 EDT
This is caused by biosraid devices that were mapped via device-mapper but not assigned a UUID by the same. Apparently we cannot rely on DM_UUID even existing.
Comment 20 Reuben W. Perelman 2010-09-27 13:04:26 EDT
Will there be a fix in the Beta?
Comment 21 David Lehman 2010-09-27 13:12:54 EDT
No. For most of you, however, using the non-live installer will prevent this bug from appearing.
Comment 22 Don Church 2010-09-29 14:05:12 EDT
Created attachment 450537 [details] Attached traceback automatically from anaconda.
Comment 23 Don Church 2010-09-29 14:22:21 EDT
sry...I submitted a bug report (bug 638705) before repeating the install process and pasting report directly here. They should be consolidated. :( I thought I could paste the output to my existing bug report.
Comment 24 Chris Lumens 2010-09-29 14:28:17 EDT
*** Bug 638705 has been marked as a duplicate of this bug. ***
Comment 25 James Laska 2010-09-29 15:08:00 EDT
Created attachment 450556 [details] Attached traceback automatically from anaconda.
Comment 26 Brian Lane 2010-09-29 17:24:11 EDT
(In reply to comment #19) > This is caused by biosraid devices that were mapped via device-mapper but not > assigned a UUID by the same. Apparently we cannot rely on DM_UUID even > existing. If so, then this is a dupe of bug 634980 and is fixed in parted-2.3-2
Comment 27 David Lehman 2010-09-30 18:18:10 EDT
There are two totally distinct bugs here: the live one is a parted bug (bug 639138), and the one jlaska is seeing is a pyblock bug (it isn't setting the uuids on the dmraid devices at all).
Comment 28 Adam Williamson 2010-10-01 12:22:08 EDT
This was discussed at the blocker review meeting of 2010/10/01. We agreed that it constitutes a blocker under the criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above".
Comment 29 Jesse Keating 2010-10-01 12:40:16 EDT
Created attachment 451055 [details] Attached traceback automatically from anaconda.
Comment 30 giles 2010-10-02 15:09:50 EDT
Created attachment 451215 [details] Attached traceback automatically from anaconda.
Comment 31 Chris Lumens 2010-10-05 15:34:40 EDT
*** Bug 640403 has been marked as a duplicate of this bug. ***
Comment 32 John Poelstra 2010-10-06 17:28:54 EDT
Is there a status on the progress towards fixing this bug? Any additional information that could be gathered to make fixing it easier?
Comment 33 Dawid Zamirski 2010-10-07 20:03:04 EDT
Created attachment 452230 [details] Attached traceback automatically from anaconda.
Comment 34 Dawid Zamirski 2010-10-07 20:28:37 EDT
(In reply to comment #33) > Created attachment 452230 [details] > Attached traceback automatically from anaconda. FYI, this traceback was generated from the pre-upgrade installer (not live USB). I also ran on this bug when using the install DVD..
Comment 35 David Lehman 2010-10-08 13:36:31 EDT
pjones is working on a patch to the kernel (device-mapper) to allow setting of uuid for already-existing maps, as long as they have no uuid at that time. Patches will also be required for libdevmapper to provide a function along the lines of the existing function dm_task_set_newname, but for uuid instead of name. I have drafted a patch to pyblock that will make use of all of the above to ensure correct uuids are set for dmraid and mpath devices created by pyblock.
Comment 36 Adam Williamson 2010-10-08 14:16:10 EDT
At the 2010-10-08 blocker meeting we agreed to reassign this bug to pyblock and create new bugs against kernel and libdevmapper which block this bug. Jlaska will be doing this.
Comment 37 James Laska 2010-10-08 15:58:08 EDT
(In reply to comment #36) > At the 2010-10-08 blocker meeting we agreed to reassign this bug to pyblock and > create new bugs against kernel and libdevmapper which block this bug. Jlaska > will be doing this. * bug#641474 (lvm2) * bug#641476 (kernel)
Comment 38 James Laska 2010-10-12 11:54:55 EDT
What's the next step for this bug, is there a patch pending based on the changes in the other 2 bugs? Dave, can you post the patch, and should this bug move into MODIFIED, or do we wait on the other 2 bug?
Comment 39 David Lehman 2010-10-12 18:33:35 EDT
Here's the patch review request: https://www.redhat.com/archives/anaconda-devel-list/2010-October/msg00072.html The patches require the libdevmapper and kernel changes tracked by the bugs that block this one. Once the patches have been pushed to upstream pyblock's git repo I will mark this one as MODIFIED.
Comment 40 John Poelstra 2010-10-14 13:24:40 EDT
Resolution of this bug is blocking on https://bugzilla.redhat.com/show_bug.cgi?id=641474 and https://bugzilla.redhat.com/show_bug.cgi?id=641476 (in MODIFIED)
Comment 41 Adam Williamson 2010-10-15 12:34:48 EDT
Discussed at the 2010-10-15 blocker review meeting. pjones is working on this whole set of bugs and expects it to be cleaned up today. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 42 James Laska 2010-10-19 09:41:27 EDT
Moving into ON_QA, a fix is available for testing at https://admin.fedoraproject.org/updates/python-pyblock-0.51-1.fc14
Comment 43 Jesse Keating 2010-10-19 18:30:15 EDT
Created attachment 454462 [details] Attached traceback automatically from anaconda.
Comment 44 Jesse Keating 2010-10-19 20:08:54 EDT
Created attachment 454475 [details] Attached traceback automatically from anaconda.
Comment 45 David Lehman 2010-10-20 12:00:59 EDT
There is a problem with the original patch. Due to another bug in pyblock, my patch prevents creation of device nodes for the partitions, which again leads to the same anaconda traceback. I have proposed a follow-on patch to python-pyblock which resolves the issue in my testing: https://www.redhat.com/archives/anaconda-devel-list/2010-October/msg00203.html
Comment 46 Fedora Update System 2010-10-20 14:59:49 EDT
python-pyblock-0.52-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/python-pyblock-0.52-1.fc14
Comment 47 Fedora Update System 2010-10-20 19:06:21 EDT
python-pyblock-0.52-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.