Skip to content

Redirecting kickstart %pre/%post over serial console

TL;DR: To push output over console exec < /dev/console > /dev/console at the top of your %pre and/or %post sections of your kickstart config.

Debugging %pre & %post scripts in kickstart is difficult if you’re working on remote systems

I was running into a problem with one of the sections of my %post section, but since I was working on a remote system (over a redirected /dev/ttyS1, in this case) I was unable to see exactly what was wrong, since the only out put would be:

Running post-install scripts

This was followed by a long period (over an hour for one failure scenario) of dead air until whatever was hanging had timed out. This both left the newly-kickstarted system in an indeterminate state, and almost as importantly was certainly wasting a lot of time.

While I could let it fail and then investigate the logs post-install, that was far from ideal, and did nothing to solve the time waste.  So, in order to see what’s going on (and what’s hanging), we need to push the %post output to the console.

Let’s get to it

One way:
In your kickstart config file, add exec < /dev/console > /dev/console at the top of the %pre and/or %post sections.  For example:

exec < /dev/console > /dev/console
echo "# Running Post Configuration   #"
#....Do stuff....
echo "End of post-install steps"

Pro: no bothering to wrap + tee, it all streams regardless
Con: None, really.

Alternative way:
In your kickstart config file, wrap your %pre/%post script in (), bundle STDERR to STDOUT, then tee to /dev/console at the bottom. Example (including double-tee so it’s also dumping to a log file):

echo "# Running Post Configuration   #"
#....Do stuff....
echo "End of post-install steps"
) 2>&1 | /usr/bin/tee /root/post_install.log | tee /dev/console

Pro: Possibly more robust for purposes of other redirects / tees (to logs, etc).
Con: more steps / less lazy

Now, during your %pre or %post script, anything that normally prints to the screen (STDOUT) or STDERR will stream to your console.  This allows you to see what is going on.  Add extra debug lines via echo if you’re still not able to zero in on your problem (e.g. echo "Now trying to Foo /dev/bar")


The end-result differences are minimal, but I prefer to just put the exec < /dev/console > /dev/console at the top of the section and be done with it. Doing so doesn’t prevent also wrapping & tee‘ing the script to dump it to a log file, which I take advantage of in the production kickstart configuration.


One Comment

  1. Marian Csontos

    %post –log=/dev/console may work too. At least on RHEL6.2 it does.

    Posted on 25-May-11 at 05:25 | Permalink