Hide Forgot
Description of problem: Had an anaconda/bootloader traceback... which shows up on Alt-F5 console. Strange to output anaconda's error there, but it very much doesn't work when it is anaconda's *interactive* "there was an error, would you like to debug" message. I have to switch to Alt-F1, press "tab" then "enter", switch back to Alt-F5 to make sure I'm now in debug mode... then for every character I want to enter must go back to Alt-F1 console, enter it, then switch back to F5 console to see the results. This really really really sucks. Perhaps redirecting anaconda errors to F5 isn't that good of an idea? Or if you want to stick with that, perhaps Anaconda should leave an error message up on F1 console, then switch getting its input from the F5 console so that debugging is practical. Thoughts? Version-Release number of selected component (if applicable): RHEL4 U4 x86_64 AS
The only things that should be showing up on tty5 are the output from disk and bootloader commands that we exec from anaconda. I believe what may be happening here is that because of the location where the traceback occurred, stdout and stderr are set to tty5, so that's where the debugging output is getting sent. Perhaps we should make sure to set up stdout and stderr when you enter the debugger. Would it be possible for you to attach the traceback you're getting, and preferably what's on tty1 and tty5 at the time you enter debug mode?
I agree, it seems that is what is happening. From memory it is when anaconda is trying to run grub... but grub (and rhpl) aren't installed (this actually happened when I was filing BZ # 204797). tty1 is showing the "Installing bootloader" message, which just hangs forever. tty5 shows a badly mangled ncurses "there was an error, would you like to debug?" screen. tty1 would accept the input, tty5 would actually show the input and debugging output. You could reproduce this with a kickstart using "%packages --nobase", without specifying rhpl or grub to be installed.
Would it be possible for you to test with FC6t3 or with RHEL5 beta? We've changed a lot of code in this area for this release, so I believe there's a high possibility this is fixed. I've personally rewritten a bunch of the exception handling code and process execution code. In my brief tests here, I was able to cause exceptions by running programs that were not installed, but the debugging worked as it's supposed to.
It would take a bit to set it up... and from what you've told me you have made anaconda manually install the packages (in this case grub and rhpl) that anaconda was missing.... so how could I know cause anaconda to go to debug mode? aka, you've made anaconda too smart in FC6/RHEL5 to recreate this now :-) Also, this is very much broken in RHEL4 U4. So really it should be fixed there :-(
This should be fixed in RHEL5 for a couple reasons - first, we've made anaconda a bit smarter about installing programs it's going to need installed. Second, we actually do reset the file descriptors when entering the debugger. The fix for this will be in the next major release of RHEL. If you require this fix in an update release of RHEL4, please talk to your support representative who will raise the issue through the appropriate channels.