Bug 952801
Summary: | Anaconda doesn't wait for NetworkManager before giving up on VNC install (Not asking for VNC because we don't have a network) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gustavo Luiz Duarte <gustavold> | ||||||
Component: | anaconda | Assignee: | Radek Vykydal <rvykydal> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 19 | CC: | g.kaviyarasu, gustavold, hamzy, jonathan, mkolman, sbueno, vanmeeuwen+fedora | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | anaconda-19.24-1.fc19 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2013-05-22 03:17:35 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Gustavo Luiz Duarte
2013-04-16 18:11:44 UTC
It is interesting that if I enter "linux inst.vnc" to the boot command line I get the following sequence of messages from Anaconda: 18:17:42 Not asking for VNC because we don't have a network 18:17:42 Starting VNC... 18:17:48 The VNC server is now running. Then I can proceed with VNC installation. Thank you for your report. Patch sent for review, you can check if it works for you using updates image by adding this to boot options: updates=http://rvykydal.fedorapeople.org/updates.vnc.connecting.19.17.img for the version 19.17 from the Description or updates=http://rvykydal.fedorapeople.org/updates.vnc.connecting.f19alpha.img for F19 Alpha anaconda-19.23-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/anaconda-19.23-1.fc19 Package anaconda-19.23-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-19.23-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-7049/anaconda-19.23-1.fc19 then log in and leave karma (feedback). anaconda-19.24-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/anaconda-19.24-1.fc19 Radek, What is the git commit id for this? Is this the patch? https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-April/003906.html I am still seeing this: Starting installer, one moment... anaconda 19.25-1 for Fedora 19 (pre-release) started. 15:36:35 Not asking for VNC because we don't have a network 15:36:35 X startup failed, falling back to text mode (In reply to comment #6) > Radek, > > What is the git commit id for this? > commit 9a0542611b2f03434a9067b76e54bf6162e971ba, the patch should be there (in 19,25). > Is this the patch? > > https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-April/003906. > html > Yes. > I am still seeing this: > > Starting installer, one moment... > anaconda 19.25-1 for Fedora 19 (pre-release) started. > 15:36:35 Not asking for VNC because we don't have a network > 15:36:35 X startup failed, falling back to text mode Hm, you might be seeing another race (checking connection for vnc even before NM gets into connecting state). Could you please attach anaconda.log and syslog from your reproducer? Thanks anaconda-19.24-1.fc19, python-blivet-0.12-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. Created attachment 752315 [details]
anaconda.log
Created attachment 752316 [details]
syslog
Radek, I came across this again: anaconda 19.28-1 for Fedora 19 (pre-release) started. 18:14:37 Not asking for VNC because we don't have a network 18:14:37 X startup failed, falling back to text mode Do the attached logs help? Thanks for the logs, it seems you might be hitting a race caused by wrong order of conditions in patch from comment #6 if not nm_is_connected() and not nm_is_connecting(): stdoutLog.warning("Not asking for VNC because we don't have a network") from the logs: 18:14:37,312 INFO NetworkManager: <info> Activation (eth1) successful, device activated. 18:14:37,313 INFO NetworkManager: <info> (eth0): device state change: secondaries -> activated (reason 'none') [90 100 0] 18:14:37,331 INFO NetworkManager: <info> Activation (eth0) successful, device activated. 18:14:37,332 INFO NetworkManager: <info> Activation (eth1) Stage 5 of 5 (IPv6 Commit) scheduled... 18:14:37,333 WARN anaconda.stdout: Not asking for VNC because we don't have a network we can see that the condition is tested just about the time the devices become activated. This is most probably the point where NM moves from state connecting to connected, so what might happen here is: - NM is in connecting state - nm_is_connected() is checked and fails - NM goes to connected state - nm_is_connecting() is checked and fails If the conditions were swapped this race should not happen (or we could add "atomic" check for both connecting and connected states in nm.py). I'll send a patch swapping the conditions and let's hope my theory was right. Here is updates image with fix for 19.29: http://rvykydal.fedorapeople.org/updates.vncrace.img but I suppose it is very difficult to reproduce the race condition and therefore almost impossible to confirm reliably that the patch actually fixes it. I agree that it would be difficult to reproduce the race condition. Should I reopen this bug? Mark, I pushed the patch from comment #12 both to master and f19-branch, it should go to builds following anaconda-19.30-1 build. I wouldn't reopen the BZ, if you really care open a new one but it would be very difficult to reproduce/verify so I'd just consider the issue fixed, waiting whether we hit the same issue in future. Awesome, thanks! |