Bug 868777 - fail to install the system use vnc
Summary: fail to install the system use vnc
Status: CLOSED DUPLICATE of bug 832510
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Radek Vykydal
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker
: 868791 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2012-10-22 06:28 UTC by lnie
Modified: 2013-01-31 13:59 UTC (History)
9 users (show)

Fixed In Version: anaconda-18.38-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-01-31 13:59:12 UTC
Type: Bug

Attachments (Terms of Use)
anaconda.log (925 bytes, text/plain)
2012-10-22 07:35 UTC, Michal Kovarik
no flags Details
syslog (67.14 KB, text/plain)
2012-10-22 07:35 UTC, Michal Kovarik
no flags Details
I have test the TC7 on my system,it failed ,but on Michal's system it passed (925 bytes, text/x-log)
2012-11-06 03:10 UTC, lnie
no flags Details
I have test the TC7 on my system,it failed ,but on Michal's system it passed (62.27 KB, application/octet-stream)
2012-11-06 03:10 UTC, lnie
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 832510 0 unspecified CLOSED vnc server starts before the network 2021-02-22 00:41:40 UTC

Internal Links: 832510

Description lnie 2012-10-22 06:28:40 UTC
Description of problem:
Boot the installer with the following command-line options :
vnc vncpassword=12345678 (vnc)

Version-Release number of selected component (if applicable):
f18 x86-64 Beta Tc6
How reproducible:
Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Michal Kovarik 2012-10-22 07:34:37 UTC
I reproduced it on DVD installation Fedora-18 x86-64 Beta TC6.
Anaconda fell down with:
Could not initialize the VNC server: No IP addresses found.

on tty2:
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:29:44:38 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
    inet6 fe80::5054:ff:fe29:4438/64 scope link 
       valid_lft forever preferred_lft forever

cat /proc/cmdline
initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2018-Beta-TC6\x20x86_64  vnc BOOT_IMAGE=vmlinuz

Comment 2 Michal Kovarik 2012-10-22 07:35:05 UTC
Created attachment 631306 [details]

Comment 3 Michal Kovarik 2012-10-22 07:35:36 UTC
Created attachment 631307 [details]

Comment 4 Michal Kovarik 2012-10-22 11:09:37 UTC
It seems to me as race condition. It's only on media installation (dvd, netinst.iso).

How reproducible:
sometimes - depends on dhcp lease

Comment 5 Chris Lumens 2012-10-22 12:54:31 UTC
*** Bug 868791 has been marked as a duplicate of this bug. ***

Comment 6 Adam Williamson 2012-10-22 15:32:38 UTC
This should be nominated as a Beta blocker, Alpha criteria say " The installer must be able to complete an installation using the text, graphical and VNC installation interfaces".

Comment 7 Adam Williamson 2012-10-24 01:53:29 UTC
Discussed at 2012-10-22 QA meeting acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2012-10-22/fedora-qa.2012-10-22-15.00.html . We agreed we need a few more details on this before deciding on blocker status. It would be useful to know if it affects only media-based installs or if it also affects PXE installs, as we suspect PXE installs may be the main users of the VNC feature. It would also help to know whether using a static IP address is usable as a workaround for this.

Comment 8 Michal Kovarik 2012-10-24 07:34:39 UTC
This issue affects only media-based installs with dhcp.
PXE installation and media-based installation with static network configuration works as expected.

Comment 9 Adam Williamson 2012-10-24 17:09:50 UTC
Discussed at the 2012-10-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-24/f18beta-blocker-review-5.2012-10-24-16.01.log.txt . With our current understanding of the issue, that it works with PXE and/or static networking, this is rejected as a Beta blocker: it violates the criterion only under certain conditions, and we believe the most likely use cases are covered. It can be re-proposed if more data emerges (tflink says he had trouble with a PXE/dhcp test, but it may not have been this precise bug).

Comment 10 Tao Wu 2012-11-05 06:18:20 UTC
It works fine on TC7 32bit, I have just verified it.

Comment 11 lnie 2012-11-06 03:10:03 UTC
Created attachment 639070 [details]
I have test the TC7 on my system,it failed ,but on Michal's system it passed

Comment 12 lnie 2012-11-06 03:10:47 UTC
Created attachment 639071 [details]
I have test the TC7 on my system,it failed ,but on Michal's system it passed

Comment 13 Michal Kovarik 2012-11-06 06:59:02 UTC
I've tried again with Fedora-18-Beta-TC7(DVD) in KVM. For first time it failed with this issue, for next time it worked fine.

Comment 14 lnie 2012-12-10 09:43:11 UTC
 Still happens in the Fedora-18-Final-TC1 X86_64

Comment 15 Radek Vykydal 2012-12-10 14:40:01 UTC
Yes, we race with slow dhcp NM's default auto connection is waiting for. Sending a patch to ML.

Comment 16 Fedora Update System 2012-12-12 00:54:47 UTC
anaconda-18.37.1-1.fc18 has been submitted as an update for Fedora 18.

Comment 17 Fedora Update System 2012-12-12 20:41:32 UTC
Package anaconda-18.37.2-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.37.2-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 18 Fedora Update System 2012-12-15 03:18:01 UTC
anaconda-18.37.2-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Kamil Páral 2013-01-02 17:28:53 UTC
Radek, can you look at bug 832510 comment 3? Maybe this is not fixed?

Comment 20 David Woodhouse 2013-01-02 19:26:23 UTC
It looks like a call to network.wait_for_dhcp() was added. But that only waits for DHCP if the Ethernet driver has already loaded, and NM is *already* starting to connect. I suspect in my case it's all happening before NetworkManager notices the Ethernet device at all, so it's not in NM_STATE_CONNECTING.

The underlying problem is still there and not fixed at all. We've just changed the parameters of the race condition a bit. The real bug is that there's absolutely no reason to *abort* the installation when this happens. As far as I can tell, the only reason you need to know the IP address is to tell the user which address they can connect to. But the user could probably work that out some other way, if you can't manage it. You should still start the server listening on [::]. It's suboptimal if the user has to work out the IP address for themselves, but it's better than an outright failure. 

There is *no* situation in which the outright failure is better than printing "No network yet; VNC installation may not work..." and going ahead anyway, surely?

You could always add an asynchronous notification when an IP address *does* come along... but that's more work. Just avoiding the crash would be a good start.

Comment 21 Radek Vykydal 2013-01-31 13:59:12 UTC

*** This bug has been marked as a duplicate of bug 832510 ***

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