The following was filed automatically by anaconda: anaconda 11.5.0.52 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/devicetree.py", line 616, in cmpActions ret = cmp(a1.device.partedPartition.number, File "/usr/lib/anaconda/storage/devicetree.py", line 659, in processActions self._actions.sort(cmp=cmpActions) File "/usr/lib/anaconda/storage/__init__.py", line 238, in doIt self.devicetree.processActions() File "/usr/lib/anaconda/packages.py", line 117, in turnOnFilesystems anaconda.id.storage.doIt() AttributeError: 'NoneType' object has no attribute 'number'
Created attachment 344064 [details] Attached traceback automatically from anaconda.
I tried this morning's rawhide images; I was previously able to install using this kickstart file a couple of days ago (11.5.0.51). Here's the disk portion; please let me know if I can provide any additional useful information. zerombr yes clearpart --all part raid.00 --asprimary --ondisk=sda --size 256 part raid.01 --asprimary --ondisk=sdb --size 256 part raid.02 --asprimary --ondisk=sdc --size 256 part raid.03 --asprimary --ondisk=sdd --size 256 part raid.10 --asprimary --ondisk=sda --size=32768 part raid.11 --asprimary --ondisk=sdb --size=32768 part raid.12 --asprimary --ondisk=sdc --size=32768 part raid.13 --asprimary --ondisk=sdd --size=32768 part raid.20 --size 100000 --grow part raid.21 --size 100000 --grow part raid.22 --size 100000 --grow part raid.23 --size 100000 --grow raid /boot --level=1 --device=md0 raid.00 raid.01 raid.02 raid.03 raid swap --level=1 --device=md1 raid.10 raid.11 raid.12 raid.13 raid pv.0 --level=10 --device=md2 raid.20 raid.21 raid.22 raid.23 volgroup vg0 pv.0 logvol /usr --fstype ext3 --name=usr --vgname=vg0 --size=10000 logvol /scratch --fstype ext3 --name=scratch --vgname=vg0 --size=1024 logvol /tmp --fstype ext3 --name=tmp --vgname=vg0 --size=4096 logvol / --fstype ext3 --name=root --vgname=vg0 --size=1024 logvol /var --fstype ext3 --name=var --vgname=vg0 --size=8192 Please
Seems that software RAID isn't implicated; it seems any use of LVM will cause the failure. This is, I believe, the minimal bootable system that uses LVM: zerombr clearpart --all part /boot --fstype ext3 --size 256 part pv.0 --size=1000000 --grow volgroup vg0 pv.0 logvol / --fstype ext3 --name=root --vgname=vg0 --size=102400 The backtrace is unchanged.
Created attachment 344202 [details] Attached traceback automatically from anaconda.
Able to consistently reproduce by doing : 1) A kickstart install containing ... autopart clearpart --all --initlabel 2) Followed by a RAID6 kickstart install containing ... clearpart --all --initlabel part /boot --asprimary --fstype="ext3" --size=200 --label=BOOT part swap --fstype="swap" --recommended --label=SWAP part /multi-stage --fstype="ext3" --size=100 --label=MULTISTAGE part raid.01 --grow --size=2048 part raid.02 --grow --size=2048 part raid.03 --grow --size=2048 part raid.04 --grow --size=2048 raid / --device=0 --fstype="ext3" --level=RAID6 raid.01 raid.02 raid.03 raid.04
*** Bug 500770 has been marked as a duplicate of this bug. ***
Note: Repeating step#2 in comment#5 manually (without kickstart) does not seem to trigger the failure.
This should be fixed in the next build of anaconda.
I can verify that doing a git clone of the current anaconda tree and stuffing the contents of the 'storage' directory into an updates.img gets things installing fine for me with the RAID/LVM kickstart from comment #2.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 351283 [details] Attached traceback automatically from anaconda.