Red Hat Bugzilla – Bug 117344
Kudzu leaves xterms in bad state
Last modified: 2013-03-08 11:04:44 EST
Kudzu leaves xterms in a bad state
Version-Release number of selected component (if applicable):
Kudzu in RHEL 3 U1
If the hardware configuration changes and Linux Kudzu runs during
boot and the console is being viewed, Kudzu leaves the xterm in a
fixed 24x80 screen size regardless of the original xterm screen
Steps to Reproduce:
Start an xterm via Reflection X on a PC or on an HP-UX workstation.
View a Linux console when it boots and runs Kudzu. After Kudzu
completes, the xterm is stuck at 24x80 and is no longer usable.
Contact Greg Albrecht <firstname.lastname@example.org> for
Does this happen with other text-based config tools?
> I have not used any other text-based config tools, so
> I don't know. Suggest some to try and I can do so.
> This used to occur during the initial Linux install. I
> can't remember whether it still occurs on an install or
> not. I can retry an install and pass that information
> along. For me, the Kudzu issue occurs more frequently
> due to hardware reconfigurations and Linux reboots.
Is there a way to add Greg (email@example.com)
to the CC: list? I tried the "Add CC:" box, but it
didn't work (maybe because Greg doesn't have a Bugzilla
Greg does need to create a Bugzilla account, and to have that account
added to the CC list after it is created.
> Suggest some to try and I can do so.
What other text-based config tool should we try?
authconfig, system-config-network-tui, mouseconfig, timeconfig, etc.
Is the xterm not resizable after calling kudzu?
If it's resizable (but simply resized to 24x80),
this reminds me of a Debian report last year which
was explained by an application calling tset
(which sets the window size).
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received the feedback we
requested, we will assume the problem was not reproduceable or has been fixed in
a later update for this product.
Users who have experienced this problem are encouraged to upgrade to the latest
update release, and if this issue is still reproduceable, please contact the Red
Hat Global Support Services page on our website for technical support options:
Created attachment 198821 [details]
script of timeconfig
Sorry, I poked Greg for more information in September 2005, but never
followed up on it.
I just tried "timeconfig" myself on RHEL5, and the problem does occur
on a console (ttyS0) connection, but not on an ssh connection.
This typescript shows timeconfig running on the console. This starts in
a 72x80 xterm, and after timeconfig exits, only 24x80 of the xterm is
That's expected (from reading the attachment):
the program sets the scrolling margins and doesn't reset them.
So, that would imply a newt bug.
Reassigning to newt. The chances of this being fixed for RHEL 3 at this point
are pretty nil, though. Feel free to move to RHEL 5 if it still happens there.
I don't care about RHEL 3 anymore. My attachment in comment #9 is from
RHEL 5, so the problem still exists there. I tried to change the version
to 5 and hardware to "all" above.
Newt uses slang. Unfortunately, I'm not sure there is anything we can do in
slang to prevent this.
When terminal doesn't have correct window size, slang and ncurses applications
will use wrong values and this will cause the problem.
Which program is used for serial communication?
Typical scenario is one of these:
sh -- xterm -- bash -- telnet
sh -- xterm -- bash -- ssh
The telnet or ssh connection is to an HP management processor (MP). One thing
the MP can do is connect you to a ttyS serial device that is the console.
I think newt/slang is using the xterm escape sequence "ESC[1;24r" to set the
scrolling region to lines 1-24. On exit, could it use "ESC[;r" to set the
scrolling region to the full size of the window? Or maybe it could
use "ESC[18;;t", which looks like it should report the size of the text area?
Newt/slang is using an xterm escape sequence to set the scrolling margins. Is
there a similar sequence it could use to read the current margins, so it could
restore them on exit?
On exit, it should use "ESC[r" to reset the scrolling
margins. Normal practice is to reset them after the
scrolling operation is no longer needed.
Ok, I was assuming that if ncurses don't use it, there is a reason why it
shouldn't be used.
ncurses does use the scrolling regions, but the sequence of operations
appears to be different...
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. This request will
be reviewed for a future Red Hat Enterprise Linux release.
We are sorry, but at this point in the RHEL5 release cycle, where only critical and security bugs are fixed, this bug is unlikely to be addressed.