The following was filed automatically by anaconda: anaconda 13.42 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/__init__.py", line 787, in destroyDevice if device.format.exists and device.format.type: File "/usr/lib/anaconda/storage/partitioning.py", line 390, in removeEmptyExtendedPartitions storage.destroyDevice(extended) File "/usr/lib/anaconda/storage/partitioning.py", line 378, in clearPartitions removeEmptyExtendedPartitions(storage) File "/usr/lib/anaconda/storage/partitioning.py", line 183, in doAutoPartition clearPartitions(anaconda.storage) File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1313, in nextClicked self.anaconda.dispatch.gotoNext() AttributeError: 'NoneType' object has no attribute 'format'
Created attachment 433792 [details] Attached traceback automatically from anaconda.
System uses 1 ATA/IDE disk which contains grub and a Windows partition and 2 SATA disk in an nvidia_raid that contains a Fedora 11 installation. Whenever the nvidia raid is selected for installation the installer stop with the attached messages.
Hi, Thanks for the bug report! Note to self here is what happening: 1) Due to the fix for bug 583484: http://git.fedorahosted.org/git/?p=pyblock.git;a=commitdiff;h=030c578f061509022e4db5136149be173b16139d pyblock no longer creates a mapping, and thus a device node for the extended partition itself 2) This means the extended partition does not get added to the device tree 3) This causes this backtrace when auto-partitioning tries to remove the extended partition (as after clearing partitions it is empty). Solution: Make pyblock create a mapping for extended partitions again, but this time one which is compatible with kpartx's mapping to avoid bug 583484. I hope that your nvidia raid is still in the condition which triggers this fault, I'll provide you with an updates.img with a proposed fix to test this. Regards, Hans
Maurice, This should be fixed in python-pyblock-0.49-1.fc14, as you cannot simply replace a package inside the installer image, I've created an updates.img file for you: http://people.fedoraproject.org/~jwrdegoede/updates-617337-x86_64.img To use this add: updates=http://people.fedoraproject.org/~jwrdegoede/updates-617337-x86_64.img To the syslinux / isolinux cmdline when starting the installer. Note that updates.img files do not work with livecd installs! Thanks & Regards, Hans
Hans, I tried the updates.img file but now it ends with another error (during the creation of filesystem and logical volumes): An error occurred mounting device /dev/mapper/via_cecccejhajp1 as /boot: device /dev/mapper/via_cecccejhajp1 does not exist. This is a fatal error and the install cannot continue. storage.log and anaconda.log are attached.
Created attachment 434233 [details] Anaconda.log
Created attachment 434234 [details] storage.log
Hi, Thanks for testing! Hmm, This is weird the error happens after creating the filesystem, so mke2fs /dev/mapper/via_cecccejhajp1 Has succeeded, but then when we are done creating filesystems and try to mount /dev/mapper/via_cecccejhajp1 we fail ? That is really, well weird. Can you try again, at the fatal error dialog, you should see a save button or some such, choice that, and then you should get a traceback, save that to bugzilla, or attach the generated /tmp/anaconda-tb-* file here. If you do not get a save button, then switch to tty2 (ctrl + alt + F2), and press arrow up there a few times, you should fine something like "killall -SIGUSRx anaconda" in the history there, execute it and then you should get a /tmp/anaconda-tb-* file, which you can then attach here. Thanks, Hans
Created attachment 434456 [details] anaconda-tb-P3aqqZ
Hans, The traceback is attached, please note that when I tried to reproduce this again the first time, the error didn't occur (I'm guessing because the old lv's and vg's were removed. So after installing it again and then retrying, the error occurs again. So it seems that this only occurs when it has to remove the old vg's and lv's (with filesystems). Hope this helps, Maurice
Maurice, Thanks for the logs, I've filed a new bug 618641 for tracking the new issue you are seeing, and I'm closing this one, as the original problem is fixed. Regards, Hans