Comment 4 for bug 1385089

On Sat, Oct 25, 2014 at 01:01:17AM -0000, diehard67 wrote:
> the only changes were to work around this, adding sleep 2 before exec
> lightdm in /etc/init/lightdm.conf

> I know lightdm.conf calls plymouth quit before running lightdm itself

Except that it doesn't do that at all. It only calls 'plymouth quit'
explicitly when either 'text' has been passed on the kernel commandline (an
option that's used to suppress the graphical login and give users a text
login only), or if the target runlevel for the system is single user mode
(and I'm not sure why it does this at all, that may be a bug).

> but I suspect it is not done quitting when lightdm starts running.

And that's fine, because what lightdm does is call 'plymouth quit
--retain-splash' internally before it launches the X server. This should
work reliably unless there is something causing plymouth to be started only
/after/ lightdm gets to this point.

> truth be told I have no idea what to look at or how to get more info, if
> there some way to get plymouth, lightdm, x and the kernel to give me
> detailed logs during boot?????

You can get debugging logs out of plymouth by booting with
<plymouth:debug=file:/var/log/plymouth-debug.log>. X and lightdm logs are
already available under /var/log/lightdm, and the kernel log is at
/var/log/kern.log.

It would indeed be helpful if you could attach these logs corresponding to a
boot that exhibited the problem.

> I should also mention my sisters netbook is not a particularly fast system
> asus eeepc x101ch

Machine specifications should not matter here, except to the extent that a
slower machine will have a bigger window in which a race can happen.

> GRUB_CMDLINE_LINUX="i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.semaphores=1"

However, I wonder about this. This is an awful lot of module options
overriding the default behavior of the graphics card; I can certainly see
this triggering bugs in the plymouth/lightdm hand-off. Do you know why
these options are here? What happens when booting without these options?

> rc.local
> #!/bin/sh
[...]
> killall plymouthd

This certainly concerns me. Was this added *only* to work around the lack
of keyboard in the greeter? That's certainly not the expected way to shut
down plymouthd, and using 'killall' to end the process definitely *does*
have a race because signals are asynchronous. At minimum, you should be
using 'service plymouth stop' to ensure plymouth is actually stopped before
you then try to start lightdm...