Bug 704658

Created attachment 498865 [details]
plymouth debug log

Created attachment 498866 [details]
screenshot of "hang"

Probably not really news, but I've established that gdm is stuck waiting on
"/bin/plymouth quit --retain-splash" to return.

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

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.

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.

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.

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?

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

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

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

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.

Ray - Any thoughts on the patch?

This issue is still present in F16, and Ian's patch resolves it.

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" :)

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

FWIW, Ian's patch resolves this issue. I am not sure why Ray hasn't committed it.

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

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.

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

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

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

Thanks spot for pushing this.

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.

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! :)

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

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

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.

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.