If you just sit there and wait, it will eventually complete and then redraw.  Pretty weird.

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

(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"

*** Bug 1104535 has been marked as a duplicate of this bug. ***

(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

*** Bug 1105427 has been marked as a duplicate of this bug. ***

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.

*** Bug 1114217 has been marked as a duplicate of this bug. ***

Are people still seeing this? It has stopped doing it for me with the current nightly and my local boot.iso builds.

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.

Created attachment 917190 [details]
Storage log

Created attachment 917191 [details]
program.log

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

Created attachment 917192 [details]
packaging.log

Created attachment 917193 [details]
ifcfg.log

Created attachment 917194 [details]
anaconda.log

Rootfs not mounting is another issue; looks like the initramfs is not building correctly.

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

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.

Saw this during installation of Fedora-Live-x86_64-21-20140807.iso.

Also seen in Fedora-Live-KDE-x86_64-21-20140805.iso

(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)

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

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.

(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.

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.

I am also not using virtualbox (who in their right mind would?).  However, I have not seen this in a while.

(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.

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?

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.

(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

(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

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

Proposed as a Freeze Exception for 21-beta by Fedora user satellit using the blocker tracking app because:

 Installer Configuration screen is blank

Bug #1142862 is probably same as this one (duplicate?)

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.

*** Bug 1142862 has been marked as a duplicate of this bug. ***

I've met this bug with KDE-Live x86_64 Beta RC2.

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.

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.

Another observation: the GtkSpinner on the progress hub is broken. Like, it's just not there. Something is messed up on KDE's end.

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?

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 .

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.

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.

Created attachment 954240 [details]
spinner.py

*** Bug 1160484 has been marked as a duplicate of this bug. ***

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.

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.

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

(In reply to David Shea from comment #45)
> Created attachment 954240 [details]
> spinner.py

that spins just fine here

(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...

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.

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.

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.

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!

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.

what is the theme on the kde spin, oxygen ?

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.

Re: comment #57
> what is the theme on the kde spin, oxygen ?

yes, oxygen.

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.)

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

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.

Reported upstream,
https://bugs.kde.org/show_bug.cgi?id=340901

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

Can somebody knowledgeable please find out which component we need to fix in MATE-Compiz in order to fix the spinner? Thanks.

@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.

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

(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!

same results with TC2 on f20 qemu/spice/qxl

(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.

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.

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.

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).

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).

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.

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.

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

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.