Bug 1103496 - Installer interface sometimes freezes for a while (but install continues, and screen eventually unfreezes)
Summary: Installer interface sometimes freezes for a while (but install continues, and...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: oxygen-gtk
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 1104535 1105427 1114217 1142862 1160484 (view as bug list)
Depends On:
Blocks: F21FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2014-06-01 14:15 UTC by satellitgo
Modified: 2014-11-20 15:07 UTC (History)
23 users (show)

Fixed In Version: oxygen-gtk3-1.4.1-3.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-20 15:07:34 UTC
Type: Bug


Attachments (Terms of Use)
Storage log (152.96 KB, text/plain)
2014-07-10 21:31 UTC, Mairi Dulaney
no flags Details
program.log (30.68 KB, text/plain)
2014-07-10 21:32 UTC, Mairi Dulaney
no flags Details
packaging.log (226 bytes, text/plain)
2014-07-10 21:33 UTC, Mairi Dulaney
no flags Details
ifcfg.log (2.80 KB, text/plain)
2014-07-10 21:35 UTC, Mairi Dulaney
no flags Details
anaconda.log (13.94 KB, text/plain)
2014-07-10 21:35 UTC, Mairi Dulaney
no flags Details
spinner.py (218 bytes, text/x-python)
2014-11-05 22:58 UTC, David Shea
no flags Details


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 340901 0 None None None Never
Red Hat Bugzilla 1142862 0 unspecified CLOSED Sometimes the whole desktop or a single app is just a still picture 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1160484 0 unspecified CLOSED Missing User account and progress bar during install 2021-02-22 00:41:40 UTC

Internal Links: 1142862 1160484

Description satellitgo 2014-06-01 14:15:06 UTC
Description of problem:
boot.iso 20140601 configuration screen is blank  21.38-1
root and user screens work if clicked on blank area (where should be located)
return to Configuration screen still blank  No progress shown.

Version-Release number of selected component (if applicable):
Anaconda 21.38-1  boot.iso 20140601
previous boot.iso 20140531 worked fine

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Chris Lumens 2014-06-02 19:16:11 UTC
If you just sit there and wait, it will eventually complete and then redraw.  Pretty weird.

Comment 2 satellitgo 2014-06-04 14:08:22 UTC
Also seen with boot.iso 20140604  anaconda 21.39-1 in Virtualbox 4.2.18_OSE r88780 with installed extensions (Oracle) 4.2.18-88780 in openSUSE 13.1
1024 / 2 CPU / bridged networking 
If you know where the root pswd and user screen buttons are located and click on the area the root and user setups work. On Back return to non visible Configuration screen. Progress can be monitored in VirtualBox disk and networking icons on bottom line of VB window

Comment 3 satellitgo 2014-06-04 15:05:50 UTC
(In reply to satellit from comment #2)
> Also seen with boot.iso 20140604  anaconda 21.39-1 in Virtualbox 4.2.18_OSE
> r88780 with installed extensions (Oracle) 4.2.18-88780 in openSUSE 13.1
> 1024 / 2 CPU / bridged networking 
> If you know where the root pswd and user screen buttons are located and
> click on the area the root and user setups work. On Back return to non
> visible Configuration screen. Progress can be monitored in VirtualBox disk
> and networking icons on bottom line of VB window

Configuration screen again shows progress at "Generating intramfs"

Comment 4 Brian Lane 2014-06-04 21:29:24 UTC
*** Bug 1104535 has been marked as a duplicate of this bug. ***

Comment 5 satellitgo 2014-06-06 02:22:40 UTC
(In reply to satellit from comment #3)
> (In reply to satellit from comment #2)
> > Also seen with boot.iso 20140604  anaconda 21.39-1 in Virtualbox 4.2.18_OSE
> > r88780 with installed extensions (Oracle) 4.2.18-88780 in openSUSE 13.1
> > 1024 / 2 CPU / bridged networking 
> > If you know where the root pswd and user screen buttons are located and
> > click on the area the root and user setups work. On Back return to non
> > visible Configuration screen. Progress can be monitored in VirtualBox disk
> > and networking icons on bottom line of VB window
> 
> Configuration screen again shows progress at "Generating intramfs"

Also encountered in Boot.iso 20140605 of Desktop default in VirtualBox

Comment 6 Chris Lumens 2014-06-06 15:47:26 UTC
*** Bug 1105427 has been marked as a duplicate of this bug. ***

Comment 7 satellitgo 2014-06-06 16:08:04 UTC
Fedora-Live-Workstation-x86_64-rawhide-20140606
The intro screen try desktop is shortened as no CD image displayed but works on click.

No root or user screens shown on Configuration screen but cursor changes to hand over them. after returning to configuration screen no progress till "generating intramfs" (Virtual Box)

Boot.iso 20140606 same behavior on Bare metal install to ext USB HD of Gnome default. wired and wireless settings worked as setup.

Comment 8 David Shea 2014-06-30 13:25:43 UTC
*** Bug 1114217 has been marked as a duplicate of this bug. ***

Comment 9 Brian Lane 2014-07-03 01:18:31 UTC
Are people still seeing this? It has stopped doing it for me with the current nightly and my local boot.iso builds.

Comment 10 Mairi Dulaney 2014-07-10 21:01:02 UTC
Still showing up in Alpha TC1 KDE Live image; have not tried any other lives.  First attempt to install appears to have completed, but root filesystem was not mounting.  Not sure if this is the same issue or not, am reproducing.  Will upload logs from reproducer.

Comment 11 Mairi Dulaney 2014-07-10 21:31:01 UTC
Created attachment 917190 [details]
Storage log

Comment 12 Mairi Dulaney 2014-07-10 21:32:34 UTC
Created attachment 917191 [details]
program.log

Note with the program.log that building the initramfs failed on lvm filters

Comment 13 Mairi Dulaney 2014-07-10 21:33:22 UTC
Created attachment 917192 [details]
packaging.log

Comment 14 Mairi Dulaney 2014-07-10 21:35:01 UTC
Created attachment 917193 [details]
ifcfg.log

Comment 15 Mairi Dulaney 2014-07-10 21:35:24 UTC
Created attachment 917194 [details]
anaconda.log

Comment 16 Mairi Dulaney 2014-07-10 21:41:31 UTC
Rootfs not mounting is another issue; looks like the initramfs is not building correctly.

Comment 17 satellitgo 2014-07-13 17:05:19 UTC
also seen in VirtualBox install of: 
Fedora-Live-KDE-x86_64-21-20140713.iso
but
Fedora-Live-SoaS-x86_64-21-20140713.iso showed configuration screen correctly

Comment 18 satellitgo 2014-07-22 16:54:22 UTC
seen in Fedora-Live-x86_64-21-20140722.iso in VirtualBox
Configuration screen is blank but cursor changes to hand over root and user which work. Configuration screen is blank during install until generating  intramf (sp)reboot at end works fine.

Comment 19 Mike Ruckman 2014-08-06 20:54:59 UTC
Saw this during installation of Fedora-Live-x86_64-21-20140807.iso.

Comment 20 satellitgo 2014-08-06 21:54:48 UTC
Also seen in Fedora-Live-KDE-x86_64-21-20140805.iso

Comment 21 satellitgo 2014-08-06 21:57:13 UTC
(In reply to satellit from comment #20)
> Also seen in Fedora-Live-KDE-x86_64-21-20140805.iso

note that this can vary  one time the language selection screen is blank; next time the Install screen is blank until intramfs with no progress %shown (VirtuaBox)

Comment 22 satellitgo 2014-08-13 20:28:58 UTC
Fedora-Live-LXDE-x86_64-21-20140813.iso  (VirtualBox) Anaconda 21.48.2-1 install with root and no user boots to Configure USER before finish install and logs in correctly

Comment 23 satellitgo 2014-08-20 14:36:45 UTC
Fedora-Live-KDE-x86_64-21-20140819.iso in VirtualBox:

Language selection screen is blank. No languages are shown to select. After next is clicked; Anaconda 21.48-2.1 continues on to Main Hub.

Configuration screen; root; user and progress screens work.
This seems to be unique to KDE installs. 

Fedora-Live-Workstation-x86_64-21-20140819.iso installs correctly in VirtualBox.

Comment 24 satellitgo 2014-08-21 15:27:33 UTC
(In reply to satellit from comment #23)
> Fedora-Live-KDE-x86_64-21-20140819.iso in VirtualBox:
> 
> Language selection screen is blank. No languages are shown to select. After
> next is clicked; Anaconda 21.48-2.1 continues on to Main Hub.
> 
> Configuration screen; root; user and progress screens work.
> This seems to be unique to KDE installs. 
> 
> Fedora-Live-Workstation-x86_64-21-20140819.iso installs correctly in
> VirtualBox.

this did not happen on 3 boots of Fedora-Live-KDE-x86_64-21-20140819  DVD on bare metal. May be an artifact of VirtualBox.

Comment 25 Chris Murphy 2014-08-21 22:16:49 UTC
I'm pretty sure clumens and roshi were not using vbox for testing. Please correct me if I'm wrong. We should find out if this is virtualbox specific. And also test with "nomodeset" and see if that works around the problem or not. I haven't run into this problem on VirtualBox with recent builds, but I've been using it in UEFI mode which uses a different video pipeline both on the linux side as well as through vbox.

Comment 26 Mairi Dulaney 2014-08-21 23:27:37 UTC
I am also not using virtualbox (who in their right mind would?).  However, I have not seen this in a while.

Comment 27 Chris Murphy 2014-08-22 00:49:03 UTC
(In reply to John Dulaney from comment #26)
> I am also not using virtualbox (who in their right mind would?)

The editorialization is not exactly helpful, but am I excused if I say I'm never in my right mind? The test machine is a Mac, and frequently it's easier to test Fedora in vbox than to reboot. I could use vmware or parallels, but vbox is free, so that's the rationalized sequence.

Comment 28 Lars Seipel 2014-08-22 01:49:39 UTC
After it was mentioned on -devel, I just tried to reproduce this using various boot and live images described as showing the problem: no success.

I even tried it on some older Mac (a 2009 model) using Virtualbox (but not UEFI).

Is anyone able to come up with a way to reliably reproduce this issue?

Comment 29 satellitgo 2014-08-23 23:06:27 UTC
Seen in bare metal installs from a Fedora-Live-KDE-x86_64-21-Alpha-TC3.iso DVD with:
1-) System 76  i7 Notebook 
2-) MSI Wind Book i5 (with HDMI Monitor) 

On both  Bios boot is the only option.

The Configuration screen is blank but root and user screens are revealed with a hand cursor. Install finishes in both cases. Blank screen returns with configuration of intrmfs (sp) Note the Anaconda language selection screen works.

Note this is KDE live.

Comment 30 satellitgo 2014-08-23 23:14:07 UTC
(In reply to satellit from comment #29)
> Seen in bare metal installs from a Fedora-Live-KDE-x86_64-21-Alpha-TC3.iso
> DVD with:
> 1-) System 76  i7 Notebook 
> 2-) MSI Wind Book i5 (with HDMI Monitor) 
> 
> On both  Bios boot is the only option.
> 
> The Configuration screen is blank but root and user screens are revealed
> with a hand cursor. Install finishes in both cases. Blank screen returns
> with configuration of intrmfs (sp) Note the Anaconda language selection
> screen works.
> 
> Note this is KDE live.

additional problem:
password selection for user does not show check in [ ] allow user as administrator

Comment 31 satellitgo 2014-08-24 03:01:43 UTC
(In reply to satellit from comment #30)
> (In reply to satellit from comment #29)
> > Seen in bare metal installs from a Fedora-Live-KDE-x86_64-21-Alpha-TC3.iso
> > DVD with:
> > 1-) System 76  i7 Notebook 
> > 2-) MSI Wind Book i5 (with HDMI Monitor) 
> > 
> > On both  Bios boot is the only option.
> > 
> > The Configuration screen is blank but root and user screens are revealed
> > with a hand cursor. Install finishes in both cases. Blank screen returns
> > with configuration of intrmfs (sp) Note the Anaconda language selection
> > screen works.
> > 
> > Note this is KDE live.
> 
> additional problem:
> password selection for user does not show check in [ ] allow user as
> administrator

also saw the screen flickering mentioned in BZ 1133166 in installer screens

Comment 32 satellitgo 2014-10-03 17:00:41 UTC
appeared again in f21-Beta-TC1 KDE-live x86_64 live
 No content in configuration screen. Cursor is hand over root and user spokes.  On return to configuration screen: shows no progress during install

Comment 33 Fedora Blocker Bugs Application 2014-10-03 17:04:20 UTC
Proposed as a Freeze Exception for 21-beta by Fedora user satellit using the blocker tracking app because:

 Installer Configuration screen is blank

Comment 34 Branko Grubić 2014-10-03 17:47:02 UTC
Bug #1142862 is probably same as this one (duplicate?)

Comment 35 Adam Williamson 2014-10-15 17:06:01 UTC
Discussed at 2014-10-15 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-15/f21-blocker-review.2014-10-15-16.04.log.txt . People still seem to be seeing this both here and in #1142862. We're not completely clear on whether they're dupes, but we think they are, so we're going to close that as a dupe of this for now.

We agreed this is sufficiently serious to merit freeze exception status - it doesn't actually seem to prevent installation working, but it can hinder interaction with the installer and cause the user to think install has broken and be concerned or bail out.

Comment 36 Adam Williamson 2014-10-15 17:06:23 UTC
*** Bug 1142862 has been marked as a duplicate of this bug. ***

Comment 37 Petr Schindler 2014-10-29 11:55:56 UTC
I've met this bug with KDE-Live x86_64 Beta RC2.

Comment 38 Adam Williamson 2014-10-30 21:29:13 UTC
Beta is signed off, no point being an AcceptedFE any more. I saw this quite a lot in Beta KDE testing in VMs, to the point that I'm proposing it as a Final blocker, as when you hit it it's quite a bad experience and it's not obvious how to recover. It's OK for a pre-release but really should be cleaned up for final.

Comment 39 David Shea 2014-10-31 15:12:12 UTC
Since this only happens in KDE, I reaaaaly think this is a KDE bug, possibly related to running things in full-screen mode, possibly the same thing that gnome-shell/mutter went through with the progress hub a while back. Some other observations:

- I thought that maybe processing the progress queue was taking too long and not returning to the Gtk main loop, but processing it in a separate thread resulted in the same behavior.
- If I run anaconda with another window (konsole) in the background, I never see this behavior.
- If I start the gtk inspector while the screen is locked up, the screen immediately updates
- If I run anaconda not-fullscreen, I do not see this behavior.

People of Fedora, convince me otherwise: when you see this happen, send SIGUSR2 to the anaconda process and attach the /tmp/anaconda-tb* file that comes out. Thanks.

Comment 40 David Shea 2014-11-03 16:55:28 UTC
Another observation: the GtkSpinner on the progress hub is broken. Like, it's just not there. Something is messed up on KDE's end.

Comment 41 Adam Williamson 2014-11-03 19:30:43 UTC
I seem to be able to reproduce this quite reliably in a freshly-installed KDE VM the *first* time I try to paste something into a terminal on the guest from the host's clipboard by doing shift-ctrl-v. Pasting with middle click doesn't seem to reproduce it, and neither do *subsequent* shift-ctrl-v pastes, but the first into a freshly-installed KDE VM always seems to. So could this be somehow related to the SPICE guest integration?

Comment 42 Adam Williamson 2014-11-05 02:18:44 UTC
We just got a report of this from the MATE-Compiz spin for Beta, which makes it sound like it's not just KDE again. That's https://bugzilla.redhat.com/show_bug.cgi?id=1160484 .

Comment 43 David Shea 2014-11-05 21:40:01 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1160484#c14 contains my latest finger-pointing at GtkSpinner and a possible workaround. If any of y'all could try running with updates=http://dshea.fedorapeople.org/1160484.img and report back I would appreciate it.

Comment 44 David Shea 2014-11-05 22:57:06 UTC
Ok, I just reproduced a non-spinning spinner outside of anaconda in the GNOME live image, so let's blame gtk. Sorry for the noise everyone.

I'll attach the small python script I am using that just makes a window with a GtkSpinner and start it. In the Workstation image it draws the circle for the spinner but does not animate. In KDE I get a blank window. In MATE I get a vertical line.

On my workstation running the rawhide version of gtk from a few months ago (gtk3-3.13.8-0.1.20140818.fc22.x86_64) it worked fine, and it continued to work fine after upgrading to the latest rawhide package (gtk3-3.15.1-1.fc22.x86_64). The live images are using gtk3-3.14.3-2.fc21.x86_64.

I'd still like to know if the anaconda workaround works right for everyone.

Comment 45 David Shea 2014-11-05 22:58:05 UTC
Created attachment 954240 [details]
spinner.py

Comment 46 David Shea 2014-11-05 22:59:50 UTC
*** Bug 1160484 has been marked as a duplicate of this bug. ***

Comment 47 Mike Simms 2014-11-06 10:34:54 UTC
David, update for MATE-Compiz Live ISO patch.

I added the command to the boot entry updates=http://dshea.fedorapeople.org/1160484.img as requested.

Unfortunately it made no difference. The notebook was connected to the router via ethernet LAN and showed a live connection when MATE started. So presumably the update downloaded? I'll attach screenshots and logs again if you believe it necessary.

Comment 48 Kamil Páral 2014-11-06 14:26:03 UTC
I'll add one more comment, it might be related. I've found out that F21 Server installations in VM are extremely slow and hog my host system a lot. After looking closer at it, I've found out that Xorg is constantly consuming at least 60% of CPU, therefore slowing the installation down considerably (at the end of the installation, I can have easily 6-8 minutes of consumed CPU time just by Xorg). Now the main point - Xorg is so heavily utilized only during the installation phase, when the spinner is animated. Once the installation phase is over, the CPU usage is basically zero. This did not happen with F20, and it also does not happen with F21 Workstation, because the spinner is static there.

So, there is clearly something wrong related to the spinner. Not only it causes rendering issues, but when it is properly animated (Server iso), it hogs CPU excessively.

I can provide proper measurements if it helps.

Comment 49 Adam Williamson 2014-11-06 16:42:34 UTC
As it happens I have a bug open on excessive CPU use by GTKSpinner, though for me it seemed tied to NVIDIA graphics:

https://bugzilla.gnome.org/show_bug.cgi?id=732199

Comment 50 Matthias Clasen 2014-11-06 19:20:09 UTC
(In reply to David Shea from comment #45)
> Created attachment 954240 [details]
> spinner.py

that spins just fine here

Comment 51 Matthias Clasen 2014-11-06 19:22:12 UTC
(In reply to Adam Williamson (Red Hat) from comment #49)
> As it happens I have a bug open on excessive CPU use by GTKSpinner, though
> for me it seemed tied to NVIDIA graphics:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=732199

Can we _please_ try not to conflate all the possible GtkSpinner related issues ?

A non-animating spinner is clearly different from an excessively cpu-hungry spinner. They are probably not the same problem - a spinner that isn't animating isn't consuming any cpu, after all...

Comment 52 Matthias Clasen 2014-11-06 20:22:44 UTC
ok, talking to david on irc, here's my theories:

spinner-in-vm issue: gnome disables animations by default when run in a vm, and spinners are affected by that setting

spinner-in-kde issue: Adwaita takes the spinner assets from the Adwaita icon theme. GTK+ always falls back to Adwaita when looking for assets, but it may just not be installed here.

Comment 53 Adam Williamson 2014-11-06 20:30:21 UTC
mclasen: sorry, that was just meant as a side note to kparal as he brought up the issue of excessive CPU use.

To try and reset the various reports we've had, I *think* it's correct to say we have reports of:

* anaconda interface - just the UI! - frequently freezing in KDE live installs, always(?) on the install progress screen
* the same symptom in a MATE live install (#1160484)
* some older reports of the same symptom in Desktop/Workstation/netinst installs, but not since 2014-08-07 AFAICS
* similar behaviour in KDE in VMs outside of the installer (I can trigger this reliably in KDE with no GTK+ apps running)

it seems pretty tricky to figure out exactly how many different actual code bugs we're dealing with here - it's like we have three current cases each of which overlaps in some way with one of the others, but not with both.

Has anyone seen this with a GNOME / Workstation image, or a netinst/DVD install, since August? I have not.

Comment 54 Mike Simms 2014-11-07 00:43:37 UTC
I've identified a solution based on comments about Adwaita in post #52 by Matthais.

The MATE-Compiz spin uses BlueMenta by default and what seems to be DMZ pointer scheme. However Adwaita controls and pointer scheme are on present as well. So I tried the following method and have found it worked on both attempts tonight.

1. Open the System menu from the top panel and then Control Center.
2. Open Appearance.
3. Click 'Customize' under the list of themes.
4. Change 'Controls' to Adwaita and do the same for pointer.
5. Close 'Customize Theme', 'Appearance Preferences' and 'Control Center' to return to the desktop.

Then fire up Anaconda via the 'Install to Hard Drive' icon.

I hope the above helps. Even if it is added to common bugs list as a workaround for now. If the same is possible in KDE it should have a similar outcome.

Comment 55 Adam Williamson 2014-11-07 01:34:10 UTC
That's not a solution, it's a workaround; but it certainly gives us a useful pointer as to where (one of?) the issue(s?) may be. thanks!

Comment 56 Jaroslav Reznik 2014-11-07 12:26:35 UTC
Another observation I have (and it somehow match with adam's comment #41) that if I run KDE live using SPICE/QXL, I run into this bug in half of installations, with VNC/Cirrus, never happened for me. But kparal hit this issue also with bare metal.

I'm going to try workaround mentioned in comment #54 with KDE live and SPICE/QXL.

Comment 57 Matthias Clasen 2014-11-07 13:51:14 UTC
what is the theme on the kde spin, oxygen ?

Comment 58 Matthias Clasen 2014-11-07 14:27:08 UTC
replacing the copy of the old adwaita spinner with the one we have in gtk now gives a working spinner. You can try this in the inspector:


keyframes spin {
  to { -gtk-icon-transform: rotate(1turn);}
}

.spinner {
  background: none;
  -gtk-icon-source: -gtk-icontheme("process-working-symbolic");
}

.spinner:active {
  background: none;
  animation: spin 1s linear infinite;
}


I've asked Benjamin to look at why the old spinner doesn't spin anymore.

Comment 59 Rex Dieter 2014-11-07 14:30:45 UTC
Re: comment #57
> what is the theme on the kde spin, oxygen ?

yes, oxygen.

Comment 60 Matthias Clasen 2014-11-08 17:29:20 UTC
After talking to Benjamin some more, the copy of the old Adwaita css spinner that is in oxygen-gtk now doesn't work anymore because it relied on a background rendering hack that is no longer working. In the short term, I would recommend replacing it by the css that i've included in comment 58 (after making sure that a suitable process-working or process-working-symbolic icon is available.)

Comment 61 Kamil Páral 2014-11-12 17:05:05 UTC
Discussed at today's blocker review meeting [1]. Accepted as a blocker.  This is a conditional violation of the Final Data Corruption criterion since it creates the opportunity of data loss to the user (by making them think the install has hung and the user restarts the machine mid-install). [2]

The decision to whether this must be fixed or at least just documented will depend on how much we see it in future composes testing. We should certainly do as much as we can (e.g. fix the spinners) to make this happen as little as possible.

Re-assigning to oxygen-gtk per comment 60.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-12/
[2] https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Data_corruption

Comment 62 Mike Simms 2014-11-12 17:22:29 UTC
Hello, Sorry to see it has become a release blocking issue.

With regards "Re-assigning to oxygen-gtk"

Please don't discount the fact it happens in MATE-Compiz as well (comments #53 to #55). However, regardless of the specific component this bug gets assigned to, I hope you manage to address the spinner fixes to work on both KDE and MATE-Compiz to minimise disruption.

Comment 63 Rex Dieter 2014-11-12 18:25:54 UTC
Reported upstream,
https://bugs.kde.org/show_bug.cgi?id=340901

Comment 64 Fedora Update System 2014-11-12 18:55:05 UTC
oxygen-gtk3-1.4.1-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/oxygen-gtk3-1.4.1-2.fc21

Comment 65 Kamil Páral 2014-11-13 09:44:01 UTC
Can somebody knowledgeable please find out which component we need to fix in MATE-Compiz in order to fix the spinner? Thanks.

Comment 66 Mike Simms 2014-11-13 10:47:57 UTC
@Kamil - I've sent a message to raveit65 who builds and maintains the MATE-Compiz packages requesting their help to identify the correct specific component.

Comment 67 Wolfgang Ulbrich 2014-11-13 11:44:00 UTC
about mate spin,
i did yesterday build a local live image with 'updates-testing' enable, and i see no missing gui element in anaconda.
Final version for mate-themes for release is 1.9.2-0.1.git20141108.66e3797.fc21, which is  latest snapshot from upstream development.
http://koji.fedoraproject.org/koji/buildinfo?buildID=591739
I'm pretty shure you did use an older version.
The spinner code is updated in our themes, see
https://github.com/mate-desktop/mate-themes/blob/master/desktop-themes/BlueMenta/gtk-3.0/gtk-widgets.css#L157

Comment 68 Kamil Páral 2014-11-13 12:41:03 UTC
(In reply to Wolfgang Ulbrich from comment #67)
> I'm pretty shure you did use an older version.

Only stable updates are used when building test composes. Please make sure the update hits stable updates repo if you want to see the bug fixed in MATE spin (assuming it helps). Thanks!

Comment 69 Wolfgang Ulbrich 2014-11-13 12:41:58 UTC
same results with TC2 on f20 qemu/spice/qxl

Comment 70 Wolfgang Ulbrich 2014-11-13 12:44:34 UTC
(In reply to Kamil Páral from comment #68)
> (In reply to Wolfgang Ulbrich from comment #67)
> > I'm pretty shure you did use an older version.
> 
> Only stable updates are used when building test composes. Please make sure
> the update hits stable updates repo if you want to see the bug fixed in MATE
> spin (assuming it helps). Thanks!

all done ;) https://admin.fedoraproject.org/updates/FEDORA-2014-14686/mate-themes-1.9.2-0.1.git20141108.66e3797.fc21?_csrf_token=5818eb7b864ca6014d86730f3a15aca8474730ec
Mike test was with beta4.

Comment 71 Mike Simms 2014-11-13 12:58:29 UTC
Kamil & Wolfgang - I've just tested booting from Beta-4 and applying updates listed below from stable repo via yumex. anaconda works fine. Thanks again Wolfgang.

mate-themes-1.9.2-0.1.git20141108.66e3797.fc21
and dependency gtk-unico-engine 1.0.3.0.5.20140109bzr152.fc21

So confirmation it is resolved for MATE-Compiz in stable.

Comment 72 Mike Simms 2014-11-13 16:55:28 UTC
Just tried out http://alt.fedoraproject.org/pub/alt/stage/21_TC2/Live/i386/Fedora-Live-MATE_Compiz-i686-21-TC2.iso

this build contains the necessary update and anaconda works 100% as expected.

Thanks all.

Comment 73 Fedora Update System 2014-11-13 18:15:56 UTC
Package oxygen-gtk3-1.4.1-2.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing oxygen-gtk3-1.4.1-2.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-14918/oxygen-gtk3-1.4.1-2.fc21
then log in and leave karma (feedback).

Comment 74 Fedora Update System 2014-11-15 09:14:04 UTC
Package oxygen-gtk3-1.4.1-3.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing oxygen-gtk3-1.4.1-3.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-14918/oxygen-gtk3-1.4.1-3.fc21
then log in and leave karma (feedback).

Comment 75 Fedora Update System 2014-11-18 12:18:50 UTC
oxygen-gtk3-1.4.1-3.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 76 Kamil Páral 2014-11-18 12:56:36 UTC
Reopening. Since this was a blocker, we will want to confirm that this is indeed fixed. We will probably need to wait for TC3 with that, at least with KDE. Or a nightly build.

Comment 77 Leslie Satenstein 2014-11-18 16:28:55 UTC
Using the server net-install beta of Nov 13th, with that included version of Anaconda, the 30-90 second lockup occurs after each spoke selection, but not while within a spoke.

As an aside, if opening up Anaconda for the fix, at least have it report the correct timezone as a default value.  (I am not in Winnipeg timezone, but in New York/Toronto timezone) (Anaconda is off by one timezone.)

Fedora-Server-netinst-x86_64-21_TC2.iso

If relevant, my system has 8 gigs memory, dual core E7300 Pentium X64 version

Comment 78 Kamil Páral 2014-11-20 15:07:34 UTC
I have performed a dozen of KDE installations with Fedora-Live-KDE-x86_64-21-20141119.iso nightly, on two bare metal machines and in a VM, and this issue seems to be gone, I haven't seen it once. The spinner is working and the Root and User spokes are visible and don't disappear.

Unfortunately, I've found also some issues:
* The spinner makes Xorg consume 75% of CPU, which is insane. (bare metal testing)
* On an AMD graphics card with radeon driver, the progress bar and its description sometimes refreshes with a delay, e.g. only once per 30-60 seconds. Disabling compositing doesn't help. But I haven't seen this elsewhere, and it also didn't happen with a vesa/efifb driver, so this seems specific really to radeon+KDE. Also might be partly caused by the issue above.

So, I'm closing this issue, it seems fixed. If you see it Root+Password spokes disappearing in anaconda again, please reopen. If you see KDE screen freeze bug, please report a new bugzilla ticket, it's most probably unrelated to this. Thanks.


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