Description of problem: When I install the F20 netinst in the kvm, it just suspend at the first step, after selecting the language. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 790310 [details] screen shot
Created attachment 790311 [details] anaconda log
Happens with either 32-bit install image (netinst or DVD). 64-bit images are not affected.
Tao, do you mean suspend (a.k.a put to sleep) or freeze? I can reproduce freeze. anaconda process is at 100% cpu. When I switch to tty1, I see: error: XDG_RUNTIME_DIR not set in the environment. Proposing as AlphaBlocker: The installer must run when launched normally from the release-blocking images. https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Installer_must_run
(In reply to Kamil Páral from comment #4) > Tao, do you mean suspend (a.k.a put to sleep) or freeze? I can reproduce > freeze. anaconda process is at 100% cpu. > > When I switch to tty1, I see: > error: XDG_RUNTIME_DIR not set in the environment. > > Proposing as AlphaBlocker: > The installer must run when launched normally from the release-blocking > images. > https://fedoraproject.org/wiki/ > Fedora_20_Alpha_Release_Criteria#Installer_must_run Kamil, I am not sure that it does freeze. In my case, the anaconda takes up about 90% cpu like the attachment displays.
Created attachment 791288 [details] cpu occupies
(In reply to Tao Wu from comment #6) > Created attachment 791288 [details] > cpu occupies Since it already consumed 1158 minutes of CPU time, I think you can very well consider it frozen (or stuck or whatever you want to call it) :-)
Discussed at 2013-08-28 blocker review meeting [1]. This is accepted as an Alpha blocker, because it violates the following F20 alpha release criterion for 32bit installs: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." [2] [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-08-28/ [2] https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Remote_package_sources
I get the same thing with a kickstart install on physical hardware. Hangs for me during "Starting package installation process" just after clicking "Yes" to skipping the missing package "unrar". strace of the anaconda process shows: 5309 futex(0x97aff70, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...> 5287 restart_syscall(<... resuming interrupted call ...> <unfinished ...> 5098 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x37c7} --- 5176 restart_syscall(<... resuming interrupted call ...> <unfinished ...> 5098 sigreturn() (mask []) = 14279 5098 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x37c7} --- 5098 sigreturn() (mask []) = 14279 5098 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x37c7} --- .......... the last two lines repeat forever. last anaconda.log lines: 16:26:32,541 INFO anaconda: Setting up the installation environment 16:26:40,828 INFO anaconda: Creating ext4 on /dev/sda5 16:26:59,393 INFO anaconda: Creating swap on /dev/sda3 16:27:00,592 INFO anaconda: Creating biosboot on /dev/sda2 packaging.log shows: 16:28:19,545 DEBUG packaging: select package unrar 16:28:19,549 INFO packaging: about to acquire _yum_lock for AnaInstallThread at /usr/lib/python2.7/site-packages/pyanaconda/packaging/yumpayload.py:1157 (_applyYumSelections) 16:28:19,550 INFO packaging: have _yum_lock for AnaInstallThread 16:28:19,552 DEBUG yum.verbose.YumBase: Checking for virtual provide or file-provide for unrar 16:28:19,555 INFO packaging: gave up _yum_lock for AnaInstallThread
This bug still exists in Tc2 i386, on my kvm.
I am seeing this bug in Alpha-TC2 and on tty1 it is reporting "error: XDG_RUNTIME_DIR not set in environment" Could this bug be as simple as an undeclared environment variable?
David, could you please have a look at this one? If I comment out the 'with englightbox(...):' line in _on_continue_clicked in pyanaconda/ui/gui/spokes/welcome.py, everything works as expected. Some debugging shows that the SIGSEGV happens when AnacondaWidgets.lb_destroy(lightbox) is called. However, since this happens only in 32bit installations, I doubt it is a problem on our side.
Created attachment 793239 [details] backtrace
This appears to be a problem in glib. The crash is happening at this line in lightbox.c: g_signal_emit_by_name(window, "configure-event", window); which is causing value_lcopy_boolean to write to an invalid pointer. The window has not been destroyed and GTK_IS_WINDOW(window) returns true. I've attached the backtrace for the g_signal_emit_by_name call and below.
Unfortunately it still happens on F20 TC3.
Doesn't look glib related to me at all. Where does the code for lightbox.c live ? Thats the most likely culprit.
Changing needinfo to David.
The relevant anaconda code [1] says /* XXX HAAAAAAACK: */ So, I'd go looking there first. [1] https://git.fedorahosted.org/cgit/anaconda.git/tree/widgets/src/lightbox.c
Fixing the signal emission [1] to actually match the signature of the configure-event signal [2] may fix the crash. But the code should still not do that kind of thing, it is not at all kosher to emit gtks internal signals willy-nilly like that. [1] https://developer.gnome.org/gobject/2.36/gobject-Signals.html#g-signal-emit-by-name [2] https://developer.gnome.org/gtk3/3.8/GtkWidget.html#GtkWidget-configure-event
Still broken in 20 Alpha TC4 i386 install images (netinst or DVD). x86_64 install images are ok as before.
Still happens in F20 Alpha TC4 i386.
David/Vratislav, did you have time to take a look on proposed fix by Matthias?
Here are some updates images for anyone who wants to test: 32-bit: http://dshea.fedorapeople.org/updates-1000927-i386.img 64-bit: http://dshea.fedorapeople.org/updates-1000927-x86_64.img
(In reply to David Shea from comment #23) > Here are some updates images for anyone who wants to test: > > 32-bit: http://dshea.fedorapeople.org/updates-1000927-i386.img > 64-bit: http://dshea.fedorapeople.org/updates-1000927-x86_64.img Will this update be in alpha_tc5 or do we need to test the updates against tc4?
(In reply to David Shea from comment #23) > Here are some updates images for anyone who wants to test: > > 32-bit: http://dshea.fedorapeople.org/updates-1000927-i386.img > 64-bit: http://dshea.fedorapeople.org/updates-1000927-x86_64.img Using these, all four 20 Alpha TC4 install images (32- and 64-bit DVD and netinst) successfully get to the "Installation Summary" page. (Unfortunately, if the Installation source is set to "Closest mirror", there's an "Error checking software selection" error when trying to do a default GNOME install, but that's a separate bug - it happens either with or without the updates.img.)
This still happens in TC5, but can work around through David Shea's updates img. Thanks to David Shea.
Setting status and component back to right value.
Can we get the patch review + build done today?
(In reply to Jaroslav Reznik from comment #28) > Can we get the patch review + build done today? Review done, as a temporary solution for Alpha. Thanks Vratislav.
anaconda-20.14-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.14-1.fc20
Package anaconda-20.14-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-20.14-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16409/anaconda-20.14-1.fc20 then log in and leave karma (feedback).
tested with f20 alpha RC1 i386 on a VM, install completes successfully. Setting to VERIFIED
anaconda-20.15-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.15-1.fc20
anaconda-20.16-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.16-1.fc20
anaconda-20.17-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.17-1.fc20
This problem no longer exists in Alpha_RC2
anaconda-20.17-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.