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... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1385089 Title: keyboard sometimes doesn't respond at login To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1385089/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
