Bug 149690

Summary: kickstart.py removes /tmp/ks.cfg.new when %installclass used
Product: Red Hat Enterprise Linux 3 Reporter: David Lehman <dlehman>
Component: anacondaAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED WONTFIX QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-27 17:20:05 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:
Attachments:
Description Flags
Don't remove /tmp/ks.cfg.new none

Description David Lehman 2005-02-25 10:26:22 UTC 
Created attachment 111421 [details]
Don't remove /tmp/ks.cfg.new
Comment 1 David Lehman 2005-02-25 10:26:22 UTC 
Description of problem:
When defining a custom installclass in the ks.cfg, the Kickstart method unlinks
the ks.cfg.new long before setInstallData (hence also readKickstart) is called.
This, of course, leads to a traceback when readKickstart tries to open the
long-gone file.

Version-Release number of selected component (if applicable):
anaconda-9.1.4.1-1.RHEL

How reproducible:
Always

Steps to Reproduce:
1. define a basic subclass of KickstartBase using %installclass in ks.cfg
2. try to use it
3.
  
Actual results:
Traceback - I can get the exact traceback on request, but all you need to do is
look at the code and you'll see it.

Expected results:
No traceback

Additional info:
Comment 2 Jeremy Katz 2005-03-14 16:57:27 UTC 
FWIW, I wouldn't recommend counting on this functionality.  It's undocumented
from what I remember and very likely to go away (I know for a fact that it's
never tested :)