Bug 500932 - Install aborts - 'NoneType' object has no attribute 'number'
Install aborts - 'NoneType' object has no attribute 'number'
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: 500770 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-05-14 19:26 EDT by Jason Tibbitts
Modified: 2009-07-10 13:23 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-25 15:29:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Attached traceback automatically from anaconda. (267.15 KB, text/plain)
2009-05-14 19:26 EDT, Jason Tibbitts
no flags Details
Attached traceback automatically from anaconda. (87.93 KB, text/plain)
2009-05-15 12:54 EDT, James Laska
no flags Details
Attached traceback automatically from anaconda. (350.39 KB, text/plain)
2009-07-10 13:23 EDT, George Beshers
no flags Details

  None (edit)
Description Jason Tibbitts 2009-05-14 19:26:23 EDT
The following was filed automatically by anaconda:
anaconda 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
  File "/usr/lib/anaconda/storage/__init__.py", line 238, in doIt
  File "/usr/lib/anaconda/packages.py", line 117, in turnOnFilesystems
AttributeError: 'NoneType' object has no attribute 'number'
Comment 1 Jason Tibbitts 2009-05-14 19:26:28 EDT
Created attachment 344064 [details]
Attached traceback automatically from anaconda.
Comment 2 Jason Tibbitts 2009-05-14 19:30:33 EDT
I tried this morning's rawhide images; I was previously able to install using this kickstart file a couple of days ago (  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

Comment 3 Jason Tibbitts 2009-05-14 21:00:09 EDT
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:

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.
Comment 4 James Laska 2009-05-15 12:54:11 EDT
Created attachment 344202 [details]
Attached traceback automatically from anaconda.
Comment 5 James Laska 2009-05-15 13:13:20 EDT
Able to consistently reproduce by doing :

 1) A kickstart install containing ...

    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
Comment 6 Chris Lumens 2009-05-15 14:30:09 EDT
*** Bug 500770 has been marked as a duplicate of this bug. ***
Comment 7 James Laska 2009-05-15 14:49:09 EDT
Note: Repeating step#2 in comment#5 manually (without kickstart) does not seem to trigger the failure.
Comment 8 Chris Lumens 2009-05-15 16:38:19 EDT
This should be fixed in the next build of anaconda.
Comment 9 Jason Tibbitts 2009-05-16 17:14:51 EDT
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.
Comment 10 Bug Zapper 2009-06-09 11:50:35 EDT
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:
Comment 11 George Beshers 2009-07-10 13:23:50 EDT
Created attachment 351283 [details]
Attached traceback automatically from anaconda.

Note You need to log in before you can comment on or make changes to this bug.