[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

anaconda debugging and recovery (was Re: RFI: How to debug a particular problem with grub-install)



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]