The following was filed automatically by anaconda: anaconda 15.22 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 607, in __setitem__ self.model.set_value(self.iter, key, value) File "/usr/lib64/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 1002, in populate self.tree[iter]['Size (MB)'] = vg.freeSpace File "/usr/lib64/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 1840, in getScreen self.populate(initial = 1) File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1338, in setScreen new_screen = self.currentWindow.getScreen(anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1258, in nextClicked self.setScreen () TypeError: value is of the wrong type for this column
Created attachment 483777 [details] Attached traceback automatically from anaconda.
I'm doing a fresh install using jlaska's new boot.iso from this morning (15.22-1). After selecting basic storage devices, and defaults for intro options, then using Custom disk layout, the "Examining storage devices" notice appears, followed by the above traceback.
*** Bug 684302 has been marked as a duplicate of this bug. ***
Ales - my guess for why we are seeing this issue (and the other similar one, also assigned to you) is that python or pygtk was allowing us to get away with some implicit type conversion where the model said a column was a string but we could toss an int in without running str() on it first. And now that's changed. I can't see that we've changed either the gtk code or the types of the things we're storing in these models. So the two fix options are we change the models to have the column be an int type, or we call str() on things before putting them into the model. The first option seems to be nicer - we might as well be storing in the model the actual things, rather than a type converted form of them. Feel free to reassign back to a-m-l if you don't want to work on this. I just assigned this one to you since you already had the related one.
The related issue is bug 682543.
Created attachment 485579 [details] Attached traceback automatically from anaconda.
(In reply to comment #5) > The related issue is bug 682543. That linked issue has now been reassigned to gtk. Should this bug follow, or are there anaconda changes needed here?
Steps I used to reproduce: 1. Started with bare metal (laptop) that has LVM partitioning setup. Fair number of LVs, but nothing too exotic. 2. Boot from a copy of the pxelinux flavor vmlinuz + initrd.img. I used one jlaska produced for testing anaconda-15.22-1, but the same error happened in 15.20.1-1. 3. Choose basic storage devices, and defaults for everything, until disk setup screen. 4. Choose Custom layout, and the "Examining storage" dialog comes up. 5. After a short time, poof, traceback.
By the way, vmlinuz + initrd.img were stored on my hard disk's /boot partition. I booted into them from GRUB.
> That linked issue has now been reassigned to gtk. Should this bug follow, or > are there anaconda changes needed here? James, If this is fixed on the GTK side (the right thing to do), we will be able to close this as dupe. If not I want to keep this bug to track one more place that needs mending.
Discussed at the 2011-03-18 blocker review meeting. We're worried about this one, but so far not enough data to be sure it's a blocker. Exactly what condition is needed to trigger this bug? Is it some particular content in the column in question (disk size?), or some number of entries in that column, or something like that? Thanks. CCing mclasen: Matthias, this is another issue caused by 682543. Just to make you aware this is a potential beta blocker and we'd definitely like to see pygobject fixed. thanks!
Created attachment 486390 [details] Attached traceback automatically from anaconda.
Booted desktop nightly 20110318. Started install to hard disk. Selected custom partitioning traceback occurred during (end of?) storage device scan. System has intel bios raid 10 device serving as PV for numerous lvs all of which are seen in the live session.
Created attachment 486714 [details] Attached traceback automatically from anaconda.
This time JLaska's custom boot.iso. Same steps as Comment 13
*** This bug has been marked as a duplicate of bug 682543 ***
Created attachment 486972 [details] Attached traceback automatically from anaconda.
Created attachment 487403 [details] Attached traceback automatically from anaconda.
Created attachment 487542 [details] Attached traceback automatically from anaconda.
Created attachment 487601 [details] Attached traceback automatically from anaconda.
For me it happened when installing fedora15/x86_64 through boot.fedoraproject.org. I'd be happy to test F15.
Created attachment 487685 [details] Attached traceback automatically from anaconda.