Comment # 11 on bug 1229813 from Thorsten Kukuk

(In reply to Simon Lees from comment #10)
> I have been unable to replicate this on my systems, or on a fresh tumbleweed
> install. Given that wtmpdb was already on my fresh tumbleweed install I
> presume it has reasonable test coverage on openqa and the issue didn't show
> up on any of the journal check tests there.

The problem is not wtmpdb, wtmpdb cannot break the boot process and is very
robust to handle missing dbus reliable. It's only a symptom of the real problem
somewhere else.

> I'm going to need more info about the systems that were having this issue
> before I can debug further, also lowering the priority as so far its only
> been seen on one system.
> 
> Out of interest had these systems previously swapped to runnning dbus-broker?

Two older MicroOS installations got stuck during boot process after applying
the snapshot with the dbus-broker switch, both UEFI, one with traditional
grub2, one with systemd-boot. One got just stuck without any visible reason,
one in the emergency shell (sulogin, not initrd). No errors (except on one
machine the dbus error from wtmpdb) were visible. Only thing I noticed:
processes depending on dbus got started before dbus. wtmpdb was clearly visible
because of the dbus error, the other I remember was systemd-logind. None had
dbus-broker installed before. In both cases a hard reset lead to a working
system again.

I installed a fresh Tumbleweed Server yesterday (UEFI, systemd-boot), which
also got stuck in the first tries to boot it, but due to the splash screen
there was no chance to get any message from the system. The machine did never
show any boot problems before.

Since many other machines with the same setup come up without any problem, this
looks like a race somewhere.