On 8/31/06, Ed Brown <ebrown@xxxxxxxx> wrote:
A 'debug mode' or error-handling framework
for %pre and %post scripts like I'm suggesting, would allow for far
easier development, and a more robust recovery capability, and allow
%post to be more fully utilized for what is was intended for, instead
of resorting to post-post scripts.
How would you build such a framework though? I'm not a developer, so
I may be a bit limited in my thinking. I can think of 2 ways of accomplishing
this 'debug mode'.
1. Build the interpreters into anaconda. This would allow ananconda itself to
read the %pre and %post sections rather than handing it off to the external
interpreter and do the syntax checking and error-handling.However , this would
make the anaconda code much larger than it should be and probably very
unmanagable. I also imagine that this would start limiting the options that we
have for interpreters because we may not have solid dedicated contributers that
would even want to jump into every possible interpreter to make it available.
Maybe we would, just not sure on that one.
2. Ask the maintainers of the interpreters' to build in this 'debug mode' that would
probably only be useful in kickstarts. I'm not sure how willing those maintainers
would be to add such a feature with such limited use. They would probably be
more inclined to help if a patch was submited.
IMHO, the Crtl-Alt-F2 tty is the debug mode. I too run a complex environment
that utilizes a robust %post section as well as a first boot "post-post" install. I use
both because it makes sense in my environment. I have been able to do all of my
%post testing and debuging from the F2 tty. The shell that is provided is the exact environment that the %post runs in. A chroot /mnt/sysimage will give you the default %post. Not using the chroot command is the same as %post --nochroot, etc...
Any other ideas, on how the debug mode/framework could live and work inside
anaconda?
-Jeremy, RHCE
