Bug 197721 - VNC install displaying incorrect IP address for viewer connection
Summary: VNC install displaying incorrect IP address for viewer connection
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Mike McLean
: 195218 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-05 19:19 UTC by ericm24x7
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2006-07-07 17:57:53 UTC

Attachments (Terms of Use)

Description ericm24x7 2006-07-05 19:19:52 UTC
Description of problem:

During VNC installation, the IP address being displayed (51:51:51:51) for
vncviewer connection is incorrect.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Assuming VNC kickstart file is ks.cfg with the following content:
      vnc --password install
      url --
      lang en_US.UTF-8
      keyboard us
      # has multiple NIC devices, so using eth0
      network --device eth0 --bootproto dhcp --hostname mazatlan2
2. Invoke the following during initial installation prompt:
      linux vnc ksdevice=eth0 ks=

3. The program installation will proceed, then install the VNC server and
display the its incorrect IP address (
Actual results:

Starting VNC...
The VNC server is now running.
Please connect to to begin the install...
Starting graphical instalation...

Expected results:

Instead of it should be displaying the actual IP address given by
DHCP server. example:

Additional info:

This could be hardware specific because the problem doesn't show up on other PCs
(tried on 5 PCs with different configuration). The following PC system is affected:

ECS (Elitegroup) K8M800-M2(v1.0) Semptron 2800+ socket 755 1GB RAM 300GB HDD

NOTE: Learning the true IP address ( in my case) through probing
(ping), I was able to proceed with the installation using that IP address
( instead of the erroneous IP address ( So I suspect
the program's module that obtain the IP address from DHCP is somewhat being
corrupted in the process.

Comment 1 Doug Chapman 2006-07-05 19:58:29 UTC
Chris, FYI before you dig into this too much this looks like a dup of one I
filed a while back: 195218

Comment 2 Chris Lumens 2006-07-05 20:11:58 UTC
Please run your installation again up to this point, then attach
/tmp/anaconda.log to this bug report.

Comment 3 ericm24x7 2006-07-05 21:02:33 UTC
I can't get into the shell terminal even though it prompt "Press <enter> for a
shell". I tried rsh, ssh, rlogin, telnet into the host machine but I get
refusal. It only allow vncviewer to go through. Any other suggestion how to
remote copy /tmp/anaconda.log file? I will try different hardware config. (use
another video instead of the on-board one, and remove the extra LAN card) and
see if I get the same error.

Comment 4 ericm24x7 2006-07-06 07:05:15 UTC
OK, I did more tests and came up with the following:
1. When there is only ONE LAN device attached, IP address is being displayed
2. When there are 2 LAN devices attached, the install program (anaconda?) is
querying the IP address on the wrong device (eth1) instead of the desired one
3. For some reason, the on-board LAN device is being defined first (eth0) on
some PCs, while the other PCs defined it last (eth1). I am guessing that the
order probably confused the install progam.

Maybe the install program should re-query the IP address just before displaying
it or just before running the VNC server?

NOTE: The latest build broke the ability to bring up a shell prompt during
installation on x86_64 and i386 platform. For this reason I can't access and
copy the /tmp/anaconda.log file.

Comment 5 Chris Lumens 2006-07-06 18:56:47 UTC
Okay, committed a patch to use the interface configured for installation instead
of looping through all available devices and using whichever one gives back an
IP address first.  I think this should take care of your problem.

Comment 6 Mark McLoughlin 2006-08-02 09:15:05 UTC
*** Bug 195218 has been marked as a duplicate of this bug. ***

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