Bug 141279 - anaconda python crashes during partitioning
Summary: anaconda python crashes during partitioning
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Mike McLean
Depends On:
Blocks: 161467
TreeView+ depends on / blocked
Reported: 2004-11-30 01:06 UTC by Rick Greer
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2005-07-26 15:18:50 UTC

Attachments (Terms of Use)
ks.cfg (3.66 KB, text/plain)
2004-11-30 01:13 UTC, Rick Greer
no flags Details
from anaconda's own crash dump (73.79 KB, text/plain)
2004-11-30 01:14 UTC, Rick Greer
no flags Details
from anaconda's own crash dump (18.11 KB, text/plain)
2004-11-30 01:15 UTC, Rick Greer
no flags Details

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)
"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
line 262, in currentStep
line 157, in gotoNext
line 225, in moveStep
line 1337, in doAutoPartition
line 990, in doPartitioning
line 961, in processPartitioning
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.

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]

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@

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:

url --url=ftp://myftp0:password@

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.

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