error handling in %post

[Edward F. Brown]

On Fri, September 1, 2006 3:51 am, Phil Bettinson wrote:
> Jeremy Lyon wrote:
>> How would you build such a framework though?
> It might be possible to simply run a shell, and connect it's output to a
> TTY, as well as it's input.

Right, and that was the suggestion I made to the question that spawned
this thread.  For text-mode install, shell interpreter, you can switch
tty's for %post, test for errors, and open a subshell:

%post
chvt 3
exec < /dev/tty3 > /dev/tty3 2>/dev/tty3
...some commands...
... some-command that deserves an error check...
if [ $? -ne 0 ]; then
  echo 'some-command failed, check it out...'
  sh
fi
...more commands

There you can work it locally, maybe fix something remotely, and when you
exit the subshell, the %post script continues.  Likely you can finish the
install without iterating ad nauseum from a cold start, and subsequently
fix your script, if necessary.

Jeremy's questions help me see the problem with a more general solution or
'error-handling framework'.  Anaconda can't know about error conditions
within the interpreter.  But what if it provided a hook: you still have to
check for errors within %post, but if you could then pass a string to an
anaconda-provided function that would display the message and provide a
shell-prompt window. This could work for text or graphical mode, with any
interpreter, and would not require the explicit tty switch in %post.
Obviously I'm not a python or anaconda developer either, but could this be
hard to implement?  Turn it off (function call ignored), (or conversely,
on), with a kickstart option.

I know, from using the less general method above for a couple of years,
that having this capability saves time developing scripts, provides a
preciously valuable runtime recovery capacity, and provides confidence in
being able to use %post for just about every kind of post install
configuration.  It just needs to be made easier, more general, a
documented kickstart no-brainer. Other ideas?

thanks,
Ed, RHCE