Red Hat Bugzilla – Bug 240367
Make %include work anywhere in the kickstart
Last modified: 2007-11-30 17:07:44 EST
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): pykickstart-0.43-1.el5
What do your kickstart file and included file contain?
Created attachment 154870 [details] test kickstart
Comment on attachment 154870 [details] test kickstart A testing kickstart we are working with for RHEL 5.
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 work.
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.
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.