Bug 928279

Summary: anaconda doesn't start on LiveCD (in Gnome)
Product: [Fedora] Fedora Reporter: Petr Schindler <pschindl>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: anaconda-maint-list, awilliam, dcbw, g.kaviyarasu, jonathan, jreznik, jskladan, kparal, mfabian, mkolman, psimerda, robatino, satellitgo, sbueno, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-08 17:31:05 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 Flags
traceback
none
anaconda.log
none
program.log
none
traceback none

Description Petr Schindler 2013-03-27 10:03:04 UTC
Created attachment 716985 [details]
traceback

Description of problem:
When I start anaconda it won't show up. It crashes with sigsegv. This is traceback from /tmp/anaconda-tb-xAr3eq

anaconda 19.13 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/__init__.py", line 531, in busyCursor
    window.set_cursor(Gdk.Cursor(Gdk.CursorType.WATCH))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/__init__.py", line 285, in setup
    busyCursor()
  File "/sbin/anaconda", line 1029, in <module>
    anaconda._intf.setup(ksdata)
AttributeError: 'NoneType' object has no attribute 'set_cursor'

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


How reproducible:
always on LiveCd Gnome

Steps to Reproduce:
1. boot live image
2. run anaconda
3.
  
Actual results:
nothing happens

Expected results:
anaconda starts

Additional info:

Comment 1 Petr Schindler 2013-03-27 10:03:47 UTC
Created attachment 716987 [details]
anaconda.log

Comment 2 Petr Schindler 2013-03-27 10:04:31 UTC
Created attachment 716988 [details]
program.log

Comment 3 Adam Williamson 2013-03-27 16:44:08 UTC
Discussed at 2013-03-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-27/f19alpha-blocker-review-3.2013-03-27-16.01.log.txt . While this could potentially be a release blocker,it doesn't seem to be consistent, other testers report success or different errors. We're delaying evaluation while we try to pin down the circumstances here.

Comment 4 Adam Williamson 2013-03-27 16:49:14 UTC
I don't hit this, with TC2 desktop live x86-64 on a KVM qxl/Spice guest on an F19 host, guest has 2GB of RAM; liveinst runs okay.

Comment 5 Petr Schindler 2013-03-28 07:14:21 UTC
I can confirm, that in KVM anaconda at least starts. But on my two desktops it doesn't start correctly. The process is running and taking 100% of CPU, but anaconda window doesn't show up.

This is, I think, interesting part of program.log:

05:47:35,144 INFO program: Starting installer, one moment...
05:47:35,149 INFO program: anaconda 19.13 for Fedora 19 (pre-release) started.
05:47:35,153 INFO program: Anaconda received SIGSEGV!.  Backtrace:
05:47:35,158 INFO program: /usr/lib64/python2.7/site-packages/pyanaconda/_isys.so(+0x37a6) [0x7fa6f25b57a6]
05:47:35,163 INFO program: /lib64/libpython2.7.so.1.0(PyObject_Call+0x43) [0x7fa704b21a73]
05:47:35,167 INFO program: /lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47) [0x7fa704baf407]
05:47:35,172 INFO program: /lib64/libpython2.7.so.1.0(PyErr_CheckSignals+0xa9) [0x7fa704be49d9]
05:47:35,173 INFO program: /lib64/libpython2.7.so.1.0(PyObject_Repr+0xd) [0x7fa704b5aabd]
05:47:35,175 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4b8e) [0x7fa704bb457e]
05:47:35,183 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed) [0x7fa704bb558d]
05:47:35,184 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4689) [0x7fa704bb4079]
05:47:35,185 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x472c) [0x7fa704bb411c]
05:47:35,196 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed) [0x7fa704bb558d]
05:47:35,198 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4689) [0x7fa704bb4079]
05:47:35,199 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x472c) [0x7fa704bb411c]
05:47:35,200 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed) [0x7fa704bb558d]
05:47:35,201 INFO program: /lib64/libpython2.7.so.1.0(+0x6d3bd) [0x7fa704b453bd]
05:47:35,202 INFO program: /lib64/libpython2.7.so.1.0(PyObject_Call+0x43) [0x7fa704b21a73]
05:47:35,204 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0xe3d) [0x7fa704bb082d]
05:47:35,205 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x472c) [0x7fa704bb411c]
05:47:35,206 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x472c) [0x7fa704bb411c]
05:47:35,207 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed) [0x7fa704bb558d]
05:47:35,208 INFO program: /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4689) [0x7fa704bb4079]

Comment 6 Jens Petersen 2013-04-03 04:20:55 UTC
liveinst starts fine for me too for TC3 Desktop Live or later on my intel laptop
and as a vm guest (I didn't try TC2 Live).

Comment 7 Kamil Páral 2013-04-03 12:01:09 UTC
I can confirm this problem with Alpha TC3 Desktop Live i686 and bare metal. Anaconda is stuck in a loop, strace shows SIGSEGV loop. In that regard it could be related to bug 928287.

Comment 8 Kamil Páral 2013-04-03 12:03:00 UTC
Created attachment 731126 [details]
traceback

traceback for comment 7

Comment 9 Adam Williamson 2013-04-03 17:21:41 UTC
Discussed at 2013-04-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-03/f19alpha-blocker-review-4.2013-04-03-16.01.log.txt . We have still not isolated the exact trigger condition for this, but it seems to affecting at least enough configurations to be provisionally accepted as a blocker per criterion "The installer must run when launched normally from the release-blocking images." on affected systems.

We may re-evaluate if further testing indicates only a few configurations are affected.

Comment 10 Adam Williamson 2013-04-03 17:30:00 UTC
can't reproduce on my laptop (bare metal), liveinst starts up correctly. Tested TC3 Desktop x86-64. The laptop is a 2010 Vaio Z, a pretty standard Intel '5 series' config (Core i5-M520, 4GB RAM).

Comment 11 satellitgo 2013-04-03 17:41:16 UTC
Tested boot of dd of 2 GB USB Fedora-19-Alpha-TC3-x86_64-Live-Desktop.iso

Acer Aspire One n450 with 2 GB Memory; wired network connected

Install to Disk: anaconda starts and it gets to main hub "Installation Summary"

Comment 12 Jens Petersen 2013-04-04 05:48:09 UTC
Petr and Kamil, can you retest again with TC4? - anaconda seems more stable now.

Comment 13 Kamil Páral 2013-04-04 09:51:48 UTC
Martin and I tested 3 different computers, Alpha TC4 Live, i386 and x86_64, GNOME and KDE. Anaconda doesn't start on either of them. Strace shows SIGSEGV loop.

I still suspect bug 928287, but anaconda devs from Brno can come any time and tinker with the machines, no problem at all.

Comment 14 Kamil Páral 2013-04-04 09:57:45 UTC
Mac Mini tested as well, Anaconda doesn't start. SIGSEGV loop.

Comment 15 Jens Petersen 2013-04-04 11:12:55 UTC
Interesting - it starts fine for me every time on my T500 - but hung for me in post install phase with anaconda using 135% cpus or so.

Comment 16 Kamil Páral 2013-04-04 11:40:48 UTC
(In reply to comment #15)
> but hung for me in post install phase with anaconda using 135% cpus or so.

That's bug 928287.

Comment 17 satellitgo 2013-04-04 13:09:41 UTC
anaconda 19.15 starts in VirtualBox TC4 Live Desktop but after install I get grub2 prompt only on both i686 and X86_64. with 2048 Memory and 16.GB HD

Comment 18 Chris Lumens 2013-04-04 19:05:20 UTC
I cannot reproduce the crash, though it's definitely very slow without the slub_debug=- parameter that I am increasingly becoming friends with.

If someone can reproduce the sigsegv, please get a core file and attach it to this bug report as well as making sure to indicate what version of anaconda and what architecture.  Thanks.

Comment 19 Jens Petersen 2013-04-05 03:42:45 UTC
Kamil, probably you can retest with Live + anaconda-19.16-2.fc19,
which fixed the "dbus crash/hang" for me.

Comment 20 Josef Skladanka 2013-04-05 08:47:55 UTC
(In reply to comment #19)

This IMHO does not fix the problem. After updating to anaconda-19.16-2.fc19 and running the "Install to Hard Drive" app, anaconda still falls into the sigsegv loop. Running liveinst from terminal says "xhost: unable to open display :0" and some gdk-CRITICAL errors (sigsegv looping ofc).

Comment 21 Josef Skladanka 2013-04-05 08:51:34 UTC
(In reply to comment #20)

Weird, after trying for fifth or sixth time, anaconda seems to be starting without problems. Both from terminal and the "Install to Hard Drive app".

Comment 22 Josef Skladanka 2013-04-05 09:00:00 UTC
OK, disregard  #20) &  (#21). I tried several times after reboots, and everything works fine after updating anaconda.

Comment 23 Jens Petersen 2013-04-06 03:39:52 UTC
Alpha TC5 has anaconda-19.16-2.fc19 - anyone still seeing this?

Comment 24 Josef Skladanka 2013-04-08 10:22:59 UTC
(In reply to comment #23)

Sadly, yes. But it's weird - it fails to the SIGSEGV loop every time, until I run `sudo liveinst` from terminal. Once I run the command, Anaconda starts, and then even the icons on welcome screen and in launcher start working (i.e. no sigsegv loop). Reproducible every time with Alpha TC5.1 and (at least) Mac Mini.

Comment 25 Jaroslav Reznik 2013-04-08 13:48:37 UTC
Seems like it's https://bugzilla.redhat.com/show_bug.cgi?id=679486

Josef confirms, "xhost +" helps, also booting with network cable unplugged.

Comment 26 Kamil Páral 2013-04-08 13:51:19 UTC
We've found out this is a re-occurrence of bug 679486. It happens just if you use DHCP hostnames, and it depends on timing. That's why we hit it all the time on the corporate network, but we don't see that on VMs (private network) or at home (when using a router). Read bug 679486 comment 7 and below.

The workaround is to either run "sudo liveinst" manually, run "xhost +" before running "liveinst", or boot and run anaconda with the network disconnected.

Comment 27 Pavel Šimerda (pavlix) 2013-04-08 14:07:26 UTC
(In reply to comment #25)
> Seems like it's https://bugzilla.redhat.com/show_bug.cgi?id=679486
> 
> Josef confirms, "xhost +" helps, also booting with network cable unplugged.

With that information in mind, I see two possibilities:

1) Fix (local) xauth to avoid dependency on stable hostname

2) Make the hostname stable

I guess the second option is the easier one. If my information is correct, the current versions of NetworkManager look at /etc/hostname and the actual hostname.

I believe that if you stabilize the hostname by setting /etc/hostname, NetworkManager will leave it as is. Make sure it's propagated to the actual runtime hostname. This is usually systemd's responsibility but it depends on when you modify the file. Maybe try just shipping /etc/hostname with the live image and let systemd and NetworkManager do their own work.

Cheers,

Pavel

Comment 28 Dan Williams 2013-04-08 17:10:04 UTC
(In reply to comment #26)
> We've found out this is a re-occurrence of bug 679486. It happens just if
> you use DHCP hostnames, and it depends on timing. That's why we hit it all
> the time on the corporate network, but we don't see that on VMs (private
> network) or at home (when using a router). Read bug 679486 comment 7 and
> below.
> 
> The workaround is to either run "sudo liveinst" manually, run "xhost +"
> before running "liveinst", or boot and run anaconda with the network
> disconnected.

Pavel's workarounds are correct; the real fix for this is to ensure that local X connections are *always* allowed, and to never rely on hostname-based authentication, because hostnames can change, and there are legitimate reasons for allowing the DHCP server to determine your hostname.

So the next step is to figure out what broken with the X local authentication workarounds that Fedora has had in place for years to always allow local connections regardless of hostname.

I don't think this is an Anaconda bug, but an xauth one.

Comment 29 Adam Williamson 2013-04-08 17:31:05 UTC
Closing as a dupe, transferring blocker status discussion there.

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