[systemd] boot stopped at 'authenticate and authorize users...'

[dino99]

Utopic upgraded from Trusty i386 (fully upgraded: systemd 2O4.8ubuntu1)

The boot process goes well until:

started login service
started avahi mdns/dns-sd stack
starting authenticate and authorize users to run privileged tasks ....

then nothing happen, no errors/warnings, only waiting for something it cant find.

That system is a single desktop with no lan/wan nor other users, only myself alone.

[N1ck 7h0m4d4k15 (nicktux)]

Please update your system with

sudo apt-get update
sudo apt-get dist-upgrade

reboot and see if the error still exist.

I cannot reproduce it and maybe is not related to [systemd].

Also

systemctl list-units --failed

could give us a clue, suppose the problem is related to [systemd]

Thanks

[dino99 (9d9)]

oem@dev32:~$ systemctl list-units --failed
Failed to get D-Bus connection: No connection to service manager.
oem@dev32:~$

I'm logged with gnome-shell, and that i386 system is fully dist-upgraded.
(cant reboot right now, will report later)

[dino99 (9d9)]

New feedback after rebooting with 'systemd'

Booted with 3.15 kernel without issue that time; so that problem seems to be fixed now.

oem@dev32:~$ systemctl list-units --failed
0 loaded units listed. Pass --all to see loaded but inactive units, too.

oem@dev32:~$ systemctl list-units-files
Unknown operation 'list-units-files'.

That is, so the previous failing D-Bus connection error is not seen if systemd is used for booting.

[N1ck 7h0m4d4k15 (nicktux)]

Yes, in order to boot and debugging systemd (reporting bugs..etc) you must boot with systemd as PID 1, or else you will get similar errors.

It you have decided to participate in systemd testing, you should boot the PC always with systemd as PID 1.

I think we can mark this bug as 'invalid', in order to keep the developers focused on other bugs.
If you agree mark it as such.

Regards

[Launchpad Janitor (janitor)]

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

[dino99 (9d9)]

Despite my comment in #3 above, i've got hard time to boot with systemd today: the first two cold boots ended with some "failed" red warning while the system was loaded (too fast to be able to see about what was failing) then got X crashed.
So the error reported here was also seen by two times (before getting X crashing).
At first glance, i was blaming the new 'transitional' update-notifier, but without beeing sure about that. It seems either be :
- a boot race issue: system continue booting, while some mandatory driver/lib/service(s) still not ready.
- or the consequency of the rather rough method while previously shutting down the system: compared to upstart case, now the system seems to be really killed: looks like it have not the time to close/unload before shutting down. Wonder if it could be a valuable reason for the next cold boot to fail ?

[Harry (harry33)]

Dino99,

When the booting stops, can you go to tty (cntr+alt+F1)?
Do you use gdm?
If so, try to login and stop gdm (sudo service gdm stop)
and the start it again (sudoi service gdm start).

[dino99 (9d9)]

Comments about #6 above:
- 'shut down' have stopped to be 'rough' now: everything seem to be unloaded/closed before shut down.
- i cant boot if lightdm-gtk-greeter is not installed
- gdm is also installed as i'm a gnome-shell user

@Harry
i've purged/reinstalled several times all the 'greeter'. tty is not available.
That said, i think its race/conflict with the all 3 installed greeters (unity/lightdm/gdm). Maybe an upstart/systemd issue with these greeters.

ps: since lightdm-gtk-greeter is used, the reported error is gone (only exist without it)

[dino99 (9d9)]

ps2: wonder if lightdm is also affected by that bug (lp: 1069218) in Utopic

[Harry (harry33)]

This is definitely a systemd issue.
You could try booting with gdm as default display manager.

[dino99 (9d9)]

@Harry

Some more tests:

- with the greeters (3) installed: either lightdm or gdm provide the login dialog box
- but sometimes (after a few days updates) the cold boot login fail to start X
- when X fails, after resetting compiz/unity, i usually be able to log with unity, but resetting gnome-shell is mostly not enough to get it launched (X crash)
- if logging with unity is successfull, then resetting gnome-shell let me logging with it (that time X does not crash)

[Martin Pitt (pitti)]

So it seems the originally reported problem was fixed. There's a multitude of insufficiently described and hard to understand other problems here. If you have particular issues under systemd, can you please report one bug for each issue with a precise description, and include the output of "systemctl status <servicename>"? If in doubt, you can also include "systemctl status --failed". Thanks!

Thanks!

[Martin Pitt (pitti)]

Removing systemd-boot tag. Upgrades from trusty necessarily use upstart, so the hang that you saw wasn't a systemd boot problem.