Bug 179209 - kickstart directive "vnc --connect" not working: server not connecting to listening vnc client
kickstart directive "vnc --connect" not working: server not connecting to li...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Mike McLean
:
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2006-01-28 00:47 EST by magaoaye
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-01 15:02:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description magaoaye 2006-01-28 00:47:29 EST
Description of problem:

the following new kickstart directive that support VNC-based installation is not
working correctly:

       vnc --connect <host>:<port>
The equivalent boot-time option:
       linux vnc vnc vncconnect=<host>:<port>

The above directive should have allowed the installation system to connect to a
listening VNC client viewer (the one that invoked "vncviewer -listen <port>")
  
Version-Release number of selected component (if applicable):

anaconda-10.91.7-1.x86_64.rpm
pykickstart-0.13-1.noarch.rpm

How reproducible:

Persistent

Steps to Reproduce:

1. Assumed that the viewing VNC client have IP=192.168.3.30 and will be using
PORT=6602 to connect to the installation system. The kickstart file
(/usr/src/ks.cfg) and the installation source tree (/usr/src/fc5.x86_64) will
also reside on the viewing VNC client system. 
content of kickstart file (ks.cfg):
     url --url ftp://192.168.3.30/fc5.x86_64 
# NOTE: assumed FTP home directory is: /usr/src
     vnc --connect 192.168.3.30:6602
From the viewing VNC client system, run the vncviewer command: 
     vncviewer -listen 6602 
2. Install the BOOT CD into the installation system, then at boot-time option,
type the following command line:
     linux ks=ftp://192.168.3.30/ks.cfg

Actual results:

OUTPUT on the install system:
    The NVC server is now running. 
    Attempting to connect to vnc client on host 192.168.3.30...
    Connected!
ON the viewing VNC client:
    NOTHING - no viewer pop up to display the install process.

Expected results:
     
The viewing VNC client should be able to have a viewer pop up to display the
install process.

Additional info:

* x86_64: reversed connection does not work whether the command line is added
inside kickstart file or typed under boot-time option.
  
* i386: reversed connection is OK when under boot-time option, NOT working when
added inside kickstart file.
Comment 1 Chris Lumens 2006-01-30 11:54:59 EST
Looks like problems in pykickstart option parsing for vnc.  I'll build a new
package today with a fix and you should be able to try it out again tomorrow. 
Let me know how well it works for you.
Comment 2 magaoaye 2006-01-30 13:44:56 EST
I think pykickstart does parse for vnc but does not pass "-connect
<host>:<port>" back to anaconda. If you look at the snip of
/var/log/anaconda.log, anaconda is simply assuming a command of "vnc" alone
rather than "vnc --connect 192.168.3.30:6602":
 
=======================================
09:56:37 INFO    : Running anaconda script /usr/bin/anaconda
09:56:39 INFO    : Display mode = g
09:56:39 INFO    : Method = ftp://192.168.3.30//mysrc/fed/x86_64
09:56:44 INFO    : Starting VNC...
09:56:44 WARNING :

WARNING!!! VNC server running with NO PASSWORD!
You can use the vncpassword=<password> boot option
if you would like to secure the server.


09:56:44 INFO    : The VNC server is now running.
09:56:44 INFO    : Please connect to bahamas2:1 to begin the install...
=======================================

Below is the snip of anaconda.log that executes "vnc
vncconnect=192.168.3.30:6602" from the kernel command line and properly passes
"extraArg --vnc" and "extraArg --vncconnect=192.168.3.30:6602":

=======================================
12:42:57 INFO    : Running anaconda script /usr/bin/anaconda
12:42:57 DEBUG   : adding extraArg --vnc
12:42:57 DEBUG   : adding extraArg --vncconnect=192.168.3.30:6602
12:42:59 INFO    : Display mode = g
12:42:59 INFO    : Method = ftp://192.168.3.30//mysrc/fed/x86_64
12:43:03 INFO    : Starting VNC...
12:43:04 WARNING :

WARNING!!! VNC server running with NO PASSWORD!
You can use the vncpassword=<password> boot option
if you would like to secure the server.


12:43:04 INFO    : The VNC server is now running.
12:43:04 INFO    : Attempting to connect to vnc client on host 192.168.3.30...
12:43:04 INFO    : Connected!
========================================

NOTE:  
1. adding "vnc -connect" on kickstart fails on i386 and x86_64
2. adding "vnc --vncconnect" on kernel command line works with i386, NOT on
x86_64. The install server says "Connected!" but the listening client is not
detecting any signal so it couldn't bring up the window screen.  

     
Comment 3 magaoaye 2006-01-30 14:12:39 EST
Chris,
I think it's critical to have the IP as well as the host name be desplayed when
the simple "vnc" directive is invoke since not all local network has local DNS
setup and running. It can be difficult to guess the correct IP if the installing
system is using DHCP. So instead of having the following info displayed:

09:56:44 INFO    : The VNC server is now running.
09:56:44 INFO    : Please connect to bahamas2:1 to begin the install..

Better info:

09:56:44 INFO    : The VNC server is now running.
09:56:44 INFO    : Please connect to bahamas2:1 (192.168.3.33:1) to begin the
install..

Comment 4 magaoaye 2006-02-01 12:41:14 EST
I just installed the latest dev build dated 2.1.06 (i386). The specific port is
not being pass on correctly. For example, if my kickstart config file has:

vnc --connect 192.168.3.30:6603

On the listening client you would invoke:

vncviewer -listen 6603

It failed to connect since the server (installing system) is sending signal to
port 5500 (probably the default signal when no port is specified). Here is the
anaconda.log file output:
===============================
11:17:58 INFO    : The VNC server is now running.
11:17:58 INFO    : Attempting to connect to vnc client on host 192.168.3.30...
11:17:59 INFO    : connecting to 192.168.3.30:5500 failed
===============================

NOTE: in order for a listening client (192.168.3.30) to view several installing
systems simultaneously it must use different ports for each system. For example,
if you are installing 3 systems at the same time and each connecting to
192.168.3.30 client, each would have the following kickstart config file
respectively:
ks1.cfg: vnc --connect 192.168.3.30:6601
ks2.cfg: vnc --connect 192.168.3.30:6602
ks3.cfg: vnc --connect 192.168.3.30:6603

on the listening client (192.168.3.30), you would bring up 3 terminals and
invoke the following commands respectively:
terminal1: vncviewer -listen 6601
terminal2: vncviewer -listen 6602
terminal3: vncviewer -listen 6603

NOTE: if only ONE system is being installed specifying port is not required, the
default port is assumed (5500). So the following kickstart config file is
sufficient:
ks.cfg: vnc --connect 192.168.3.30

The listening client would simply execute:
   vncviewer -listen (same as executing "vncviewer -listen 5500")

NOTE on x86_64 platform:
=======================
Here is the vnc command on the kickstart config file:
ks264.cfg: vnc --connect 192.168.3.30:6602

On the listening client, I tried the following:
terminal2: vnvviewer -listen 6602  (result:no viewer started)

And I tried the following without specifying port:
terminal2: vncviewer -listen

Below is the anaconda.log output:
=================================
11:00:59 INFO    : The VNC server is now running.
11:00:59 INFO    : Attempting to connect to vnc client on host 192.168.3.30...
11:01:00 INFO    : Connected!
==================================

The server says connected but the listening client (192.168.3.30) does not bring
up the vnc viewer window. I think it's a FALSE SIGNAL since I tried running it
WITHOUT any listening client running. The anaconda.log should have the following
output:
==================================
111:17:58 INFO    : The VNC server is now running.
11:17:58 INFO    : Attempting to connect to vnc client on host 192.168.3.30...
11:17:59 INFO    : connecting to 192.168.3.30:6602 failed

11:17:59 INFO    : Will try to connect again in 15 seconds...
11:18:14 INFO    : connecting to 192.168.3.30:6602 failed

11:18:14 INFO    : Will try to connect again in 15 seconds...
11:18:29 INFO    : connecting to 192.168.3.30:6602 failed
===================================

Same problem also even when I invoke the vnc directive into the boot-time
command line:

linux vnc vncconnect:192.168.3.30:6602

Anyway, I think we're getting closer with i386, but for x86_64 it just doesn't
connect with listening client either invoking the vnc directive in the kickstart
file or from boot-time command line.
Comment 5 Chris Lumens 2006-02-01 15:02:53 EST
The VNC port bug was in pykickstart.  I've fixed that and will rebuild later, so
tomorrow's tree should be okay.  The x86_64 problems you are seeing is actually
due to a vnc bug that we're doing a very poor job of telling you about.  It
appears to be happening only on x86_64.  I've filed this as bug 179635.
Comment 6 magaoaye 2006-02-04 21:04:16 EST
Chris submitted change works great on i386 when I tested it Fri (Feb 3), but for
some reason the latest change in today's build (Feb 4) failed again. Did someone
reversed Chris' changes on pykickstart? Right now I can't figure out where to
find the changelog for the daily build.  
Comment 7 magaoaye 2006-02-05 01:16:26 EST
OK, looks like there is a change in the way to vnc command directive supposed to
be type. It would work if I type the following:

vnc --connect <hostname> --port <port_number>

The following command NO longer works:

vnc --connect <hostname>:<port_number>

I wonder if the installation documentation has been update to reflect the change.

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