Bug 500932
| Summary: | Install aborts - 'NoneType' object has no attribute 'number' | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jason Tibbitts <j> | ||||||||
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 11 | CC: | anaconda-maint-list, gbeshers, jlaska, lmacken, rmaximo, vanmeeuwen+fedora | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | anaconda_trace_hash:9e79ee07a18d1ab72cda70a3af60e3e2fe49296e8ae3679daef52fbf54432dbc | ||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2009-06-25 19:29:09 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
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.
|
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'