lightdm tries (and fails) to start too early?

In case I wasn't clear, here is the window that pops up about half the times that I boot.

When this comes up, I hop to a tty, log in, and do 'start lightdm'. Then I have the bad X on :0 (with log files showing it tried to modprobe 'nv'), and the good X which I just started on :1.

When I don't get this popup, then lightdm/X start just fine and are running on :0.

Status changed to 'Confirmed' because the bug affects multiple users.

I see this with Intel Sandy Bridge as well (i7). Either the low graphics warning or just blank screen. Manually starting lightdm always helps.

In the /etc/init/lightdm.conf file adding some delay before executing lightdm solves the problem for me:

    sleep 10
    exec lightdm

This way I can also see the Ubuntu boot screen with the progress bar which I never saw before. It was just the plain background color flashing a couple of times quickly (I have an SSD drive) and after that in the lucky cases the login screen showed up, other cases I had to start lightdm manually.

Quoting Miklos Juhasz (<email address hidden>):
> In the /etc/init/lightdm.conf file adding some delay before executing
> lightdm solves the problem for me:
>
> sleep 10

unacceptable on a 5 second boot :)

> exec lightdm
>
> This way I can also see the Ubuntu boot screen with the progress bar
> which I never saw before. It was just the plain background color
> flashing a couple of times quickly (I have an SSD drive) and after that

Right, I have an SSD drive as well. That's why I thought perhaps lightdm
needs another required event to ensure the nvidia kernel module has
finished loading.

I get this with fglrx and intel driver as well. It seems that there's some race condition in the upstart scripts and the graphic card is not ready yet.

My desktop machine became virtually unbootable with a fast SSD so 10s (actually 5s is enough) delay was the only way to make it work. I can press Ctrl+Alt+F1 and log in and start lightdm by hand but others family members can't... so they have to wait a few more seconds.

Dupe of bug #982889 for Intel.

For nvidia/fglrx, we've had numerous reports (the issue seems more widespread with binary drivers).

Comment #5 is just a workaround, but that's essentially what's needed - pause X startup until the kernel driver is ready. Question is how to best do that...

Here is the start on:

start on ((filesystem
           and runlevel [!06]
           and started dbus
           and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                or stopped udev-fallback-graphics))
          or runlevel PREVLEVEL=S)

I suspect drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 or stopped udev-fallback-graphics is emitting too soon.

here is udev-fallback-graphics:

start on (startup and
   (graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY=1
           or drm-device-added PRIMARY_DEVICE_FOR_DISPLAY=1
           or stopped udevtrigger or container))

That bare 'card0' on the drm-device-added event is quite puzzling. Is it possible that it is simply matching as 'drm-device-added' and a second, non primary graphics chip is causing the issue? That might explain it. The timeline for these events is pretty complex so it will likely take some deep thought.

Nothing in the upstart man pages suggests this syntax, event, bareword, variable, is valid or what it might mean. It seems to have been cargo culted to KDM as well, and come from gdm in lucid originally.

Can somebody who is affected try removing 'card0' and see if that fixes the problem?

I suspect this might be related to bug #936552 which also has to do with lightdm seemingly starting too soon.

Hm the card0 thing doesn't seem to make a difference in my trackpad bug.

However, adding 'and stopped udevtrigger' *does* solve that problem. So can somebody who is affected try adding that ? as in, make /etc/init/lightdm.conf's start on:

start on ((filesystem
           and runlevel [!06]
           and started dbus
           and stopped udevtrigger
           and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                or stopped udev-fallback-graphics))
          or runlevel PREVLEVEL=S)

My theory is that the udev drm-device-added event is not being seen because the kernel has already sent it by the time we get to this point, since the boot speed is so fast.

For 12.10, we really should add a 'primary-graphics-card' event alias or abstract job that abstracts the udev complexities since that confusing condition ("drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 or stopped udev-fallback-graphics") is also semi-duplicated in other jobs:

- plymouth-splash.conf
- udev-fallback-graphics.conf

I think the "definitive" condition that becomes true when the first graphics device becomes available is:

(graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY=1
    or drm-device-added PRIMARY_DEVICE_FOR_DISPLAY=1
    or stopped udev-fallback-graphics)

I agree that 'card0' seems bogus - looks like it's trying to match DEVPATH but that will never match since there is no wildcard in the expression. It should be something like the following (note the asterisk after the equals!!):

    drm-device-added DEVPATH=*card0 PRIMARY_DEVICE_FOR_DISPLAY=1

Using named variables ('name=value' as opposed to positional ones where only a *value* is given) as I've done above is *much* safer in this scenario since to use positional variables, you need to know the exact content of the corresponding udev message that the upstart-udev-bridge converts into an Upstart event.

File /lib/udev/rules.d/78-graphics-card.rules is what is modifying the udev message to add PRIMARY_DEVICE_FOR_DISPLAY=1 so I'm wondering if we can simplify the logic to be simply:

    drm-device-added PRIMARY_DEVICE_FOR_DISPLAY=1

... since udev will tag both KMS and non-KMS devices correctly.

> However, adding 'and stopped udevtrigger' *does* solve that problem.

Based on 10 restarts I can confirm that. Either it does solve the problem or it just delays lightdm with the right amount of time.

So far, adding 'and stopped udevtrigger' seems to be working for me as well.

Any chance of getting that into precise's lightdm yet?

uploads for precise are pretty frozen, that could be in the first SRU though, could somebody come with a merge request with the change?

I'm getting the same symptom - more often than not getting dropped to the low-graphics alert during startup - and the change to /etc/init/lightdm.conf listed above has *not* made a difference. This behaviour is consistent across several different machines. From googling around this bug seems fairly prevalent, and is graphics vendor/chipset agnostic which supports your reasoning above. However as noted the prooposed change hasn't helped me.

Looking through logs in /var/log/lightdm the only thing that stands out is in the greeter logs e.g. for a failed start:
No protocol specified
No protocol specified
...
(unity-greeter:2340): Gtk-WARNING **: cannot open display: :0
No protocol specified
...

I'm happy to try out other ideas for fixes as this is a show stopper for a desktop environemnt refresh under way at work.

This looks like it might be a duplicate of bug 615549.

I've done some digging and although I'm not sure this will fully resolve the issue observed, I have found a bug in lightdm.conf which could cause the behaviour seen...

As Clint intimates in #11, the current 'start on' condition...

    drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1

... is *NOT* valid. What this condition is asking Upstart to do is match on an event whose first _positional_ environment variable *exactly matches* the string 'card0' and which also has an environment variable called 'PRIMARY_DEVICE_FOR_DISPLAY' with value '1'.

However, if you look at /var/log/udev:

$ awk 'BEGIN{RS="";ORS="\n\n"}; /UDEV *\[/ && /PRIMARY_DEVICE_FOR_DISPLAY=1/ { print; }' /var/log/udev
UDEV [34.559987] add /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 (drm)
ACTION=add
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
DEVTYPE=drm_minor
MAJOR=226
MINOR=0
PRIMARY_DEVICE_FOR_DISPLAY=1
SEQNUM=2231
SUBSYSTEM=drm
TAGS=:udev-acl:
UDEV_LOG=3
USEC_INITIALIZED=34559916
$

... you'll see that there are no variables that exactly match 'card0'! The fix is as simple as adding an asterisk to perform a wild-card match:

  drm-device-added *card0 PRIMARY_DEVICE_FOR_DISPLAY=1

However, my preference would to make our intent explicit and say:

  drm-device-added DEVPATH=*card0 PRIMARY_DEVICE_FOR_DISPLAY=1

This would protect against a change to the way the upstart-udev-bridge handles udev environment variable ordering and is much easier to understand.

@serge - could you add the missing asterisk and report back?

Addendum to #19:

Currently the 'card0' matching is being attempted on DEVPATH. This isn't obvious from the /var/log/udev extract shown, but the upstart-udev-bridge will in this scenario create the event with the following environment variable ordering:

1) DEVPATH
2) DEVNAME
3) SUBSYSTEM
4) ACTION
5) <<the rest>>

So if in doubt, prefer name=value pairs to positional variables.

Please could those affected attach /var/log/udev?

Changing 'card0' to 'DEVPATH=*card0' seems to have fixed the problem for me, at least across a half dozen reboots.

Udev log attached.

Same issue 01-06-12 fully updated system (gnome remix based on ubuntu)
Hardware HP ProBook Sandybridge I3
Intel 3000
Intel SSD
Boottime 8 sec.

sometimes (one out of ten) the xserver freezes at login

adding 'and stopped udevtrigger to lightdm.conf fixes the issue.

 lightdm.conf looks now like this:

start on ((filesystem
           and runlevel [!06]
           and started dbus
           and stopped udevtrigger #this line I added
           and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                or stopped udev-fallback-graphics))
          or runlevel PREVLEVEL=S)

Best regards,

Otto Meijer

Just an update that I still get this very infrequently - maybe once a week across many reboots of several machines - post applying the 'DEVPATH=*card0' fix.

Same here. DEVPATH=*card0 and still having the issue.

I'm using 12.10 and am seeing the same log messages as Lincoln reported in #18. I have used both Intel and Nvidia chipsets and the issue seems to occur in both.

A couple of things I have tried:

* Removing 'card0' from the PRIMARY_DEVICE_FOR_DISPLAY line
* Adding 'and stopped udevtrigger' as above
* Adding 'sleep 10' before lightdm is executed

So far only adding a sleep has helped, although it is not 100% effective.

I've had a look at /var/log/udev and there are no PRIMARY_DEVICE_FOR_DISPLAY lines, so am I right in thinking that once udev-fallback-graphics stops, lightdm will try to start? To me, it seems like something is still not ready at the time that LightDM runs.

All,

There is a lot more heat in #1066410 but not as much progress as I've seen here. I've suggested that #1066410 is marked as a duplicate of this ticket and those people come here and mark it as affecting them also.

I've tried adding "and stopped udevtrigger" and "sleep x" and both work more often than not but it is still unreliable.

Same issue with me on Ubuntu 12.10 x64 with the following hardware :-

Intel Core i3-3225 (w/HD 4000)
8GB Corsair Vengeance DDR3-1866
ASRock H77M-ITX motherboard
Corsair F40 40GB SSD

On most cold boots now LightDM is failing to start, and will just display the standard display reconfigure message (which obviously doesn't actually do anything other than boot you to a terminal)

I have to start LightDM manually 'sudo lightdm' and once it's initialised everything is fine again, and I can even reboot the system and LightDM will usually start (occasionally it will still fail on a reboot).

Actually, manually running "sudo lightdm" does no always work for me either. I'm starting to wnder if this is fixable by modifying the init scripts or whether the problem is deeper in LightDM.

On Sun, Dec 02, 2012 at 06:28:09PM -0000, Gavin Graham wrote:
> Actually, manually running "sudo lightdm" does no always work for me
> either.

Then you probably need to file a separate bug report.

I haven't tried "and stopped udevtrigger" and "sleep x" yet; that's next.

Instead of 'sudo lightdm stop' and 'sudo lightdm start', I've had consistently good luck (so far) with 'sudo service lightdm --full-restart'.

I see this on a desktop (HP Compaq 8000 Elite (AU247AV)) with rotating rust, not SSD, so I doubt it's related to an SSDs speed

Just reinstalled my desktop (see comment above) with 12.10, and it came up as normal, X flashing etc. However, after updating packaes, X won't come up. Starting 'sudo lightdm' manually works. Again, this is with rotating rust, a Seagate ST3320418AS

roy

In the /etc/init/lightdm.conf I've changed

exec lightdm

to

exec lightdm -d

as a way to catch some extra debugging information in the lightdm log file and lo, now it never fails.
Hmmm, I wonder if writing debug information as slowed things down just enough to avoid a race condition inside the lightdm binary.

This seems to happen everytime I boot my computer... I'm running a fresh install of 12.10 on an i7 core, primary SSD, Nvidia drivers from x-swat and Dual monitors with Twinview enabled.

What I've tried so far with no success:

- rename to *card0
  : seemed to have no effect as there is no card0 in my udev.log
  : also no PRIMARY_DISPLAY_DEVICE in there either, it's almost as if udev is not finding my graphics card properly
- added "and stopped udevtrigger"
- added a sleep 2

My last attempt was to add '-d' to exec lightdm, I was hoping to get more info on what was going on... instead it seems to work properly now.

On a side note, after much experimentation... I have a much higher chance of a correct boot when my external monitors are not attached. I've only seen it fail a handful of times whereas with external monitors attached it's nearly 100%.

Logging in and manually starting lightdm service doesn't help, it just fails immediately again.

> Nvidia drivers from x-swat and Dual monitors with Twinview enabled.

You are using the binary nvidia drivers, so this is not your bug. Yes, you will have neither card0 nor PRIMARY_DISPLAY_DEVICE, because the binary nvidia drivers don't provide the kernel drm driver interface. In your case, lightdm should *only* be starting after 'stopped udev-fallback-graphics', which in turn only happens after 'stopped udevtrigger'. You should probably file a new bug report for your system and attach /var/log/udev.log.

@Daniel (internalkernel)

Just confirming so it isn't lost in the midst, you changed

'exec lightdm'
to
'exec lightdm -d'

and now you are getting Lightdm performing correctly each time?

That is correct... so far so good

exec lightdm -d

On Sun 16 Dec 2012 02:12:08 PM EST, Gavin Graham wrote:
> @Daniel (internalkernel)
>
> Just confirming so it isn't lost in the midst, you changed
>
> 'exec lightdm'
> to
> 'exec lightdm -d'
>
> and now you are getting Lightdm performing correctly each time?
>

That's not a fix, that's just slowing down the exec by enabling debugging so that it's not causing the race issue.

@Pieter

I agree, it is not a fix (well, a permanent and proper one anyway) but it does suggest that it's a race condition and that it is in the Binary itself and not the /etc/init/lightdm script as some of the other potential "fixes" have tried to remedy.

Excerpts from Gavin Graham's message of 2012-12-19 02:25:34 UTC:
> @Pieter
>
> I agree, it is not a fix (well, a permanent and proper one anyway) but
> it does suggest that it's a race condition and that it is in the Binary
> itself and not the /etc/init/lightdm script as some of the other
> potential "fixes" have tried to remedy.
>

Actually thats not really the case.

The most likely case is that there's something, hardware wise, missing
that X needs, that isn't encoded in the events that trigger lightdm
to start.

We'll need full X logs to determine that for sure, but thats what I
suspect. Its possible that udev events are being emitted for devices
that aren't 100% ready, or that there are more events that need to be
blocked on.

@Clint

I'm happy to participate in collecting the data on a quiet day over the Christmas break when I don't really need to use my computer for any real activity. Are you talking about a debug-level log of X or something similar?

Tell me what you would like to see and I'll strip the '-d' from the 'exec lightdm -d' line of /etc/init/lightdm and set other X switches or what ever may be required for that level of information. Do you just want the standard logs?

I thought I'd try stripping the config back to the original without the '-d' in the 'exec lightdm -d' line and after six reboots, not one failure. I'll leave the config in its original state now and if/when the symptoms reappear, I'll grab all the logs and post them up here.

Ideally lightdm should wait until soundcards are ready as well, waiting for the udev event with SOUND_INITIALIZED="1".
See udev script 78-sound-card.rules.

This is quite bad when running ubuntu on VMWare WorkStation 9

I tried editing the lines:
           and stopped udevtrigger #this line I added
           and (drm-device-added DEVPATH=*card0 PRIMARY_DEVICE_FOR_DISPLAY=1

But that didn't work.

Bug 1080082 has been marked as a duplicate of this one, although I'm not sure it is (I use fglrx).

Anyway, my workaround for 1.5 months with no issues and no need for arbitrary sleep has been to modify /etc/init/lightdm.conf and adding "respawn" like this:

...
stop on runlevel [016]

respawn # <-- add this line

emits login-session-start
emits desktop-session-start
emits desktop-shutdown
...

If lightdm comes up the first time, it stays. Otherwise, I see a flicker of the first one dying, and then it immediately starts up again and all works good.

With respawn is working consistently well here so far.

It may have something to do with the powersaving modes of some graphic cards, too.
On the same laptop, booting with the power plugged in causes this problem, but everyting's fine when the power is plugged off.

I believe this bug is featured on Web Upd8: http://www.webupd8.org/2013/01/ubuntu-lightdm-black-screen-when-using.html

Also I found this an interesting comment:

xf86-video-modesetting 0.6.0 driver has been released fixing the crash with a udev race condition.
http://www.phoronix.com/scan.php?page=news_item&px=MTI3MDc

Found this post here: http://askubuntu.com/questions/215842/ubuntu-12-10-sometimes-a-black-screen-after-boot:

I had almost the same problem, black screen at login :( I had to Ctrl+Alt+F1 and restart lightdm and then it worked perfectly, but it sucked a bit to do that all the time so this is what a did next

sudo gedit /etc/rc.local

before the "exit 0" line insert this line:

service lightdm restart

This worked for me,and i hope it'll work for you too.

I'm affected by this bug and have nvidia gpu with the binary nvdia drivers enabled (12.10). Comment #12 provides a solution for me.

I'm on a Dell XPS 15z. I detail below other attempts (all pretty much taken from this thread but unsuccessful for my setup); instead, what works for me is to (1) change in /etc/default/grub the variable GRUB_CMDLINE_LINUX_DEFAULT to "acpi_backlight=vendor dell_laptop.backlight=0 quiet splash", i.e., adding the entire part beginning "acpi_backlight..." ahead of "quiet splash", as suggested in

https://wiki.ubuntu.com/HardwareSupport/Machines/Laptops/Dell/XPS/15z

(thanks).

What also worked was (2) replace the Display Manager lightdm with gdm, i.e., in a terminal do

sudo apt-get install gdm

and then select gdm, although obviously that's not a fix for a lightdm problem. [Alternatively, "sudo dpkg-reconfigure gdm" if you're, luckily, already running lightdm or some other DM.]

Trials that failed for me:

A. In /etc/init/lighdm.conf
Add line "sleep 10" just before line "exec lightdm"
Add flag "-d" to "exec lightdm"
Add line "and stopped udevtrigger" just after line "and started dbus"
Add line "respawn" right before "emits login-session start"
(whether in combination or singly).

B. In a terminal "sudo restart lightdm" or "sudo service lightdm restart" or "sudo service lightdm --full-restart".

I also have this problem, I think!

Occasionally my computer will hang at boot showing only a black screen.
Running Ubuntu 12.10 on the following hardware:

CPU: Intel Core i7-2700K@3.5 Ghz (Sandy Bridge)
GPU: Nvidia GeForce GTX660Ti 2Gb
HDD: Corsair Force 3 SSD 240GB (mounted as / )
Motherboard: MSI B75MA-P45 (LGA1155)
Nvidia binary driver: 310.14

Simply hitting the reset button or power it off and on and it will boot.
I was afraid this was some hardware problem but then maybe not :)

Comment #48 seems to have remedied the problem for me. It's a bit of a hack, but it does the trick. A terminal prompt showed up first for a few seconds (the same thing that often happened before), then Light DM fired up the login screen.

For me this bug appears on a (slow) BTRFS partition on hard disk mounted as root. Apperantly lightdm has timing proplems and there is no fix for it. As a workaround, respawing as of #48 worked for me as well.

Interesting, I too use btrfs for root and home.

Marked #1142044 as a duplicate of this one as I believe it is the same bug.

I'm on a Samsung Series 9 notebook with an Intel Core i7. In my bug report I've added some additional information and logs which aren't available here.

I'm on 13.04 though.

isn't it upstart issue? I removed it and it's booting and working good.

Excerpts from maxim's message of 2013-03-05 09:02:15 UTC:
> isn't it upstart issue? I removed it and it's booting and working good.
>

You removed what?

The issue is that something in the system is not ready when lightdm
tries to start, so either the upstart job needs more start on conditions
(thats lightdm's problem, not upstart), or the kernel needs to not emit
one of the udev events it does, when it does.

I upgraded to Ubuntu Linux kernel 3.5.0-25 and the fix I described in comment #55 now fails as well. So does the work-around suggested in comment #48 (as I previously described, again in comment #55). I have switched back to kernel 3.5.0-23. I'm still looking forward to a genuine fix.

I'm on 12.10 kernel 3.5.0-25 and I'm booting off an SSD (which seems to be a common symptom).

When the blanks screen occurs, I know it wants the FS crypt password. So I type it in blind on this black screen. Then the rest of boot occurs normally. I never see the Grub screen.

I tried adding a 5 second sleep before the "exec lightdm" line on /etc/init/lightdm.conf. This did not solve the problem.

My adapter is:

Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200]

Linux 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 18:26:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Bug still persist in 13.04. GDM works fine.

#64 provides a work-around that does the trick for me too. I'm on the same kernel as jmac939 there, and about 50% of the time my system boots properly into the lightdm login screen. But the rest of the time the system fails to do so but shows only the black screen + mouse pointer. When that happens, I type in my password blind and my login proceeds normally. Obviously, this wouldn't work for a multi-user system [unless keyboard arrow presses get the user to the right login box].

I switched to GDM for the moment.

In my computer, bumblebee started causing this problem.

A suggested fix, given in https://github.com/Bumblebee-Project/Bumblebee/issues/205#issuecomment-8022153 did not solve the problem, and added a delay. However the "and stopped udevtrigger" seems to be working with a fresh bumblebee install (so, without delay).

One thing that may be interesting is that the problem did not happen when I had the phones plugged in.

+1 for #48

On an Lenovo Thinkpad X200s with ext4 SSD (256GB Crucial V4) and some integrated Intel graphics, it is reproducible even when just /etc/init.d/lightdm restart -ing it from console, doing so happens every 15th time or so. Sleep 5 does not help, "and stopped udevtrigger" does not work either, it just keeps getting killed. But respawning works well. It often respawns 2 times in a row.

+1 for #48

Sleep only helped occacionally.

#5 Seems to do the job for me

On an silentmaxx Tower with
- Mainboard GIGABYTE GA-Z77X-UP4 Thunderbolt
- Radeon ATI Radeon 7750 1GB
- SSD Samsung SATA3 128GB

It's a bit annoying, that this bug is over a year old, and still not fixed. Ubuntu is made for 'working out of the box' especially for less experienced users. Having a black screen after boot is an important bug to be fixed.
So please give this bug a higher priority!

I just added respawn to /etc/init/lightdm.conf as suggested in comment #48 - did /not/ fix the problem for me.

VirtualBox - fresh install. No SSD :)
+1 for #48
That's a catch-all workaround, that does not rely on an outcome in some race condition.
If it does not work for you, I believe you have a different bug.

I have same problem.
On 12.04 it was even acceptable - freezing from time to time. But after upgrading to 13.04 I have 3 to 4 freezes before successfull lightdm load.
Patching /etc/init/lightdm.conf helped me for now - but slowing down fastboot is a little pity.

Let me know if I could help (logs/configs/etc).

I run Ubuntu 13.04 on Thinkpad W530 with 256GB SSD. After upgrading to kernel 3.8.0-26 I have a black screen with cursor in place of lightdm. Lightdm works well if I boot with elder kernels.

The solutions of posts #5 (sleep 10) and #48 (respawn) are useless, the solution of post #12 (and stopped udevtrigger) freezes the system. Any ideas?

respawn workaround works fine here, but frankly I find it troubling that such a severe issue has gone unfixed for so long... Will we ever get an official update that fixes this? New users shouldn't be expected to edit config files just to get their system to boot correctly. This type of bug should never even make it out of a beta release, and definitely shouldn't go unfixed in multiple "stable" releases.

Excerpts from bwat47's message of 2013-07-16 22:02:03 UTC:
> respawn workaround works fine here, but frankly I find it troubling that
> such a severe issue has gone unfixed for so long... Will we ever get an
> official update that fixes this? New users shouldn't be expected to edit
> config files just to get their system to boot correctly. This type of
> bug should never even make it out of a beta release, and definitely
> shouldn't go unfixed in multiple "stable" releases.
>

First, this is a race. Races are really hard problems to reproduce and
solve reliably.

Second, I'm pretty sure this is a hardware specific problem caused
by drivers lying to the system about the state of the hardware, and
subsequently dying when actually asked to function. This is only exposed
on systems that boot extremely fast.

Please be patient, it has been looked at by some of the brightest minds
in Ubuntu, and has thus far remained a bit of a mystery.

@Clint: But honestly, why not deploy the workaround by default?
It has 0 bad effects when you don't have the issue, and is the difference between some strange flickering and most people not being able to get a working system at all.

Excerpts from Ivo Anjo's message of 2013-07-17 08:32:54 UTC:
> @Clint: But honestly, why not deploy the workaround by default?
> It has 0 bad effects when you don't have the issue, and is the difference between some strange flickering and most people not being able to get a working system at all.
>

I have not seen data that proves it has 0 bad effects. I'd suspect that
it would have a minor impact on time between power-on and login for
those users who are not affected, but I also have no data on that either.

What is needed is several affected systems and a very focused engineer
who has access to all of them. Apparently that hasn't happened yet. :-P

> I have not seen data that proves it has 0 bad effects. I'd suspect that
> it would have a minor impact on time between power-on and login for
> those users who are not affected, but I also have no data on that either.

Sorry... say what!? I will just quote it for you, from canonical's upstart documentation:
http://upstart.ubuntu.com/cookbook/#respawn
"6.26 respawn
Without this stanza, a job that exits quietly transitions into the stop/waiting state, no matter how it exited.
With this stanza, whenever the main script/exec exits, without the goal of the job having been changed to stop, the job will be started again."

So please don't make up suppositions and compare them to facts.

Excerpts from Ivo Anjo's message of 2013-07-22 16:39:16 UTC:
> > I have not seen data that proves it has 0 bad effects. I'd suspect that
> > it would have a minor impact on time between power-on and login for
> > those users who are not affected, but I also have no data on that either.
>
> Sorry... say what!? I will just quote it for you, from canonical's upstart documentation:
> http://upstart.ubuntu.com/cookbook/#respawn
> "6.26 respawn
> Without this stanza, a job that exits quietly transitions into the stop/waiting state, no matter how it exited.
> With this stanza, whenever the main script/exec exits, without the goal of the job having been changed to stop, the job will be started again."
>
> So please don't make up suppositions and compare them to facts.
>

Ease up, we're all working together right?

Respawn is a mitigation strategy and I actually thought that was in the
file already. Good idea to just add it, though it will fail to help if
it respawns too fast. The workaround I thought you were referring to
was changing the "start on".

Perhaps open a second bug, reference this one, and submit a patch?

lightdm does not use respawn because the failsafe-x job catches lightdm failures and launches its own fallback X server for troubleshooting purposes. Adding 'respawn' doesn't fix the ordering issue, and would break other things besides.

Is this both a lightdm bug and a failsafe-x bug?
Because I don't get failsafe-x when lightdm fails, I just get a tty.

I only see a black console with a blinking cursor.. lightdm process is still running, so failsafe-x doesn´t take over i guess...
Experiencing this bug with latest 13.10 Saucy Salamander...

Would be nice if someone can fix this! Its a problem that effects a lot of users and people who don´t know there way arround console just dump ubuntu from their newly bought PC/Laptop with SSD becaue they think it is crap.. / only works every 2th boot...

Since I reinstalled my system (13.10) in UEFI mode, this bug even occurs more often. Before it only occured about every second start.

I've got a SATA II SSD, and a Haswell i5 CPU which also handles the graphics.

The special thing about the bug for me is that I am never able to start or restart lightdm manually. It shows a blinking cursor on a black screen like on the most boots. Even when the boot works normally, I sometimes get the black screen again when logging out.

Same problem here with Ubuntu 12.10 running kernel 3.5.0-37-generic.
Acer Apire Timeline U
SSD 20GB with Btrfs - /
HDD 500 with Ext4 - /home
6GB Ram

Then the "sudo /etc/init.d/lightdm restart" helps me.
Intel(R) Core(TM) i5

Also affected here.

Ubuntu 13.04
SSD
Radeon HD4250
Phenon X4

Seems to work making lightdm.conf as:

start on ((filesystem
           and runlevel [!06]
           and started dbus
           and stopped udevtrigger ###---->>> line added
           and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 ###---->>> line added
                or stopped udev-fallback-graphics) ###---->>> line added
           and plymouth-ready)
          or runlevel PREVLEVEL=S)

Dell XPS 13 + Fresh 13.04:
Black screen almost every time ... for month.

1) Log in to the console.
2) sudo /etc/init.d/lightdm restart && logout
3) Enter the password for the third time. I did it!

I guess I have to remove lightdm and fire up 'startx' from the console instead for more comfort. ;)

Excerpts from Clint Byrum (clint-fewbar) message:

> Second, I'm pretty sure this is a hardware specific problem caused
> by drivers lying to the system about the state of the hardware, and
> subsequently dying when actually asked to function. This is only exposed
> on systems that boot extremely fast.

I've bought a Dell Precision M6500 because it was Ubuntu certified. But just when I installed a second SSD (from Kingstone) it put me into this bug and a daily struggle to boot my laptop.

So this does not seam to be hardware specific. It just seams that Ubuntu does not run properly on SSD drives (which actually means that Ubuntu does not run on modern hardware).

I've not seen this bug on my SSD based vaio in a long time. Originally I fixed it with the 'and stopped udevtrigger' workaround, but that has been gone for awhile. I assume this is because I'm not running the nvidia drivers any more. (Long ago it had been posited that the problem was that the nvidia drivers were lying about their readiness at some point?)

Perhaps it would be worth re-trying the nvidia drivers to see if I can reproduce again. (I didn't drop them because of this issue, but because the right version wasn't being installed for my kernel)

I had this with fglrx, so either both amd and nvidia suffer from the same bug, or it is elsewhere.
It's just a pity that this is treated as such low priority.

I had the opposite problem. By commenting out the line : sleep 5
after the line: post-start script
in /etc/init/lightdm.conf
my lightdm bug is fixed in Ubuntu 13.04

If the bug is actually what I think it is (not that sure reading some comments), ie black screen with white cursor in the top left corner instead of lightdm from time time, but still working when typing your password and Enter "in the dark".
Then I have it on my Dell xps 13, SSD and only Intel HD Graphics 4000, on Ubuntu 13.04.

Ubuntu 13.04
Intel SSD
i7 4770S
Using the processor graphics with the default driver.

I got the black screen with a white mouse cursor about a quarter the time on boot and finally discovered the machine wasn't broken/crappy by pressing CTRL-ALT-F1 to see if tty1 would work (previously I would just press reset when the black screen issue came up).

I tried the sleep workaround here and have had good results so far (I used a 1 second delay):
http://www.webupd8.org/2013/01/ubuntu-lightdm-black-screen-when-using.html

Is there some way to detect the error state and present an error message to the user instead of the black screen? A fix would be better but it would be nice if we could at least give a little feedback so users don't assume Ubuntu is broken.

With our particular setup of school labs. 2-3 out of 30 stations would always fail - the display manager would not start.

On the kernel i turned removed: splash & quiet and noticed that the events proceeding starting lightdm were quite a bit shorter for the failed machines.

When I turned on more debugging features, all the machines boot-up fine with no errors! So my hack/solution:
* kernel boot options remove: splash quiet
* kernel boot options add: verbose init=/sbin/init --verbose
* /etc/default/rcS
     VERBOSE=yes

My guess is that dumping the verbose text out to the screen creates just enough delay to fix the race condition.

Same problem with my X230 since I installed a SSD drive. Previously ran the same device with a normal drive without these issues.

Lenovo X230
Ubuntu 12.10/13.04 64bit
Samsung SSD 840
i5-3320M
using the processors HD4000 graphics.

Definitely checks the boxes for a race issue. Often I can boot just fine on the first try. On other ocassions even multiple reboots don't get me to login. Switching to a console and starting lightdm always works.

As this issue has gone unfixed for so long and - at least judging from the information in this report - there is no progress made towards a solution it seems about time a workaround is developed and distributed. This issue is annoying for advanced users. Everyone else will think their computer is broken. Imho at this point even the most horrible band-aid is preferable to the current state of affairs. This issue now spans 12.04 LTS, 12.10, 13.04 and soon 13.10.

This happens sometimes on my machine:
Ubuntu 12.04 64bit
Intel SSD 335
Nvidia GTS 650 with NVIDIA drivers.
lightdm version 1.2.3-0ubuntu2.3

Tracked it to a race issue - if NVRM module is loaded before lightdm starts, all is OK. (see logs in Post Scriptum)

My current configuration in /etc/init/lightdm.conf:

start on ((filesystem
           and runlevel [!06]
           and started dbus
           and plymouth-ready)
          or runlevel PREVLEVEL=S)

Post Scriptum: Logs clearly showing that when lightdm is started before the NVRM module is loaded, and dies a horrible death:
Sep 13 14:20:07 Pendragon kernel: [ 5.944960] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sep 13 14:20:07 Pendragon kernel: [ 6.099801] init: lightdm main process (1127) terminated with status 1
Sep 13 14:20:07 Pendragon kernel: [ 6.509805] HDMI status: Codec=0 Pin=5 Presence_Detect=0 ELD_Valid=0
Sep 13 14:20:07 Pendragon kernel: [ 6.533772] HDMI status: Codec=1 Pin=5 Presence_Detect=0 ELD_Valid=0
Sep 13 14:20:07 Pendragon kernel: [ 6.557710] HDMI status: Codec=2 Pin=5 Presence_Detect=0 ELD_Valid=0
Sep 13 14:20:08 Pendragon kernel: [ 6.581717] HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
Sep 13 14:20:08 Pendragon kernel: [ 6.581814] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:03.0/0000:01:00.1/sound/card1/input10
Sep 13 14:20:08 Pendragon kernel: [ 6.581890] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:03.0/0000:01:00.1/sound/card1/input11
Sep 13 14:20:08 Pendragon kernel: [ 6.581954] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:03.0/0000:01:00.1/sound/card1/input12
Sep 13 14:20:08 Pendragon kernel: [ 6.582180] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/0000:01:00.1/sound/card1/input13
Sep 13 14:20:08 Pendragon kernel: [ 6.583236] nvidia 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Sep 13 14:20:08 Pendragon kernel: [ 6.583243] nvidia 0000:01:00.0: setting latency timer to 64
Sep 13 14:20:08 Pendragon kernel: [ 6.583247] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
Sep 13 14:20:08 Pendragon kernel: [ 6.583341] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.32 Wed Jun 19 15:51:20 PDT 2013
Sep 13 14:20:08 Pendragon kernel: [ 6.794290] init: udev-fallback-graphics main process (1380) terminated with status 1
Sep 13 14:20:08 Pendragon kernel: [ 6.951100] init: plymouth-stop pre-start process (1400) terminated with status 1
Sep 13 14:20:08 Pendragon kernel: [ 7.533643] cfg80211: Found new beacon on frequency: 2472 MHz (Ch 13) on phy0

Adding some lines to /etc/init/lightdm.conf fixed the problem on my PC (Ubuntu 12.04):

start on ((filesystem
           and runlevel [!06]
           and started dbus
           and plymouth-ready
           and (graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY=1 #added
           or drm-device-added PRIMARY_DEVICE_FOR_DISPLAY=1 #added
           or stopped udevtrigger or container)) #added
          or runlevel PREVLEVEL=S)

I'm experimenting this bug since 12.10 on all my systems, amd and nvidia.

Attached the lightdm.log from a filed startup.

I think it's time to fix this bug.

I am running kernel 3.2.0-54 in Ubuntu 12.04. After the last update, lightdm does not start so no gui. I tried editing the config for lightdm by adding some delay and the respawn but it did not work. Can anybody here tell me what is wrong by looking at the log?

plum7500, in the log you just reported, the relevant lines are these:

[+0.03s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0
[+1.62s] DEBUG: Process 1470 exited with return value 127
[+1.62s] DEBUG: X server stopped

What means the X Window System Server wasn't unable to register a seat for the LightDM X Display Manager; due to a malfunction in this last one.

thanks for looking into this bug. I tried switching the display manager to gdm but pc kept rebooting. How would I restore old version of lightdm?

I managed to downgrade lightdm to version 1.2.1-0buntu1-amd64 but I still do not get GUI when I boot up

I got better result using default lightdm greeter instead of ubuntu's one. Maybe this can help others.
sudo apt-get purge lightdm
sudo apt-get install ubuntu-desktop
sudo apt-get install lightdm-gtk-greeter
If lightdm-gtk-greeter is installed, you will not be able to start neither ubuntu-greeter, nor default gtk greeter. After the installation of the gtk-greeter, ligthdm will default to this one.

By the way I encountered this bug on an old laptop with ATI Mobility Radeon X1300 using radeon module on 13.10 (/ on btrfs fs, /home on ext4 fs ; using SSD drive).

I might have some news for this bug:

First is, if i remove "quiet splash" from boot, the bug disappears as well.

More importantly though, if I have the blank login screen, and I connect an external monitor, the screen shows up.
If I go to a tty (Alt-Ctrl-F1) and back to X (Alt-Ctrl-F7), the screen is blank again.
Then, if I pull out the external monitor, the login screen shows up again.

Summed up
1. toggling external screen connection brings login screen up
2. switching to text and back to X kills it

It takes 1 to 2 seconds to bring the screen up after the cable is connected/disconnected.

I am on toshiba portege Z930-14L
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

By the way, I noticed (very rarely) that when logged in, the "screen refresh" may "lag", that is when for example typing a command in the shell the last character of the command would show up only after pressing enter. I believe this was not particular to the shell, but since it happend only once or twice on this new laptop I cannot tell for sure.

Can I do anything to further debug this?

BR, Chris

I should also mention that after the screen locks and blanks while unattended, it often comes back only on the external monitor while leaving the laptop monitor blank. Pulling the monitor cable brings it back on the main screen.

I recommend that Canonical moves over to using GDM or another display manager if they can't get this fixed for LightDM.

If they're looking to make a good impression, resolving this critical issue should be at the absolute top of the list (and back-ported).

same problem with 13.10 on a samsung series 5 notebook with a ssd
set sleep to 5 (with lower seconds the bug still persist in a lower frequency...)

Same problem, 13.04 fresh install. I have been trying to solve this bug for ages, the only workaround that has worked for me is to use GDM, not ideal, I have tried #39, since the set up is similar to mine, nvidia graphics and SSD, will report back with findings. At least we can work around it, but for some reason when I enable GDM a lot of programs like ubuntu one and the terminal from unity were removed.

Not sure if those two are somehow related.

In 13.10 on an Aspire laptop with an HDMI attached 1920x1280 monitor the background on one or the other comes up blank depending upon how I set the monitor positions. When side by side with the laptop to the right, it is the laptop screen that comes up blank. Gkrellm is supposed to come up on the top right hand corner of the laptop screen but instead it is in the top left of the external monitor. -- Behavior not evident in previous versions.

I find I can fix the background situation by changing the background, Going to a terminal session and doing a restart lightdm also works. I'll try the init script suggestions provided here to see what happens.

Despite the sleep command (up to 12 at this moment) before exec lightdm in /etc/init/lightdm.conf
 still the ocasionally startup with a black screen and blincking cursir.

Also tried the lightdm-gtk-greeter and GDB. The same error remains!

I have a fresh Ubuntu 12.04.3 LTS installation and at first everything worked fine. 2 days and approximately 10-15 reboots after the initial installation I started experiencing this "blank screen, blinking cursor in upper left corner" problem with increasing density. After another 2-3 days and a numer of reboots I could only get this blank screen.

I followed the fix / workaround suggested in comment #95 and so far I have not experienced the problem once, i.e. no problems in rouhly a week and another 15-20 reboots.

For those working with the issue, below is a list of my HW.

H/W path Device Class Description
======================================================
                            system MS-7823 (To be filled by O.E.M.)
/0 bus Z87M-G43 (MS-7823)
/0/0 memory 64KiB BIOS
/0/3d processor Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz
/0/3d/3e memory 1MiB L2 cache
/0/3d/3f memory 256KiB L1 cache
/0/3d/40 memory 6MiB L3 cache
/0/41 memory 8GiB System Memory
/0/41/0 memory 8GiB DIMM DDR3 Synchronous 1600 MHz (0.6 ns)
/0/41/1 memory DIMM [empty]
/0/41/2 memory DIMM [empty]
/0/41/3 memory DIMM [empty]
/0/100 bridge 4th Gen Core Processor DRAM Controller
/0/100/2 display Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
/0/100/3 multimedia Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller
/0/100/14 bus 8 Series/C220 Series Chipset Family USB xHCI
/0/100/16 communication 8 Series/C220 Series Chipset Family MEI Controller #1
/0/100/1a bus 8 Series/C220 Series Chipset Family USB EHCI #2
/0/100/1b multimedia 8 Series/C220 Series Chipset High Definition Audio Controller
/0/100/1c bridge 8 Series/C220 Series Chipset Family PCI Express Root Port #1
/0/100/1c.4 bridge 8 Series/C220 Series Chipset Family PCI Express Root Port #5
/0/100/1c.4/0 eth0 network RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
/0/100/1d bus 8 Series/C220 Series Chipset Family USB EHCI #1
/0/100/1f bridge Z87 Express LPC Controller
/0/100/1f.2 storage 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode]
/0/100/1f.3 bus 8 Series/C220 Series Chipset Family SMBus Controller
/0/1 scsi0 storage
/0/1/0.0.0 /dev/sda disk 240GB KINGSTON SV300S3
/0/1/0.0.0/1 /dev/sda1 volume 100MiB Windows NTFS volume
/0/1/0.0.0/2 /dev/sda2 volume 112GiB Windows NTFS volume
/0/1/0.0.0/3 /dev/sda3 volume 111GiB Extended partition
/0/1/0.0.0/3/5 /dev/sda5 volume 103GiB Linux filesy...

Also tried the workaround #95;

<<quote>>
On the kernel i turned removed: splash & quiet and noticed that the events proceeding starting lightdm were quite a bit shorter for the failed machines.

When I turned on more debugging features, all the machines boot-up fine with no errors! So my hack/solution:
* kernel boot options remove: splash quiet
* kernel boot options add: verbose init=/sbin/init --verbose
* /etc/default/rcS
     VERBOSE=yes
<<unquote>>
Seems to work. After more then one week no meer black screens-.........!
Thanx

Commented to early, The workaround #95 did not resolve the blackscreen issues (although the frequency seems to be lower)

Now something has changed since as I took more disk to use. As the system is a dual-boot, I mounted the Windows system disk (SSD) as read-only and another disk as shared read-write for both systems to use.

What happens now, and actually started happening a couple of days after the changes described above in #113, booting stopped with an error message on the screen about mountall failing. After pressing Ctrl-ALt-Del the boot continues and I get an almost normally behaving system. I have to mount the two abovenemtioned filesystems by hand, but luckily my /home -directory from a non-SSD disk has been mounted succesfully and I can log in.

At this point, I do not have the faintest idea about what is going on.

Seems that the bug occurs more often after an update and reboot (with new profiling) although it also occurs less often without any updates..............

The same what 323232 wrote happened to me - had to replace lightdm with gdm.

This is still an issue in ubuntu 14.04.

We need to apply a fix in the startup which performs a while statement to check if dependencies are not yet loaded. This will mitigate against problems with varying sleep times which may or may not work for users.
Alternatively, having a list of dependencies to run inline may be a better option.

Seven months have passed with no fix in place. I have removed the assigned user so that another may step-up in their place to resolve the issue.

Yep. It's a bug with the ligthgm setup. Replacing it with gdm solves the problem

Excerpts from walec51's message of 2014-03-01 23:53:04 UTC:
> Yep. It's a bug with the ligthgm setup. Replacing it with gdm solves the
> problem
>

Thanks for the data, that should help a bit.

However, all that proves is that gdm does not have the symptom. It does
not indicate that "the problem" is lightdm's setup. It may just be that
gdm starts up a few seconds slower and thus loses the race where lightdm
wins it.

I concur!
Though, I think the problem is more-so that there is a race in the first place instead of a march which is what I'm hoping we can fix.

Something has happened again. The scenario described in #116 has disappeared, that is now - for some reason, which I do not know - I am not experiencing any of the problems described in #116. Goes without saying, I haven't changed anything, just used the computer.

Relax, the bug is only sporadic and the slowdown on boot may be overcome with inode updates and defrags which may or may not occur automatically with the BTRFS file system. While it may happen with one system, it may not with another. While it may happen at one time with a system, it may not at another. It's based on how quickly boot occurs and whether or not lightdm loads before or after its dependencies which may or may not occur depending on how optimized the filesystem is as well as other factors.
Using the computer will add, remove, and optimize files in the filesystem as time goes on. This scenario of having lightdm load properly was expected and is part of the bug in question.
To simplify, lightdm is winning the race condition instead of losing. However, much like Global Thermonuclear War, the only way to truly win every time is not to play. Thus, the bug still exists.

Currently I've been running without issues with the following configuration in /etc/init/lightdm.conf since September 2013.

[...]
start on ((filesystem
           and runlevel [!06]
           and started dbus
           and plymouth-ready
           and stopped udevtrigger) # <- one line fix
          or runlevel PREVLEVEL=S)
[...]

My configuration is:
Ubuntu 12.04 64bit
Intel SSD 335
Nvidia GTS 650 with NVIDIA drivers.
lightdm version 1.2.3-0ubuntu2.4

Additionally, dependencies on the following were not helping to solve the problem:
graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY=1 - this event is not fired on my machine
graphics-device-added - this event is fired too early - possibly on vesafb load - ligthdm crashes and the fallback mode kicks in.
drm-device-added PRIMARY_DEVICE_FOR_DISPLAY=1 - is not fired on my machine

This bug affects me also. I have not tried Ciprian's one line fix. My logs are attached.

I have applied Ciprian's "fix" from #127 to no avail.

Here are my new logs, with the change applied. I didn't spot any difference.

Avius: When lightdm fails to start, do you get sometimes X started up in "safe mode" as per Comment 2 from Serge ?

Your problem seems different as your your logs show that lightdm can successfully start and connect to the X server, and something happens during your login. Relevant extract from your logs below:
[+3.06s] DEBUG: Seat: Display server ready, starting session authentication
[...]
[+5.80s] DEBUG: Session pid=1330: Started with service 'lightdm', username 'avius'
[+5.80s] DEBUG: Session pid=1032: Greeter start authentication for avius
[+5.80s] DEBUG: Session pid=1330: Sending SIGTERM
[+5.80s] DEBUG: Seat: Setting XDG_SEAT=seat0
[+5.80s] DEBUG: Session: Setting XDG_VTNR=7
[+5.80s] DEBUG: Session pid=1331: Started with service 'lightdm', username 'avius'
[+5.80s] DEBUG: Got signal 15 from process 991
[+5.80s] DEBUG: Caught Terminated signal, shutting down

Could your problem be related to authentication ? Is your system set to autologin?
Have you tried logging into the console and running 'start lightdm'?

As per comment #97, lightdm (which in turn starts X) can be started before the display kernel modules are fully loaded (creating a race). The problem is most apparent to people running Ubuntu from an SSD. On my PC, the "one line fix" delays the lightdm start sufficiently for the kernel display modules to be fully loaded. It's really working on my system:

ls -ltr /var/log/Xorg*
-rw-r--r-- 1 root root 69099 Sep 13 2013 /var/log/Xorg.failsafe.log.old <-penultimate start of X into failsafe mode before performing the workaround
-rw-r--r-- 1 root root 69514 Mar 8 14:17 /var/log/Xorg.failsafe.log <- last start of X into failsafe mode while getting this down to a one liner in March
-rw-r--r-- 1 root root 31975 Mar 28 19:11 /var/log/Xorg.0.log.old
-rw-r--r-- 1 root root 30869 Mar 30 10:58 /var/log/Xorg.0.log

There are other workarounds from other people in this thread, which seem to have the same effect - for example someone suggests in comment #114 to make the startup verbose, which seems to solve the problem for that person.

When X fails to start, I don't get the safe mode screen; I just have a blinking cursor in the top left corner. This occurs during random bootups, and without any interaction; the failure is before the username/password textbox is presented. I'm not sure what the "something happening during login" could be. The system is not set to autologin.

During those bootups that fail, I typically log in to a tty and run "sudo service lightm restart". If I run "sudo service lightdm start", then I get a message about how lightdm is already running.

Any ideas what my issue is? Are you sure that it is not the same race condition biting me?

I forgot to mention: sometimes it takes two or three "sudo service lightdm restart" attempts before the system proceeds normally. In other words, it will bootup, go to the blinking cursor, I'll restart lightdm, and it will go to the blinking cursor again. Sometimes if I'm fast, I can catch it starting to load the lightdm greeter screen for a split second before it crashes.

avius, the same behavior "sudo service lightdm restart" for my at an HP N54L. I'm not sure which parameter counts, the times I tried to restart or the duration since booting.

It's me, again.

The N54L works now, but I don't remember the changes.

But today I failed to add SSD based EnhanceIO to several iSCSI based Ubuntu desktops (Intel G530 and G1610). They hung up with a blank screen and a mouse cursor in the middle. The kernel hung up, I cannot ping it. But when I booted with text mode and then "sudo service lightdm start", it worked for the most times and failed for several times. It seems that lightdm or X failed if the machine STARTED TOO SOON. I tried all the walkarounds above but no one works.

I run Ubuntu 14.04 and the workaround in #127 seems to have fixed it for me, thanks Ciprian.

The fact that this is still happening on Ubuntu 14.04 is pretty shocking - I know LightDM and Upstart are effectively deprecated in favour of SDDM and systemd in the newer versions, but since this is such a high-impact bug affecting so many users it really should be fixed in the LTS versions.

FWIW, I'm also on 14.04 LTS and the workaround from comment #127 did not work for me. (nor any of the other lightdm work-arounds.)

The "fix" to switch to GDM worked for me

--BUT--

If you set your screen to shut off and require a password (in the Brightness & Lock settings), you'll get this bug still, even with GDM as your login manager.

This bug hit me after an upgrade from 14.04 to 16.04.1. Strangely I was not affected earlier. Maybe a reinstall might fix this issue? Two out of three reboots leads to failsafe X. Sleep command improved the situation but still 50%... Other solutions like restart in rc.local somehow did not work. Maybe systemd is ignoring it or it is executed way to early.
Maybe this bug is related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1070150 ?

gdm3 currently only comes up with a black screen and a mouse cursor and no error in the logs...
sddm is working fine but the lockscreen locks the terminal permanently and only killing the process on tty1 unlocked it.

Current workaround with a newly created systemd service which starts after the graphical target is completed. (see attached file)

systemctl enable lightdmrestart
systemctl reboot

Currently working without an issue. Hope it helps if someone else is still affected and needs a quick fix.

It looks like I just ran into this issue with Ubuntu 16.10 so the upstart reference may be wrong here.

Is any more data needed or would it be useless anyway?

PS: It seems that some of the "fixes" made it to /etc/init/lightdm.conf already but nothing helps?