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
