Bug 197721 - VNC install displaying incorrect IP address for viewer connection
VNC install displaying incorrect IP address for viewer connection
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Mike McLean
: 195218 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-07-05 15:19 EDT by eric magaoay
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-07 13:57:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description eric magaoay 2006-07-05 15:19:52 EDT
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 15:58:29 EDT
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 16:11:58 EDT
Please run your installation again up to this point, then attach
/tmp/anaconda.log to this bug report.
Comment 3 eric magaoay 2006-07-05 17:02:33 EDT
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 eric magaoay 2006-07-06 03:05:15 EDT
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 14:56:47 EDT
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 05:15:05 EDT
*** 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.