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

Re: [K12OSN] Rdesktop Fails after Update

Julius Szelagiewicz wrote:
On Wed, 25 Apr 2007, [ISO-8859-1] "Terrell Prud� Jr." wrote:

Hmm...I've got to head to work, but I'll see if I can find anything out
Googling this evening when I get some time.  This definitely should not
be happening.

Hey, waitasec.  Not crashing from the console, but it is through the
terminals, eh?  In that case, we might be seeing an X11 (on the client)
issue.  Back when I was running UltraSPARC thin clients, I was using a
release-candidate set of binaries of XFree86 4.4 (just before the Big
Split).  See, I had Red Hat Linux 6.2 installed on the Ultra 5 boxes'
hard disks, which uses XFree86 3.3.6.  The LTSP X11 binaries in
/opt/ltsp/sparc were XFree86 4.4rc. TuxType and TuxMath would
intermittently crash on me when TFTP-booting in normal LTSP style.
However, when I booted RHL 6.2 and had XFree86 3.3.6 do an XDMCP query,
then TuxMath ran fine, but TuxType would simply not run at all due to
the ancient X11 version.

Maybe this is what's biting you as well with rdesktop.

Do you GNU!?
Microsoft Free since 2003 <http://www.gnu.org/>--the ultimate antivirus

k12ltsp wrote:
Hello there!

Thank you for the suggestion! I have moved the old rdesktop and compiled a
new version using the source code at the website you provided. I did
notice some improvements, such as it defaulting to a higher color depth.

Unfortunately, the issue still follows. There is a segmentation fault that
happens when we attempt to login. It's also worth noting that the issue
does NOT occur when using rdesktop from console. It only occurs when
launched through a terminal.

"Support list for open source software in schools." <k12osn redhat com>

Hmm...I vaguely recall seeing something like that a year and a half or so
back.  Here's what I did.  Try downloading the rdesktop source code and
installing it (it should install into /usr/local by default).  Then, try
renaming /usr/bin/rdesktop to, say, /usr/bin/rdesktop.orig, and then
symlink your new rdesktop to /usr/bin/rdesktop.  What we're trying to do
here is see if the rdesktop executable got FUBAR'd or if there's some
other library that it's looking for but can't find.  When you compile it,
it will compile specifically for your libraries and shouldn't have any

	I am running updated to the gills version K12 6 on 3 servers and a
	The issue is new - it came after the yum update a few days ago,
but I became aware of it only a few hours ago.
	The segmentation fault happens on terminals and on the laptop,
that is, on the console too.

For you, it's happening on the console as well?  Hmm...that *is* interesting.  What version of rdesktop are you running?  Could it be that yum update also updated rdesktop to 1.5, and 1.5 might itself be buggy?  A couple of other folks have pointed out that "downgrading" from rdesktop 1.5 to 1.4.x seems to make the problem go away.  I do happen to be using 1.4.1.

Do you GNU!?
Microsoft Free since 2003--the ultimate antivirus protection!

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