Bug 704658 - gdm doesn't start properly when spinfinity theme is used
gdm doesn't start properly when spinfinity theme is used
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-13 17:30 EDT by Ian Pilcher
Modified: 2012-08-09 19:17 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-26 18:38:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
plymouth debug log (142.53 KB, text/plain)
2011-05-13 17:31 EDT, Ian Pilcher
no flags Details
screenshot of "hang" (3.58 KB, image/png)
2011-05-13 17:32 EDT, Ian Pilcher
no flags Details
Backtrace showing call to ply_event_loop_exit when charge theme is used (3.24 KB, text/plain)
2011-05-16 15:11 EDT, Ian Pilcher
no flags Details
Patch to pull idle trigger right away if already idle (1.00 KB, patch)
2011-05-16 19:56 EDT, Ian Pilcher
no flags Details | Diff

  None (edit)
Description Ian Pilcher 2011-05-13 17:30:50 EDT
Description of problem:
When the plymouth "spinfinity" theme is selected (and initramfs is rebuilt),
the gdm login screen is never displayed.

The spinfinity graphical boot itself does display properly.  The screen then
turns black and the X "spinny mouse pointer" appears, but gdm never draws
the background or anything else.  (I will attach a very unexciting screenshot.)

getty is not running on any VT, but the system is accessible via ssh.
systemctl shows that everything is waiting on plymouth-quit-wait.service:

[root@new-host-5 ~]# systemctl list-jobs --full
  95 plymouth-quit-wait.service start           running
  96 getty.target              start           waiting
  97 getty@tty5.service        start           waiting
 101 getty@tty4.service        start           waiting
 103 getty@tty6.service        start           waiting
 105 getty@tty2.service        start           waiting
 107 getty@tty3.service        start           waiting

ps shows:

[root@new-host-5 ~]# ps ax | grep plymouth
  150 ?        S      0:08 /bin/plymouthd --attach-to-session --pid-file /run/plymouth/pid
  980 ?        Ss     0:00 /bin/plymouth --wait
 1116 ?        S      0:00 /bin/plymouth quit --retain-splash

(PID 1116 is a child of gdm.)

By attaching to the processes with gdb, I've been able to determine that all
3 processes are in epoll_wait.

I was also able to use gdb to capture the plymouth debug log, which I will
attach.

Version-Release number of selected component (if applicable):
plymouth-0.8.4-0.20110427.1.fc15.x86_64
Comment 1 Ian Pilcher 2011-05-13 17:31:40 EDT
Created attachment 498865 [details]
plymouth debug log
Comment 2 Ian Pilcher 2011-05-13 17:32:27 EDT
Created attachment 498866 [details]
screenshot of "hang"
Comment 3 Ian Pilcher 2011-05-14 12:57:21 EDT
Probably not really news, but I've established that gdm is stuck waiting on
"/bin/plymouth quit --retain-splash" to return.
Comment 4 Ian Pilcher 2011-05-16 12:52:59 EDT
I have been able to reproduce this problem in a "non-boot" environment, in a
KVM guest.

PREPARE THE KVM GUEST

1. Create a KVM guest running 64-bit Fedora 15 (on a Fedora 15 host).  Ensure
   that the packages required for a plymouth graphical boot are installed.
   (Installing from a "live CD" ISO will get the required packages.)

2. Enable root ssh logins to the guest by enabling sshd and editing the
   iptables rules (or disabling iptables entirely).  It may also be useful
   to set a fixed IP address.

3. Edit /boot/grub/grub.conf and add "vga=792" to the kernel command line.

4. Apply all updates:

   yum -y update

5. Install the spinfinity theme:

   yum -y install plymouth-theme-spinfinity

6. Disable getty on tty1:

   rm -f /etc/systemd/system/getty.target.wants/getty@tty1.service

7. Change the default runlevel to disable gdm:

   ln -sf /lib/systemd/system/runlevel3.target \
      /etc/systemd/system/default.target

8. Reboot.  The charge theme should be displayed during boot, followed by a
   black screen.

VERIFY THAT THE CHARGE THEME WORKS:

1. In two separate windows (henceforth known as "Session A" and "Session B"),
   ssh to the guest as root.

2. (Session A) plymouthd --attach-to-session --pid-file /run/plymouth/pid

3. (Session A) plymouth --show-splash

4. Wait for the animation to mostly complete.

5. (Session A) plymouth deactivate

6. (Session A) plymouth --wait

7. (Session B) plymouth quit --retain-splash

The "plymouth --wait" command should return when "plymouth quit ..." is issued
in the other window.  ps should show that plymouthd is no longer running.

REPRODUCE THE PROBLEM WITH THE SPINFINITY THEME:

1. (Session A) plymouth-set-default-theme spinfinity

2. Repeat steps 2 - 7 from the previous section.

This time, neither the "plymouth quit ..." command or the "plymouth --wait"
command will return.
Comment 5 Ian Pilcher 2011-05-16 15:11:43 EDT
Created attachment 499213 [details]
Backtrace showing call to ply_event_loop_exit when charge theme is used

ply_event_loop_exit is not getting called when the spinfinity theme is used.

The attached backtrace shows the call to ply_event_loop_exit when the charge
theme is used.
Comment 6 Ray Strode [halfline] 2011-05-16 15:19:47 EDT
In step 4 you say "Wait for the animation to mostly complete".  Does the animation not fully complete?

Quit is deferred until the animation finishes.
Comment 7 Ray Strode [halfline] 2011-05-16 15:24:19 EDT
do you mind breaking on the on_timeout function and seeing if animate_at_time is returning false when it finishes the last iteration of the throbber loop following deactivate?
Comment 8 Ian Pilcher 2011-05-16 16:04:20 EDT
(In reply to comment #6)
> In step 4 you say "Wait for the animation to mostly complete".  Does the
> animation not fully complete?

I'm an impatient sort, so I'm not sure.  It sort of slows down at the end,
I assume because the daemon isn't receiving the "update" messages that it
normally gets from systemd.

> Quit is deferred until the animation finishes.

Deactivate causes it to finish, right?
Comment 9 Ian Pilcher 2011-05-16 16:31:28 EDT
(In reply to comment #7)
> do you mind breaking on the on_timeout function and seeing if animate_at_time
> is returning false when it finishes the last iteration of the throbber loop
> following deactivate?

I'm not sure if this is exactly what you were looking for, but I set a break-
point at ply-throbber.c:191:

  if (!should_continue)
    {
      throbber->is_stopped = true;           <========== BREAKPOINT
      if (throbber->stop_trigger != NULL)
        {

I hit this breakpoint exactly once when I issued the "plymouth deactivate"
command, so it looks like animate_at_time must be returning false.
Comment 10 Ray Strode [halfline] 2011-05-16 17:11:09 EDT
oh indeed, looking at your log there's this:

[main.c]                           on_boot_splash_idle:boot splash idle

so your gdb-fu and the log agree, it's finishing the animation okay and then finishes deactivating.

[ply-boot-server.c]            ply_boot_connection_on_deactivated:deactivated

So now it's sitting on a good frame ready to quit and then gets the quit request:

[ply-boot-server.c]                ply_boot_connection_on_request:got quit --retain-splash request

and then...

[ply-boot-splash.c]                   ply_boot_splash_become_idle:telling splash to become idle

What? it's trying to make it become idle again?  Weird.

The throbgress plugin (which is the code behind the spinfinity theme) doesn't notice it's already idle though and instead just blocks indefinitely when told to become idle twice.

Contrast this with the two-step plugin (which is the code behind the stock theme) which explicitly checks if it's idle already on become_idle and fires the trigger immediately in that case.

Looking in the history I see:

commit eed536ba544dee38aee3c697efd2e3980362954a
Author: Ray Strode <rstrode@redhat.com>
Date:   Mon May 4 17:17:36 2009 -0400

    [two-step] pull trigger right away if already idle
    
    The trigger always needs to get pulled so that the
    daemon knows that it can quit.  Previously, we weren't
    pulling it if two-step was already idle.  This meant that
    plymouthd never quit.

So apparently I fixed this a couple of years ago in two-step and didn't fix comparable code in throgress (i don't really have any memory of this commit though and I didn't list a bug link in the commit for context, unfortunately)
Comment 11 Ian Pilcher 2011-05-16 19:56:42 EDT
Created attachment 499246 [details]
Patch to pull idle trigger right away if already idle

The attached patch is my attempt at "porting" the idle trigger stuff into the
throbgress plugin.  It does indeed allow gdm/kdm to start properly when the
spinfinity theme is used.
Comment 12 Ian Pilcher 2011-06-21 14:39:48 EDT
Ray - Any thoughts on the patch?
Comment 13 Tom "spot" Callaway 2011-10-01 18:51:21 EDT
This issue is still present in F16, and Ian's patch resolves it.
Comment 14 Xavier Hourcade 2012-01-29 11:11:36 EST
Hi all, I've just experienced this too under F16 KDE
(up to date, first attempt to apply spinfinity).

A simple workaround here: just pressed Esc during spinfinity animation, *before* it completes. Then KDM welcome screen appears, ttys are available and all is fine.

This defeats its purpose, thou, hence I reverted to "charge" :)
Comment 15 Xavier Hourcade 2012-01-29 14:36:56 EST
More info: spinfinity hang may cause overheat

My previous comment was with nouveau driver -- GeForce 8600M GT (Asus V1S laptop) is, besides, subject to the infamous overheat issue (see eg. nvidiadefects.com), forcing to keep "a very low profile" using nouveau (that means : dual displays, full screen video or VM even with a single display = kernel overheat shutdown).

Switched to proprietary driver (kmod-nvidia @rpmfusion-nonfree), which solves this (that means: even flash video can play full screen on external display, no overheat, as it used to be with F14 where spinfinity was working fine, too).

Then, trying spinfinity again:

* If letting it go, nVidia splash screen shows up, then black screen.
  New: it brings instant overheat -> shutdown
  And it now seems to be the only situation where overheats may occurs here.

* If pressing Esc, boot process continue as with nouveau... almost.
  New: it leads to a tied loop where endless atd errors are printed on screen
  (these messages are not new, distinct issue #718422, but the tied loop *is* new)
  Magic keys (Alt+SysRq) did let me complete the boot process.

Reverted to "charge" theme, all is fine again from a user perspective
(even if the unrelated atd error is not yet fixed on this system).
Comment 16 Tom "spot" Callaway 2012-01-30 10:49:09 EST
FWIW, Ian's patch resolves this issue. I am not sure why Ray hasn't committed it.
Comment 17 Mattia M. 2012-03-27 03:15:10 EDT
(In reply to comment #0)
> Description of problem:
> When the plymouth "spinfinity" theme is selected (and initramfs is rebuilt),
> the gdm login screen is never displayed.
> 
> The spinfinity graphical boot itself does display properly.  The screen then
> turns black and the X "spinny mouse pointer" appears, but gdm never draws
> the background or anything else.

I noticed this issue on my Fedora 16, too.
Any news about the patch that should resolve it? Thanks.
Comment 18 D. Charles Pyle 2012-07-15 21:59:46 EDT
I can confirm that the same thing happens to me on a clean install of Fedora 17.

I get the same message as above cannot get past a black screen, with the same behavior requiring pressing the power button.

Switching to another plymouth theme allows logon but not spinfinity.

I also get a message stating that there is a problem with fglrx acceleration but this only occurs when the plymouth theme spinfinity runs at boot time. None of the others do it.

Weirdly, I end up with the open source radeon driver loading before fglrx even though the radeon module is blacklisted. This only happens with spinfinity, though. I do not have this problem with any of the other plymouth themes.

I am running the ATi/AMD proprietary driver version 12.6.
Comment 19 Fedora Update System 2012-07-23 10:46:52 EDT
plymouth-0.8.5-0.2012.04.27.2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/plymouth-0.8.5-0.2012.04.27.2.fc17
Comment 20 Fedora Update System 2012-07-23 10:47:10 EDT
plymouth-0.8.4-0.20110822.5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/plymouth-0.8.4-0.20110822.5.fc16
Comment 21 Fedora Update System 2012-07-23 16:21:13 EDT
Package plymouth-0.8.4-0.20110822.5.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing plymouth-0.8.4-0.20110822.5.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10993/plymouth-0.8.4-0.20110822.5.fc16
then log in and leave karma (feedback).
Comment 22 Ray Strode [halfline] 2012-07-23 17:50:28 EDT
Thanks spot for pushing this.
Comment 23 D. Charles Pyle 2012-07-24 08:31:17 EDT
Many thanks. That seems to have fixed the problems. I did not want to wait for it to go into the repositories so I downloaded from the provided links and ran rpm -Uvh --force ~/Downloads/plymouth/plymouth-*.rpm in a terminal.

I then set the default theme to spinfinity, rebuilt initramfs, and configured Grub2.

Note: I have found that I have to do that last item or I end up with an extra menu item on the Grub2 menu listing the current kernel installed in addition to and above the normal "Fedora" menu item that should be at the top of the menu.

Thanks again! I am happy to have spinfinity back.
Comment 24 Xavier Hourcade 2012-07-24 10:21:19 EDT
Solved here to, thanks!

Tested spinfinity theme only on F16 with kmod-nvidia driver and kdm (KDE spin, and I cannot test nouveau on this hardware).

NB. Updating plymouth alone (as in comment #21) did not bring lib and theme updates as dependencies, hence did *not* solve the issue for me.

Updated the theme package, which then *did* bring all deps :

# su -c 'yum update --enablerepo=updates-testing plymouth-theme-spinfinity-0.8.4-0.20110822.5.fc16.x86_64'

What is now installed here :

# yum lsi | grep -E "kernel\.|kmod-nvidia\.|plymouth"
kernel.x86_64                      3.4.4-4.fc16       @updates                    
kmod-nvidia.x86_64                 1:295.59-1.fc16.3  @rpmfusion-nonfree-updates  
plymouth.x86_64                    0.8.4-0.20110822.5.fc16  @updates-testing
plymouth-core-libs.x86_64          0.8.4-0.20110822.5.fc16  @updates-testing
plymouth-graphics-libs.x86_64      0.8.4-0.20110822.5.fc16  @updates-testing
plymouth-plugin-label.x86_64       0.8.4-0.20110822.5.fc16  @updates-testing
plymouth-plugin-throbgress.x86_64  0.8.4-0.20110822.5.fc16  @updates-testing
plymouth-plugin-two-step.x86_64    0.8.4-0.20110822.5.fc16  @updates-testing
plymouth-scripts.x86_64            0.8.4-0.20110822.3.fc16  @updates-testing
plymouth-system-theme.x86_64       0.8.4-0.20110822.5.fc16  @updates-testing
plymouth-theme-charge.x86_64       0.8.4-0.20110822.5.fc16  @updates-testing
plymouth-theme-spinfinity.x86_64   0.8.4-0.20110822.5.fc16  @updates-testing

Listed available themes
# plymouth-set-default-theme -l

Applied spinfinity, rebuilding initramfs
# plymouth-set-default-theme spinfinity -R

Regenerated grub menu
# grub2-mkconfig -o /boot/grub2/grub.cfg

And finally...
# reboot

Spinfinity is resurected. Houra! Long life to spinfinity! :)
Comment 25 Ray Strode [halfline] 2012-07-24 10:43:48 EDT
I believe we explicitly didn't have a Requires: plymouth in the plugin subpackages because of some odd dependency loops it imposed that made the transaction order wrong, though I'm a little vague on the details.

These days lower level components like kernel and dracut no longer Requires: plymouth themselves, so I think all the weird ordering problems that caused, should no longer be an issue, so I've pushed the Requires back in
Comment 26 Mattia M. 2012-07-25 15:16:17 EDT
(In reply to comment #24)
> 
> NB. Updating plymouth alone (as in comment #21) did not bring lib and theme
> updates as dependencies, hence did *not* solve the issue for me.
> 
> Updated the theme package, which then *did* bring all deps :
> 
> # su -c 'yum update --enablerepo=updates-testing
> plymouth-theme-spinfinity-0.8.4-0.20110822.5.fc16.x86_64'

The same for me on Fedora 17 x86_64. Updating plymouth alone does not trigger the update of plymouth-theme-spinfinity.
Comment 27 Fedora Update System 2012-07-26 18:38:51 EDT
plymouth-0.8.5-0.2012.04.27.2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 28 Fedora Update System 2012-08-09 19:17:36 EDT
plymouth-0.8.4-0.20110822.5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

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