Bug 141279

Summary: anaconda python crashes during partitioning
Product: Red Hat Enterprise Linux 3 Reporter: Rick Greer <rxga>
Component: anacondaAssignee: Chris Lumens <clumens>
Status: CLOSED RAWHIDE QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: nobody+pnasrat
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-07-26 15:18:50 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:
Bug Depends On:    
Bug Blocks: 161467    
Attachments:
Description Flags
ks.cfg
none
from anaconda's own crash dump
none
from anaconda's own crash dump none

Description Rick Greer 2004-11-30 01:06:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; HP-UX ia64; en-US; rv:1.4) Gecko/20031022

Description of problem:
Doing a kickstart ftp install using slightly modified anaconda-ks.cfg
generated from a previous install -- with the exception of three
commented (generated part/raid) lines (which caused another 
mysterious error), all of the part/raid lines were generated
by anaconda and so we see that it cannot handle its own output.
Here is how the bug was announced to me:

Traceback (most recent call last):
    File "/usr/bin/anaconda", line 1081 in ?
        intf.run(id, dispatch, configFileData)
    File
"usr/src/build/441161-i386/install//usr/lib/anaconda/text.py", line
422, in run File

  File "/usr/src/build/441161-i386/install//usr/lib/anaconda/text.py",
line 422, in run
  File
"/usr/src/build/441161-i386/install//usr/lib/anaconda/dispatch.py",
line 262, in currentStep
  File
"/usr/src/build/441161-i386/install//usr/lib/anaconda/dispatch.py",
line 157, in gotoNext
  File
"/usr/src/build/441161-i386/install//usr/lib/anaconda/dispatch.py",
line 225, in moveStep
  File
"/usr/src/build/441161-i386/install//usr/lib/anaconda/autopart.py",
line 1337, in doAutoPartition
  File
"/usr/src/build/441161-i386/install//usr/lib/anaconda/autopart.py",
line 990, in doPartitioning
  File
"/usr/src/build/441161-i386/install//usr/lib/anaconda/autopart.py",
line 961, in processPartitioning
  File
"/usr/src/build/441161-i386/install//usr/lib/anaconda/partRequests.py",
line 619, in getActualSize
AttributeError: 'NoneType' object has no attribute 'getActualSize'

Local variables in innermost frame:
member: 1
smallest: None
nummembers: 2
sum: 0
req: None
self: RAID Request -- mountpoint: None  uniqueID: 34
  type: ext3  format: 0  badblocks: None
  raidlevel: RAID1  raidspares: 0
  raidmembers: [1, 13]
diskset: <partedUtils.DiskSet instance at 0x96017f4>
partitions: <partitions.Partitions instance at 0x960282c>


Version-Release number of selected component (if applicable):
from RHEL 3 Update 3

How reproducible:
Didn't try

Steps to Reproduce:
1.setup an ftp install server for RHEL 3 Update 3
which by the way works fine 
2.use RHEL CD #1 plus a floppy with the attached ks.cfg to try 
and do a kickstart.  The ftp login fails, for reasons unknown to me,
so I use the same information to manually login and then 
the disk partitioning step fails as outlined above.
3.
    

Actual Results:  see description

Expected Results:  a successful installation

Additional info:

I have the following which I will attempt to attach to this bug report:

anacdump.txt  anaconda.bug.ks.cfg  syslog

Comment 1 Rick Greer 2004-11-30 01:13:22 UTC
Created attachment 107593 [details]
ks.cfg

Comment 2 Rick Greer 2004-11-30 01:14:16 UTC
Created attachment 107594 [details]
from anaconda's own crash dump

Comment 3 Rick Greer 2004-11-30 01:15:06 UTC
Created attachment 107595 [details]
from anaconda's own crash dump

Comment 4 Jeremy Katz 2004-12-01 19:07:35 UTC
Is this reproducable?

This is something that has been sporadically reported, yet I have yet to get a
reproducable case locally to debug it with :/

Comment 5 Rick Greer 2004-12-06 22:10:23 UTC
I have not checked to see if it is reproducible.
I need to use this machine.  If I were to try to reproduce it, since I would be
doing an install, if it were not reproducible, then it would wipe out my
configuration.  And if I were to reproduce it, what would you do differently?
You would still have to reproduce it locally because at the least, my machine
is not available for indefinite periods of remote debugging.  I think you should
try and reproduce it -- I don't see how it matters whether I do or not.
I sent in all the information that was requested of me.

By the way, I could never get the ftp login to work with kickstart
even though I used the same information to login manually.  Would you please
confirm that this is the correct syntax:

install --url=ftp://myftp0:password@192.168.1.4/export/RHEL

I think it is:  can you confirm that using NON-anonymous ftp in this fashion
works for you?

Comment 6 Rick Greer 2004-12-06 22:20:14 UTC
OOPS -- actually, I do know that the --url has to be on a separate line.
So, here is what I actually used as confirmed by the files I sent in:

install
url --url=ftp://myftp0:password@192.168.26.68/export/RHEL

I'm thinking that the non-anonymous ftp login is not being correctly
supported by kickstart.
Is that that the case?

Comment 7 Chris Lumens 2005-05-09 14:25:51 UTC
I believe I've fixed this bug on cvs head (as in, for FC4).  If you need the fix
to be backported to RHEL3, you'll need to take it through Issue Tracker so that
it can get placed for the proper update release, etc.

Comment 8 Chris Lumens 2005-05-26 18:32:28 UTC
Closing based on my previous comment.  Please use Issue Tracker if you need this
fix backported to RHEL3.