Comment 21 for bug 276857

First thing to realize, when trying to follow these instructions print
them BEFORE rebooting!

On Wed, 2008-10-22 at 15:02 +0000, Martin Pitt wrote:
> Experiment 1: Just "startx"
> -> I got the "config/hal: couldn't initialize context: (null) ((null))" in Xorg.0.log, and I did not have keyboard and mouse (I do not have an xorg.conf).
>
> So that demonstrates the "no hal" -> "no love" effect.

Ditto.

> Experiment 2: sudo hald; startx
>
> hald usually stays in the foreground until all the "coldplugging" is
> done, and then forks off into the background. This is more or less what
> the init script does as well. startx avoids all the gdm delays etc. This
> worked fine, I had keyboard and mouse, and Xorg.0.log didn't complain.

Works for me also.

So, the question is why is this different than boot. I tried increasing
the system load and removing the disk cache. On separate VTs did:

    make -i -j 12
    find . --name "*" --exec cat {} \; &> /dev/null
    find . --name "*" --exec cat {} \; &> /dev/null

Things still work.

But, this got me looking into why boot would be different. One thought
on that was that the read ahead was effecting things. So I
changed /etc/readahead/boot to only include: /bin/bash. No effect. I
then changed it to include all of the fdi files in /usr/share/hal. No
effect.

> * If you boot with adding "text" to the kernel command line, gdm is not
> started. If you start (a) gdm or (b) startx manually after a text-only
> boot, does it work (a1/b1) the first time, (a2/b2) the second time?

It works the first time if booting without gdm and then starting it.

> * If the previous experiment still fails for you, please boot with
> "text" again, go to a VT, do
>
> sudo killall hald
> sudo hald --verbose=yes --daemon=no 2>&1 | tee /tmp/hal.log

hal.log is uninteresting. But attached.

I started looking at the dbus logs to see if there was anything
interesting. This involved doing dbus-monitor in the system bus and
watching things come on and off. X is connecting and getting a name.
There's nothing weird going on there. There was no noticeable
differences between the two executions.

All in all, it seems to be something with the boot sequence
specifically. I'm not sure exactly how. DBus traffic? Network Manager
tasking HAL so it can't respond? I'm unsure why X believes that there
is no HAL.