failed to initialize HAL : gdm init script priority should be at least equal to dbus one

Attached lspci.

There are more people with this problem. See http://beans.seartipy.com/2006/11/25/ubuntu-610-annoyance-failed-to-initialize-hal-error/

I’ve seen this a few times. This error dialog actually comes from update-notifier. Could there be a race condition between dbus starting hald and GNOME starting update-notifier?

Wouldn't it be possible to start first hald and then GDM?
Or make update-notifier wait until hald is started?

I don't see any reason why it should be update-notifier fault :
There is a real problem if hal is started after gnome, what seams to be the case

I think this bug is due to a problem in the init script priority :
- gdm start with S13
- dbus (and so hal) start with S20
In the majority of the case there is no problem. But if you use automated login and if there a script between the 2 that take some time, it might fail.

I suggest that priority of gdm should be at least the same as dbus (20) or, to be more safe, greeter (21 or something)

bug # 84718 is a duplicate of this bug, on feisty.

I propose this one as a blocker for feisty. The casual user will be completely lost if this happens.

Basically, gdm should not start before dbus/hal, since the gnome session *depends* on dbus/hal. Relying on the user to be slow is not a good idea, or the machine to be fast enough is not a good race resolution.

The bug in update-notifier is that the error message is confusing: "internal error: failed to initialize HAL". There is no indication that the error comes from update-notifier. Also, um, why does update-notifier require HAL to be started, anyway?

Hal is use by a lot different pieces in the desktop, so if it isn't update-notifier that shows up this message, it will be show by something else.
So what is important is not to improve the update-notifier message, but to make hal running properly before gnome start.

I have a duel boot setup between a 32bit edgy and a 64bit edgy > feisty upgrade. The feisty installation shows this issue repeatedly, I think this is only since the upgrade but I'm not certain of that. For what its worth I've found running the following gets things working again for me:

sudo /etc/init.d/dbus restart

Dunno if it helps any, but when doing that I notice that avahi-daemon appears not to be running before the dbus restart but happily starts when restarting dbus.

Restarting the all dbus init scripts during a gnome session, could stop support for some working service (like avahi in your case).
The minimal should be to restart hal :
sudo /etc/dbus-1/events.d/20hal restart
The best is to simply restart gnome.

Hum, misread your comment, but anyway, sudo /etc/init.d/dbus restart should be taken with caution. It's always better to restart gnome in that case.

I see Pascal has set this bug for Edgy, but not for Feisty -- and it also affects Feisty. I have requested it to be nominated also for Feisty.

Of course, update-notifier also gets nominated -- wrongly, but I have no control over it.

Indeed we should either start gdm later or dbus earlier, whichever suits better.

I have changed the startup, putting dbus as S12, and leaving the rest as is. So far, no problems.

I'm seeing this one all the time on feisty. It started occurring when I set gdm to automatically log a particular user in (thus I suspect it is a race between HAL/DBUS and gnome-power-manager). The gnome-power-manager errors messages are as follows:

"HAL does not support power management!"

"Either HAL or DBUS are not working!"

I assume the following is from update-manager (but it is not clear at all - the only clue is the icon at the top left of the window)
"Internal error

failed to initialize HAL!"

(Perhaps another bug could be on gnome-power-manger only reporting issues like this once rather than three times and putting a title into titlebar of the error windows).

Should this bug also be against upstart?

How do you change the priority?

I would say, make the users, who have these programs, change their script prioritity and let's see if it helps...

I just got the "Internal error: failed to initialize HAL" dialog again.
My version of Ubuntu and kernel:

$ lsb_release -dsc
Ubuntu 6.10
edgy

$ uname -r
2.6.17-11-generic

Florent Mertens wrote:
> The best is to simply restart gnome.
Login out of the gnome session and logging in shows the message "Internal error: failed to initialize HAL" again!
What do you mean by restarting gnome?

Below I did a hal debug as described in the 2nd part of this wiki page: https://wiki.ubuntu.com/DebuggingRemovableDevices.

$ sudo killall hald
hald: no process killed

$ sudo hald --daemon=no --verbose=yes 2>&1 | tee hal.log
>>> see attachment <<<

$ sudo /etc/dbus-1/event.d/20hal start
 * Starting Hardware abstraction layer hald [ ok ]

Then I logged out and in again, this solves the problem since the error dialog is gone and running the following command returns:
$ ps -A | grep hald
 4565 ? 00:00:00 hald-addon-acpi
 4581 ? 00:00:00 hald-addon-keyb
 4590 ? 00:00:00 hald-addon-stor
 4592 ? 00:00:00 hald-addon-stor
 6666 ? 00:00:02 hald
 6667 ? 00:00:00 hald-runner
 6673 ? 00:00:00 hald-addon-acpi
 6684 ? 00:00:00 hald-addon-keyb
 6693 ? 00:00:00 hald-addon-stor
 6695 ? 00:00:00 hald-addon-stor

Please note: I have changed my e-mail address.

Please forward a copy of your message to <email address hidden> and update your contacts.

This e-mail account is no longer in use and I will not receive your message.

Hello,

I was struggeling with this too. When I set login to automatic, I got this 'Internal error. Failed to initialize HAL' error. For now I solved by:

sudo mv /etc/rc2.d/S13gdm /etc/rc2.d/S21gdm

to start gdm after dbus. I have not encountered nasty consequences (yet) and automatic login works now. Anyway I hope this is helpful.

I've tried some of your solutions described here and now I cant even login to gnome. I put my username and password and then it restarts the session without login in. HELP!!!

I have feisty, recently updated from edgy.
I think I had similar problems with Edgy, but the move of S13gdm to S21gdm cleared the problem.

Having updated, I have the same problem, and I noticed that when I restarted dbus, avahi-daemon was removed as not running.
I also noted that I did not have dbus in /etc/rc2.d, while there is an S13gdm (now moved to S21gdm as advised above).
So I have added S12dbus in /etc/rc2.d/ and this removes the problem.

I got the same error with Feisty beta, after a clean install on its own disk and an update (350 packages). After the clean install, no error, and Feisty could see my usb camera. After the upgrade, the "failed to initialize HAL" error came up as it did for many of you other folks, and the camera was not seen.

This workaround got rid of it for me:

sudo dpkg-reconfigure hal -- I got a message that socket /var/run/dbus/system_bus_socket did not exist. Checking, I found that the whole directory /var/run/dbus was missing. Then I made one like the one on my other system, running Edgy:

sudo mkdir /var/run/dbus
sudo chown messagebus:messagebus /var/run/dbus

Then I told dbus-daemon to make a message bus with the standard configuration file, and re-configured hal:

sudo dbus-daemon --system
sudo dpkg-reconfigure hal

On reboot, the problem had gone away, and Feisty was able once more to see my camera.

"Well," I thought, "must have been that missing directory." So, I removed /var/run/dbus and all in it, then rebooted. No HAL failure this time! And, there was /var/run/dbus belonging to messagebus:messagebus, and populated with a pid and a socket.

HTH.

On a fresh install of feisty final, using no auto-login but instead waiting until all init scripts are finished and then logging manually in, I still get the error. I tried

# sudo dpkg-reconfigure hal

which gave me:
UUID file '/var/lib/dbus/machine-id' contains invalid hex data

root@mango:/var/lib/dbus# cat machine-id
Name: adduser/homedir-permission

Right, this doesn't look like a hex value ;) I don't know where this string comes from. I deleted machine-id and did

root@mango:/var/lib/dbus# dbus-uuidgen --ensure
root@mango:/var/lib/dbus# cat machine-id
8084dbe5dda580d55fa79e0046418245

This looks better.

root@mango:/var/run/dbus# /etc/init.d/dbus restart
works now.

I'll try a reboot now to see if it still works or if my machine-id gets overwritten with invalid data again.

I got a "new" addition to this.

If the user is taken from AD through pam_winbind, the same does happen.

User on local passwd file -> All ok.
Delete the user from passwd/shadow and take the one from AD -> Auth & Co does work but the HAL bug does happening.

I got no idea whats wrong - the same configuration does work on Gentoo for example.

Had the same bug with my ubuntu 8.04.
Failed starting Hardware Abstraction Layer was resolved by renaming /etc/rc5.d/S50dbus to /etc/rc5.d/S12dbus .
As a result dbus, hal and gdm started by init in the following order:
/etc/rc5.d/S12dbus
/etc/rc5.d/S24hal
/etc/rc5.d/S30gdm