From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Description of problem:
(This bug report is probably going to be a bit vague, but I'll provide
more information in additional comments.)
I have a VNC server running Mandrake 10.0 Official, but
vnc-server-4.0-5 (from FC2 errata), installed using --nodeps. I am
able to connect to and use this server just fine from most clients,
including any RHEL 3 U3 clients. However, if I upgrade to U4 beta via
up2date, or if I perform a fresh installation of U4 beta, then the vnc
client freezes (after asking for my password but before it gets to
display stuff from the remote computer).
I'm not sure whether to file this against vnc, or against
distribution. The strange thing is, I can install the RHEL 3U4 beta
vnc and/or kernel packages on what is otherwise a 3U3 installation,
and 3U3 will keep working. Likewise, I can downgrade a 3U4 beta
installation's kernel and vnc packages to the 3U3 versions, and that
3U4 beta install will continue to fail. (If the component isn't really
vnc, then I need to figure out what the real guilty party is...)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install (or upgrade to) RHEL 3 U4 beta.
2. Boot into the installed system, do all the firstboot stuff, and log
in graphically as a normal user.
3. In a terminal, run: "vncviewer 192.168.0.2:1" (or whatever the
server's address is)
Actual Results: vnc prompts for password; upon successful password
entry, the client just freezes
Expected Results: vnc prompts for password; upon successful password
entry, it shows a window with the screen of the other computer (this
is what happens with RHEL 3 U3)
If I install vnc-4.0-5 on RHEL 3 U4 beta, then even that version of
vnc freezes. I'll now try to find out what's triggering the problem.
I'm not sure what the guilty component is, but it's not glibc,
XFree86, rpm, libstdc++, or up2date. I just figured out that the
problem only happens under GNOME, not KDE or TWM. Also, once the
guilty package is installed, I have to log out and back in to make the
I'm still working on this, so hopefully I'll make more progress in the
next few hours.
Ok, I figured out where the breakage appears to be coming from.
Breaks vncviewer: metacity-2.4.55-7.11
If I take a RHEL 3U4 beta installation and I downgrade metacity to the
3U3 version, everything works again...
BTW, here's how I found this. If I do the following:
<press Control-Alt-F1 so I have a text console>
X :1 &
<wait for X to start, then press Control-Alt-F1 again>
Then vncviewer works properly. If the U4 beta metacity is installed,
then the above sequence of steps, with "twm" replaced by "metacity",
results in vncviewer not working.
Also, FWIW, this is the output of vncviewer (whether it succeeds in
showing a window or simply stands there doing nothing instead).
VNC viewer for X version 4.0b4 - built Sep 6 2004 13:13:55
Copyright (C) 2002-2003 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Sat Nov 6 09:06:09 2004
CConn: connected to host 192.168.0.2 port 5901
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.7
Sat Nov 6 09:06:10 2004
TXImage: Using default colormap and visual, TrueColor, depth 16.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding
CConn: Throughput 20243 kbit/s - changing to hextile encoding
CConn: Throughput 20243 kbit/s - changing to full colour
CConn: Using pixel format depth 16 (16bpp) little-endian rgb565
CConn: Using hextile encoding
BTW, in case it's relevant, this problem does not occur on a
2004-11-05 rawhide snapshot (i.e. metacity-2.8.6-2).
There are a couple of newer RHEL3 metacity on
ftp://people.redhat.com/hp/testing/ as well, that may be worth a shot.
metacity-2.4.55-7.12 fixed it for me, and 2.4.55-7.14 also works
(that's what I'm running now).
Thanks, we should be in good shape then. It was the same bug I fixed
in another context.