Hide Forgot
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
Created attachment 107593 [details] ks.cfg
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: 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?
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?
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.