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)
422, in run File
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:
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
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
I have the following which I will attempt to attach to this bug report:
anacdump.txt anaconda.bug.ks.cfg syslog
Created attachment 107593 [details]
Created attachment 107594 [details]
from anaconda's own crash dump
Created attachment 107595 [details]
from anaconda's own crash dump
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 :/
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:
I think it is: can you confirm that using NON-anonymous ftp in this fashion
works for you?
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:
I'm thinking that the non-anonymous ftp login is not being correctly
supported by kickstart.
Is that that the case?
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.
Closing based on my previous comment. Please use Issue Tracker if you need this
fix backported to RHEL3.