Dag Wieers wrote:
>>> How would I be able to see from anaconda what command is being run
>>> and what output it got back. I am not looking for a solution to
>>> this problem directly, I am looking for a way to make obvious what
>>> is going on from (during or after) the installation. If something
>>> was available to see exactly what happens, what decisions are
>>> being made and what programs are run (even without the output) it
>>> would positively affect bug-reports and help from the community
to >>> improve Anaconda.
...
> I'm worried about anaconda development in the sense that many people
> use it, but few people improve it. And anaconda is definitely
> something that could be improved wrt. debug output.
...
> I was not looking for interim solutions really, I know how I can fix
> this or work around it from a kickstart file. (Using %pre etc...)
I've been making similar suggestions on the kickstart list. So much
dialogue on both lists revolves around how to get information about
what is going on, correctly or incorrectly. 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. The user experience is of something primitive and broken (like a
long phone answering menu that abruptly disconnects you in the end)
when an install aborts after investing much time in it. I've done
many hundreds of RedHat installs over the last 5 years or so, but it
took 4 tries, from scratch, to get FC5-x86_64 installed on a new home
computer recently. Many folks strive for minimal %post scripts,
preferring to do their post-install configuration 'post-post-install',
because it is can be so hard to develop, and maintain, %post (and
%pre) scripts.
If it were possible to enable 'breakpoints' during anaconda's install
phase, possibly on error conditions, with a chance to interact, such
as attempt to query state, or manually run failed commands or work
around them otherwise, and then continue, it could save an enormous
amount of time iterating through install attempts. And why should it
be impossible to return to the end of the info gathering phase, with
'back' button opportunity from there, on errors during the install
phase (for non-kickstart installs)? Could anaconda provide a
'debugProblem' function that could be called from any interpreter
during %post (and perhaps %pre) scripts for kickstart installs, that
could display a passed string argument, and provide a shell prompt for
debugging and recovery, that on exiting, returned control to %post to
be able to continue? How else could anaconda be made more friendly,
and flexible?
-Ed
