Bug 179209
Summary: | kickstart directive "vnc --connect" not working: server not connecting to listening vnc client | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | magaoaye |
Component: | anaconda | Assignee: | Chris Lumens <clumens> |
Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-01 20:02:53 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 150222 |
Description
magaoaye
2006-01-28 05:47:29 UTC
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. 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. 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.. 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. 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. 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. 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. |