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
In your kickstart config file, add
exec < /dev/console > /dev/console at the top of the %pre and/or %post sections. For example:
%post 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.
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):
%post ( 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.