Bug 240367 - Make %include work anywhere in the kickstart
Make %include work anywhere in the kickstart
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pykickstart (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Depends On:
  Show dependency treegraph
Reported: 2007-05-16 15:12 EDT by Jack Neely
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-30 11:07:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test kickstart (11.98 KB, text/plain)
2007-05-16 16:39 EDT, Jack Neely
no flags Details

  None (edit)
Description Jack Neely 2007-05-16 15:12:00 EDT
Description of problem:
The %include directive only works if it is the first %-directive.  It does not
work if its after %packages, %post, etc.  It would be great if this directive
worked from any location in the kickstart file.

From looking at pykickstart it looks like the parser's state is not reset
properly when the %include directive causes the recursive call to
self.readKickstart (args[1]).

Version-Release number of selected component (if applicable):
Comment 1 Chris Lumens 2007-05-16 15:43:07 EDT
What do your kickstart file and included file contain?
Comment 2 Jack Neely 2007-05-16 16:39:13 EDT
Created attachment 154870 [details]
test kickstart
Comment 3 Jack Neely 2007-05-16 16:40:14 EDT
Comment on attachment 154870 [details]
test kickstart

A testing kickstart we are working with for RHEL 5.
Comment 4 Chris Lumens 2007-05-16 16:58:30 EDT
It looks like you have %pre scripts that write out a file with your partitioning
scheme, and that file is then included in the middle of your kickstart file. 
The problem here isn't that %include doesn't work, but that you can't include
kickstart commands once you've done a %packages, %pre, %post, etc.  Those sorts
of commands need to be before any of these other sections.  This is due to the
unfortunate very old decision to not have any sort of end marker for kickstart
file sections, so sections are assumed to go on until the next one begins. 
There's no marker for the command section so you can't have a second one, and
included files could contain chunks of scripts to run.  So we're kind of stuck
with it.

I bet if you move your %include /tmp/partitioning to before %packages, it would
Comment 5 Jack Neely 2007-05-22 10:27:41 EDT
Indeed, placing %include above %packages does work.

However, I was under the impression that the FSM in pykickstart would cure some
of these annoying parsing behaviors.  Explicitly this one.

Looking at the code we have a simple FSM to populate a data structure.  To
handle includes better using a pushdown automaton and an additional state should
suffice.  Before we recurse to handle the include file we push the current state
on the stack and reset the state to STATE_COMMANDS.  When the function returns
we pop off the saved state.  If its STATE_COMMANDS we continue, otherwise we go
to the new state to handle any input before the next section starts.

Perhaps that's something I can do after I unbury myself from work.  
Comment 6 Chris Lumens 2007-05-24 09:56:50 EDT
It's not so much a problem with the parser as with the definition of the
kickstart file format.  An included file can contain anything - kickstart
commands, a complete script, some packages, only a couple lines of a script,
etc.  In your kickstart file above, what if there were a package named
"autopart" or "logvol" or whatever?  Yes, it's a bit of a stretch, but there's
certainly no way of knowing.  With putting an %include after a %pre or %post,
it's even more difficult since the script can use any interpreter you want.

If there were a %commands section header, or if scripts and %packages had some
sort of end marker, we could very easily allow commands to take place multiple
times in the file.  However with the current state of things, we just have to
assume that once any of the other section headers are seen, you are done
specifying commands.

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