Comment 32 for bug 1764417

Fix:
If you search your journalctl output and find an event like this:
Jul 07 20:45:20 ubuntu dbus-daemon[1064]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' requested by ':1.168' (uid=1000 pid=23634 comm="/usr/lib/gnome-settings-daemon/gsd-color " label="unconfined")

and the timestamp coincides with the second (successful) login (look for "GNOME Shell started" if you are using Gnome), and the first (failed) login doesn't have a matching event like the above, then the following might help:

# copy /lib/systemd/system/graphical.target to /etc/systemd/system/

# edit /etc/systemd/system/graphical.target, so that when you diff it against the original, you get something like this:
$ diff /lib/systemd/system/graphical.target /etc/systemd/system/graphical.target
14c14
< Wants=display-manager.service
---
> Wants=display-manager.service colord.service
16c16
< After=multi-user.target rescue.service rescue.target display-manager.service
---
> After=multi-user.target rescue.service rescue.target display-manager.service colord.service

# next time you reboot the issue should be gone.

Explanation:
gsd-color is invoked by org.gnome.SettingsDaemon.Color.desktop.
The event above is logged presumably when gsd-color requests the dbus service provided by colord.service.
One can reasonably guess a failed login happens when gsd-color makes the request but colord hasn't yet started, so it fails and when gnome shell gets tired waiting, it kills itself.
So we add colord as a dependency to be run prior to graphical.target.