Created attachment 408050 [details]
Attached traceback automatically from anaconda.

What steps did you take to get to this traceback?

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).

*** Bug 607679 has been marked as a duplicate of this bug. ***

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])

*** Bug 618853 has been marked as a duplicate of this bug. ***

Created an attachment (id=439281)
Attached traceback automatically from anaconda.

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.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Created an attachment (id=440705)
Attached traceback automatically from anaconda.

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.

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.

Created an attachment (id=447749)
Attached traceback automatically from anaconda.

Created an attachment (id=447788)
Attached traceback automatically from anaconda.

Just a note: as of F14 development this appears to be a live-only, biosraid-only bug.

Created attachment 448755 [details]
Attached traceback automatically from anaconda.

(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.

Created attachment 448764 [details]
Attached traceback automatically from anaconda.

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.

Will there be a fix in the Beta?

No. For most of you, however, using the non-live installer will prevent this bug from appearing.

Created attachment 450537 [details]
Attached traceback automatically from anaconda.

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.

*** Bug 638705 has been marked as a duplicate of this bug. ***

Created attachment 450556 [details]
Attached traceback automatically from anaconda.

(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

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).

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".

Created attachment 451055 [details]
Attached traceback automatically from anaconda.

Created attachment 451215 [details]
Attached traceback automatically from anaconda.

*** Bug 640403 has been marked as a duplicate of this bug. ***

Is there a status on the progress towards fixing this bug?  Any additional information that could be gathered to make fixing it easier?

Created attachment 452230 [details]
Attached traceback automatically from anaconda.

(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..

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.

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.

(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)

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?

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.

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)

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

Moving into ON_QA, a fix is available for testing at https://admin.fedoraproject.org/updates/python-pyblock-0.51-1.fc14

Created attachment 454462 [details]
Attached traceback automatically from anaconda.

Created attachment 454475 [details]
Attached traceback automatically from anaconda.

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

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

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.