John Summerfield wrote:
Ed Brown wrote:
A 'debug mode' framework
would not only improve the ability to quickly troubleshoot, it could
also be used to provide a recovery capacity that is sorely lacking now.
But I'm sure there's a python debugger, and Anaconda does have test (I
don't recall what that does tho) and autostep modes: this allows a
measure of stepping through the install.
And, there are some undocumented switches; see the source for details.
Thank you for the suggestions. The undocumented switches are
interesting, I'd like to find out more about them. The python
debugger might be well-suited for python developers, but it's not
really what I'm looking for, nor is autostep mode. Basically what I'm
asking for is improved fault tolerance, a more flexible approach, so
problems, and they are simply inevitable, aren't as often fatal, and
don't consume so much of an installer's time.
If you'll permit an analogy - currently anaconda is something like a
train: you spend a little time in the station, when it leaves, you
either get where you're going, or you derail and walk back to the
station to catch another train. What if all applications behaved like
this, forcing you to reboot to be able to restart the application?
For manual installs, why isn't it possible to go back to
question/answers once an install has started? Who hasn't run into a
problem, especially with %pre and %post scripts, that could have been
fixed without starting completely over, if they'd had the opportunity
to see what the error was, change something locally or remotely, and
retry/resume? Who's had to start over and over to determine what a
problem is or to test fixes?
If an opensuse install aborts, you get extensive menus and options:
all kinds of system info available, manipulation of drivers and
settings and boot options, and you can choose to go into a rescue
mode, attempt to boot from the hard drive, or go right back to
install/update: brilliant, helpful, friendly, fast...
My own kickstart scripts allow for one-time, runtime, changes to the
kickstart file itself in %pre. In %post, they stop and provide a
shell prompt when there are errors I don't want to ignore. Maybe that
yum configuration file I'm trying to download isn't available for some
reason, well ssh over and fix that, or retrieve it elsewhere, exit,
and continue with the next thing... You can stop the train, if you
will, AND get back on, to continue your journey. I can't begin to say
how much time and frustration this has saved over the last couple of
years.
Greater flexibility and error handling/recovery is entirely realistic,
but it needs to be generalized and incorporated and done right for
different install modes (text or graphical), available to any
interpreter in %post/%pre scripts, and possibly even during the
os-install part of anaconda. I wish I could offer python code instead
of suggestions, and I'm sure there are a lot of other priorities for
ananconda developers with work on RHEL5 in high gear, but maybe there
are some things that could be implemented more easily than others, if
there is any agreement about a need for improvements.
thanks,
Ed Brown, RHCE
