Bug 204799 - redirected anaconda errors to F5 console don't work when interactive
Summary: redirected anaconda errors to F5 console don't work when interactive
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Chris Lumens
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-31 17:01 UTC by Joshua Jensen
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-09-25 18:52:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Joshua Jensen 2006-08-31 17:01:53 UTC
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

Comment 1 Chris Lumens 2006-09-15 14:07:20 UTC
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?

Comment 2 Joshua Jensen 2006-09-16 22:00:03 UTC
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.

Comment 3 Chris Lumens 2006-09-20 18:18:11 UTC
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.

Comment 4 Joshua Jensen 2006-09-20 21:31:02 UTC
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 :-(


Comment 5 Chris Lumens 2006-09-25 18:52:48 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.