Failed to initalize HAL.

Can you please give me the output of the following commands:

  $ ps -p $(< /var/run/dbus/pid)

  pidof hald

  ls -l /etc/rc2.d/*dbus*

Was this a clean breezy install? Or did you upgrade from hoary or from a Breezy
pre-release version?

  Im having the same problem. My breezy was
  a clean install. I ran the commands you listed
  and these are the results

   $ ps -p $(< /var/run/dbus/pid)
    said the pid file was not found

     pidof hald
  just returned the command prompt

   ls -l /etc/rc2.d/*dbus*

  ls -l /etc/rs2.d/*dbus* gave me this

 lrwxrwxrwx 1 root 14 Mar 11 23:17 /ect/rc2.d
 /s12dbus -> ../init.d/dbus

 by the way this is from the post above.

> /ect/rc2.d/s12dbus -> ../init.d/dbus

Is that indeed a small 's' before the 12? It should be a capital 'S'. Or was this just a typo? (You can copy&paste from the terminal to the web browser).

Can you please try this:

  sudo /etc/init.d/dbus start
  ps -p $(< /var/run/dbus/pid)
  pidof hald

and copy&paste the outputs here? Thanks!

root@TVOM:~# sudo /etc/init.d/dbus start
 * Starting system message bus... [ ok ]
 * Starting Hardware abstraction layer: [ ok ]
root@TVOM:~# ps -p $(< /var/run/dbus/pid)
  PID TTY TIME CMD
 8153 ? 00:00:00 dbus-daemon
root@TVOM:~# pidof hald
8166
root@TVOM:~#

The /etc/init.d/dbus start output looks like dbus and hal wren't running before. Can you please answer to this bit:

> > /ect/rc2.d/s12dbus -> ../init.d/dbus
> Is that indeed a small 's' before the 12? It should be a capital 'S'. Or was this just a typo? (You can
> copy&paste from the terminal to the web browser).

If that's indeed a lower-case 's', then this would explain why dbus is not running (but I have no idea why it should be a small s, unless you manually changed this).

I looked in /etc/rc2.d and indeed the small s was a typo.

I read S12dbus.

The problem with hal started the first time the system started after the system install.

Maybe it is an upgrade problem. Do you encounter this if you install a clean dapper from scratch?

i having this issue i believe this is related somwhow with this bug report

https://launchpad.net/distros/ubuntu/+source/libpam-foreground/+bug/58165

this is the output from my system

sudo /etc/init.d/dbus start
Password:
 * Starting system message bus dbus /etc/init.d/dbus: line 38: 6906 Fallo de segmentación start-stop-daemon --start --quiet --pidfile $PIDFILE --user $DAEMONUSER --exec $DAEMON -- --system $PARAMS

dbus is not running, so i'm having the failed to initialize HAL message.

this systems is an upgrade from breezy.

i'm attaching an strace from

dbus-daemon --system

in a good system (without the problem)

and another one from a bad system

in this there's a segmentation fault message

i hope this helps to found this issue.

to be honest is truly hard to use a system with this trouble.

you cannot easily access cd nor usb pens,

i cannot believe it but mounting like the old days is really boring...

i would like to give this bug more priority.

please tell me how can i help to solve this issue

I can confirm it too in edgy. If I login just after it is possible all goes ok. But if I wait for some time I get such problem. On dapper I had this problem too.

Instead of running dbus with strace could you please run dbus with gdb, get it to segfault and attach the backtrace to this bugreport?

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 will be closed in 90 days.

--------------------

Original Message:

X-Originating-IP: [82.211.81.139]
Return-Path: <email address hidden>
Authentication-Results: mta132.mail.re4.yahoo.com from=canonical.com; domainkeys=neutral (no sig)
Received: from 82.211.81.139 (EHLO adelie.ubuntu.com) (82.211.81.139)
  by mta132.mail.re4.yahoo.com with SMTP; Sun, 12 Nov 2006 22:30:08 -0800
Received: from gangotri.ubuntu.com ([82.211.81.179])
 by adelie.ubuntu.com with esmtp (Exim 4.60 #1 (Debian))
 id 1GjVKa-0006OQ-5h
 for <email address hidden>; Mon, 13 Nov 2006 06:30:08 +0000
Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
 by gangotri.ubuntu.com (Postfix) with ESMTP id 1EEF5318915
 for <email address hidden>; Mon, 13 Nov 2006 06:30:08 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: =?utf-8?q?Sebastian_Dr=C3=B6ge?= <email address hidden>
Reply-To
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Hi,

I have upgraded from Dapper to Edgy before a month or so and everything was running smoothly till week ago. When I am logging into Ubuntu, I got the same message as above described "Failed to initialize HAL". The Problem seems to be, that dbus is not being starting properly or at the right time ???. I checked all syslinks under /etc/rc2.d/ and everything is fine.
I just saw in the above messages though that others have 'dbus' with starting number 12
(/etc/rc2.d/S12dbus), but on my laptop it is 50 (/etc/rc2.d/S50dbus).

When I logout and switch to terminal console and run:
'sudo /etc/init.d/dbus start', it says that dbus is being already started.

Running:
'sudo /etc/ini.d/dbus restart' and then logging in again fixes everything.

Should i change that starting sequence number, but then why now.? It was starting fine till week ago, and i haven't changed anything under the system startup levels.

If you need any other information that can help you, just say, because I have no idea. It's very strange.

I confirm the existence of this bug in edgy. I notice it, after setting the automatic startup login. Changing the priority number of the init script to 12 resolves the problem.

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.

I have this on Feisty sometimes. I think it's a race between hal/dbus initializing and gnome desktop loading (apps that required dbus). When I'm logged in to Gnome session and get the "Failed to initalize HAL" error, I switch to tty1 and see that hal/dbus is still in middle of its initialization-phase. Thanks to upstart and parallel start-up of init scripts, my Ubuntu boots too fast for hal/dbus.

Have this bug in Feisty.
Receive three pop-up windows when logging to Gnome:

Power Manager.
HAL does not support power management!

Internal Error
failed to initialize HAL!

Power Manager
Either HAL or DBUS are not working

Running Ubuntu Feisty on a Via C3 laptop

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.

Martin, I get this too when I have auto-login turned on in GDM. I get the 3 error messages you mention, then hald leaks memory something fierce (uses up all 3GB of my machine's memory in a few days).

When I turn off auto-login so I have to spend a few tens of seconds in GDM before Gnome fires up, everything starts up without errors. I'm not sure about the hald memory leak since I only just now figured out this workaround.

Hopefully this will be fixed as Upstart matures.

dbus init.d priority needs to be set to 12, not 20, to avoid race condition with gdm.

 dbus (1.0.2-1ubuntu3) feisty; urgency=low
 .
   * debian/rules: Start dbus at runlevel priority 12, so that it comes before
     gdm. This eliminates the race condition of starting the X session before
     hal is running. (LP: #25931 and two handfuls of dups)
   * debian/dbus.postinst: Migrate rc?.d symlinks from 20 to 12 on upgrades to
     this version.
   * debian/control: Set Ubuntu maintainer.
   * debian/rules: Clean up doc/*.html (they are generated from XML sources).

I filled a bug report about a similar problem, and I was forwarded here as my problem appeared to be similar and that I could find help here, but I cant!
The only thing I understood is to print here these:

deuce@flaptop:~$ sudo /etc/init.d/dbus start
Password:
 * system message bus already started; not starting.
 * Starting system message bus dbus deuce@flaptop:~$ ps -p $(< /var/run/dbus/pid)
  PID TTY TIME CMD
 6108 ? 00:00:00 dbus-daemon
deuce@flaptop:~$ pidof hald
6123
deuce@flaptop:~$ ls -l /etc/rc2.d/*dbus*

lrwxrwxrwx 1 root root 14 2007-03-07 16:57 /etc/rc2.d/S20dbus -> ../init.d/dbus

Can someone help? I cant access my external HD and I have a project due:( Thanks!

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!!!

deuce, if 'dbus start' fails that way, then it is already running. The easiest workaround is to just wait for some seconds at the login screen before logging in. The correct way is to rename /etc/rc2.d/S20dbus to /etc/rc2.d/S12dbus (this was recently done in Feisty).

If it does not even log in, please get .xsession-errors from your home directory and attach it here (you can log in on a text console after pressing Ctrl+Alt+F1).

how can I do that?

> how can I do that?

In a terminal with 'sudo mv /etc/rc2.d/S20dbus /etc/rc2.d/S12dbus'.

I am following this as I am having the same problems. I have checked the /etc/rc2.d folder and I don't have a S20dbus file, no dbus file in that folder at all.

I do have an @20dsub file in the /rc3.d folder I changed this to S12dbus with on effect.

This problem is getting to the stage where I might just reinstall Windows, much as I don't want to do that. aghhhhhhhh

Hi,

roberto [2007-03-13 9:14 -0000]:
> I am following this as I am having the same problems. I have checked the
> /etc/rc2.d folder and I don't have a S20dbus file, no dbus file in that
> folder at all.

Please try

  sudo ln -s ../init.d/dbus /etc/rc2.d/S12dbus

I have solved my problem. I copied the S20dbus file from /etc/rc3.d folder to /etc/rc2.d folder and renamed it to S12dbus and I now log in with no Hal error and my thumb rive working fine.

Hope this helps someone else.

Got the same error.

Internal error

failed to initialize HAL!

Im on Feisty.. I dont have a S20dBus file in my /etc/rc3.d only a S12DBUS.
And nothing dbus in my /etc/rc2.d

Any fix for this?

Aktiwers,

Quick way to see what runlevels have dbus set up:

# locate S??dbus

I ran into this HAL bug not long ago, and found that re-configuring HAL got rid of it. Short story: make sure /var/run/dbus exists, and is owned by messagebus:messagebus. You can make that directory and chown it over to the proper owner:group if it does not exist. Then do

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

Long story: same thing, but with more gory details, in my post to bug #81670.

HTH.

Hi jmrasor,

Thanks for the reply.

aktiwers@HAL:~$ locate S??dbus
/etc/rc4.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc5.d/S12dbus
aktiwers@HAL:~$

aktiwers@HAL:~$ sudo dbus-daemon --system
Failed to start message bus: Failed to bind socket "/var/run/dbus/system_bus_socket": No such file or directory
aktiwers@HAL:~$

aktiwers@HAL:~$ sudo dpkg-reconfigure hal
 * Reloading system message bus config...
  Failed to open connection to system message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
invoke-rc.d: initscript dbus, action "force-reload" failed.
 * Starting Hardware abstraction layer hald
aktiwers@HAL:~$

Thats what happends.. and the error is still there.

Any Ideas?

Thanks!

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.

PS: Did post this in a duplicate, sorry - ignore it there, this is the bug for the problem.

Addition:

I set the status to incomplete, because the bug is still there - the proposed fix does not solve the issue (in all cases, as i think i've got a new one).

Hi Guys,
I have the same problem aswell.
i get the following output
I also have a little red cross over the network icon that appears on the system tray, I think this has some connection with the HAL error.

ag@ubuntu:~$ sudo /etc/init.d/dbus start
 * system message bus already started; not starting.
 * Starting system message bus dbus
ag@ubuntu:~$ ps -p $(< /var/run/dbus/pid)
  PID TTY TIME CMD
 5758 ? 00:00:00 dbus-daemon
ag@ubuntu:~$ pidof hald

(after typing the last command i.e pidof hald, i do not get any output, just get the command prompt.

Please help me guys, this is veyyyy frustratingggggggggg

Summarising the workaround above by jmrasor, running the four commands below then relogging fixes the problem temporarily. I have to do this on every boot to get my USB attached harddrives to be recognised, which is thankfully infrequent ;).

sudo mkdir /var/run/dbus
sudo chown messagebus:messagebus /var/run/dbus
sudo dbus-daemon --system
sudo dpkg-reconfigure hal

Yay! Thanks to this thread I've just noticed that /etc/rc2.d/S12dbus was missing.

After copying it from /etc/rc3.d/S12dbus I no longer get this error on my up to date Breezy->Feisty->Gutsy machine.

I still have the error like mentioned above, although i tried all fixes which are told here - no success yet. Peters "way" doesn't help either.

/var/lib/dpkg/info/dbus.postinst assumes that old priorities were always 20:

# fix rc symlink priorities for upgrades from older versions
if [ "$1" = configure ] && dpkg --compare-versions "$2" lt-nl 1.0.2-1ubuntu3; then
    echo "Fixing up startup script priorities..."
    for l in 2 3 4 5; do
        old=/etc/rc$l.d/S20dbus
        new=/etc/rc$l.d/S12dbus
        if [ -e $old ] && ! [ -e $new ]; then
            mv $old $new
        fi
    done
fi

However, in my case the rc2.d priority was 50 (don't ask me why), so I removed all the dbus symlinks:

localhost# update-rc.d -f dbus remove
 Removing any system startup links for /etc/init.d/dbus ...
   /etc/rc0.d/K20dbus
   /etc/rc1.d/K20dbus
   /etc/rc2.d/S50dbus
   /etc/rc3.d/S12dbus
   /etc/rc4.d/S12dbus
   /etc/rc5.d/S12dbus
   /etc/rc6.d/K20dbus

Then, I just remade them using the command from the last section of dbus.postinst:

localhost# update-rc.d dbus multiuser 12 20
 Adding system startup for /etc/init.d/dbus ...
   /etc/rc1.d/K20dbus -> ../init.d/dbus
   /etc/rc2.d/S12dbus -> ../init.d/dbus
   /etc/rc3.d/S12dbus -> ../init.d/dbus
   /etc/rc4.d/S12dbus -> ../init.d/dbus
   /etc/rc5.d/S12dbus -> ../init.d/dbus

Then rebooted and now all the troubles about hal, dhcdbd, etc. are gone.

So I guess that dbus.postinst should not assume the old priority value.

HTH

Can someone else review whether my fix solves their problems with hal?

hi paul j here.

i am running gutsy tribe 5. my startup would run and then drop into text mode at Starting system tools backends system tools backends. machine would then hang for 2-3 minutes gdm would start and as soon as desktop loaded Failed to initialize HAL. i looked around and found dbus and hal starting as S12dbus and S12hal in /etc/rc2.d/. i also saw in upstart info that hal is dependent on dbus so i changed hal to S13hal and gdm to S14gdm in /etc/rc2.d/ by deleting links and relinking. everything is fine now. i dont know if this helpful or correct. i hope it is helpful

I did an upgrade from Feisty to Gutsy Tribe 5, my installation is actually through WABI. Alex, your fix didn't work on my installation and neither did Paul's. I'm still getting hald not started.

Checking the systems logs I see:
administrator@ubuntu:/var/log$ tail syslog Sep 13 11:06:07 ubuntu hald[6990]: 11:06:07.838 [I] hald_dbus.c:4807:
local server is listening at
unix:abstract=/var/run/hald/dbus-CEFHnlshb0,guid=49f595eaaa554420a5c33c0046e951df
Sep 13 11:06:07 ubuntu hald[6990]: 11:06:07.888 [I] hald_runner.c:299:
Runner has pid 6991
Sep 13 11:06:07 ubuntu hald[6990]: 11:06:07.889 [W] ci-tracker.c:200:
Could not get uid for connection:
org.freedesktop.DBus.Error.NameHasNoOwner Could not get UID of name
'org.freedesktop.DBus': no such name
Sep 13 11:06:07 ubuntu hald[6990]: 11:06:07.889 [E] hald_dbus.c:4462:
Cannot get caller info for org.freedesktop.DBus Sep 13 11:06:07 ubuntu hald[6990]: 11:06:07.892 [I] hald_runner.c:180:
runner connection is 0x8094ac8
Sep 13 11:06:07 ubuntu hald[6990]: 11:06:07.894 [I] mmap_cache.c:161:
Regenerating fdi cache..
Sep 13 11:06:17 ubuntu hald[6990]: 11:06:17.901 [I] mmap_cache.c:137: In regen_cache_cb exit_type=1, return_code=0 Sep 13 11:06:17 ubuntu hald[6990]: 11:06:17.902 [E] mmap_cache.c:190:
fdi cache regeneration failed!
Sep 13 11:06:17 ubuntu hald[6990]: 11:06:17.902 [I] mmap_cache.c:193:
fdi cache generation done
Sep 13 11:06:17 ubuntu hald[6990]: 11:06:17.902 [I] mmap_cache.c:251:
cache mtime is 1189629072

Just wanted to say I had the exact same problem as paul j and his solution worked for me.

Same here , somehow(??!!) rc2.d,dbus priority was 50 on a feisty to gutsy beta.
Renaming it to S20dbus works for now ..

seemed to get same hal failure after large (100mb+) gutsy beta upgrade today 29/9/07. Seems that reverting CONCURRENCY in /etc/init.d/rc back to none from shell solved this for me

Tim and other still suffering this, could you please check current priorities of dbus, hal and dhcdbd? These are mine:

$ ls -1 /etc/rc?.d/*dbus
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus

$ ls -1 /etc/rc?.d/*dbus
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus

$ ls -1 /etc/rc?.d/*dhcdbd
/etc/rc0.d/K16dhcdbd
/etc/rc1.d/K16dhcdbd
/etc/rc2.d/S24dhcdbd
/etc/rc3.d/S24dhcdbd
/etc/rc4.d/S24dhcdbd
/etc/rc5.d/S24dhcdbd
/etc/rc6.d/K16dhcdbd

drumour wrote on 2007-09-29: (permalink)

seemed to get same hal failure after large (100mb+) gutsy beta upgrade today 29/9/07. Seems that reverting CONCURRENCY in /etc/init.d/rc back to none from shell solved this for me.

I can confirm that this works. I had the same problem.

Do you guys use automatix, envy, or any other third-party application that modifies Ubuntu in a global way? Priority 50 has never been a default in Ubuntu proper.

Martin, I never used any of those and I actually had /etc/rc2.d/S50dbus. See my previous comment above:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/25931/comments/41

I was trying to install Ubuntu on a friend's laptop.

Off of the live cd, both Feisty and Gutsy Beta work just fine. Once I installed either, though, after restarting it a couple times, this error would pop up.............

Laptop is a Sony Vaio VGN-S260. I received similar results to Alex Muntada... (these are just copied off of his)

$ ls -1 /etc/rc?.d/*hal
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus

$ ls -1 /etc/rc?.d/*dbus
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus

Tried making it so that hal was after dbus, shifting gdm to 14 and hal to 13.. to no avail.

>Gelke wrote on 2007-10-01: (permalink)
>
>>drumour wrote on 2007-09-29: (permalink)
>>
>>seemed to get same hal failure after large (100mb+) gutsy beta upgrade today 29/9/07. Seems that reverting CONCURRENCY in /etc/init.d/rc back to >>none from shell solved this for me.
>
>I can confirm that this works. I had the same problem.

Resolved my 'Failed to initialize HAL' error in Gutsy Beta. Never would have figured that one out myself, thanks!

CONCURRENCY=shell in /etc/init.d/rc caused the problem for me, I had to set it back to CONCURRENCY=none and my problem was solved for gutsy beta

 I can confirm that CONCURRENCY=shell in /etc/init.d/rc gives me the hal problem here too (and that CONCURRENCY=none sorts it out), this on a Core 2 Duo machine.

I, too have this problem on a Core 2 Duo machine - although CONCURRENCY /etc/init.d/rc is set to none.

BTW: I, too have a S50dbus rc entry.

I tried recreating the rc entries as mentioned by Alex (https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/25931/comments/41) and it works like a charm.
Muchos gracias :)

I tried the same thing that LCID Fire did, then I changed CONCURRENCY=none back to CONCURRENCY=shell in /etc/init.d/rc, and rebooted, but I'm still getting the same error.

As a quick note - my CONCURRENCY is still set to none - I didn't change that.

CONCURRENCY=none seems to have fixed the problem here.

okay I had the problem with failed to initial Hal at startup.

After reading many posts here is what i did to fix it:

in /etc/rc2.d/

I changed S12hal to S13hal using the following in terminal

'sudo mv /etc/rc2.d/S12hal /etc/rc2.d/S13hal'

This was a fresh install of Gutsy RC1 64bit.

Yesterday i upgraded to gutsy. On the first reboot i had no problem!! This morning i had the HAL error!!

When i click on the off button, nothing happens... The network applet say that there is no network connection but it's not true... Other disks are not mounted...

I followed all the suggestions in this page with no results:

- CONCURRENCY in /etc/init.d/rc was just set to none...

- renamed S12hal to S13hal and S13gdm to S14gdm in /etc/rc2.d (i tried renaming them even in /etc/rc(3,4,5).d)

- "sudo update-rc.d -f dbus remove" and then "sudo update-rc.d dbus multiuser 12 20" as suggested by Alex Muntada (https://bugs.launchpad.net/~alex.muntada)

I have a core 2 duo machine.

" ps -p $(< /var/run/dbus/pid)" give -->
PID TTY TIME CMD
 4969 ? 00:00:00 dbus-daemon

"pidof hald" and then "ls -l /etc/rc2.d/*dbus*" give -->
lrwxrwxrwx 1 root root 14 2007-10-20 11:37 /etc/rc2.d/S12dbus -> ../init.d/dbus

These are the current priorities of dbus, hal and dhcdbd:

$ ls -1 /etc/rc?.d/*dbus
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus

$ ls -1 /etc/rc?.d/*hal
/etc/rc1.d/K16hal
/etc/rc2.d/S12hal
/etc/rc3.d/S12hal
/etc/rc4.d/S12hal
/etc/rc5.d/S12hal

$ ls -1 /etc/rc?.d/*dhcdbd
/etc/rc0.d/K16dhcdbd
/etc/rc1.d/K16dhcdbd
/etc/rc2.d/S24dhcdbd
/etc/rc3.d/S24dhcdbd
/etc/rc4.d/S24dhcdbd
/etc/rc5.d/S24dhcdbd
/etc/rc6.d/K16dhcdbd

By now the problem disappeared with the reinstallation of the package "hal" using synaptic! :)

I can also confirm setting CONCURRENCY=none or 'none' fixes the problem. Side effect is a slower boot. Something must be wrong with the kernel internally because this happened after I upgraded to the most recent kernel. How odd...

Does the Concurrency function refer to something inside the kernel?

I am running an Intel Core Duo 1.66 GHz on Gutsy Gibbon.

It seems like it is only affecting Intel Core Duo machines!?

No my machine has an AMD athlon 2800+

I had the problem with HAL after upgrade from 7.04 to Gutsy (7.10) two days ago. I found the file /etc/rc2.d/S50dbus, and after renaming it to S12dbus, the problem was solved.

Reinstallation of HAL using synaptic solved some problems (missing suspend to ram and suspend to disk in Shutdown-Menu, no start of System->Settings->gnome-power-preferences), but the error occured again after next reboot.
My first Upgrade to 7.10 was interrupted (missing free disk), perhaps this is the reason for S50dbus?
My machine is Intel Pentium3, 667 Mhz.

Same problem here, after Feisty to Gutsy upgrade.
No NetworkManager, hald won't start, exit menu options take well over 1 minute to pop up.
See complete description here: http://ubuntuforums.org/showthread.php?t=583940
Reinstalling Hal and Dbus makes no difference.
Reordering init script links also makes no difference.
Changing CONCURRENCY around also makes no difference.
Gutsy's HAL just won't start...

AMD64 dual core

Same behaviour here.
I tried to uninstall/reinstall hal dbus but nothing.
Seems like anyway that if I boot ubuntu in rescue mode [single mode] I'm able to run and start dbus and hal.
This *does not* happen instead with normal boot.

Right now the steps I do to have my working gnome desktop are:
1. boot in rescue mode
2. at prompt # I give 'gdm'
3. slowly my gdm appears and I can login.

this is a pain anyway, it would be great if someone could fix the hal problem.
Thanks and regards.

I'm on a 'hp compaq d330 dt'.

After booting in single mode I tried to give a `strace /etc/init.d/dbus start` and after a few seconds it stops in a "wait4 (-1, " message.

HAL error message gone for me after change concurrency back to none from shell in /etc/init.d/rc .

I'm running Gusty on an Intel Core 2 Duo e6550.

I changed the concurrency setting after reading an article on the net saying that chaning the setting would speed up Ubuntu, especially on dual core machines...apparently, that's not the case?

I am another "Failed to initialize HAL" Gutsy user. My computer is a Dell Inspiron 600m laptop. 1G RAM, 80G HD. I had no problems in Fiesty. Did a network upgrade to get Gutsy. WUBI originally used to install Fiesty.

Things are pretty sluggish.

System > Administration > Network Settings experience. Dialog is greyed out for about 90 seconds. Then populates. Was able to set-up ethernet and wireless connections, but had to use manual settings. Navigating in this dialog takes plenty of patience. Often over a minute between actions.

System > Preferences > Hardware Information Unpopulated dialog opens for about 5 seconds then closes.
System > Preferences > Power Management No dialog ever opens.

Concurrency setting in /etc/init.d/rc is set to 'none'.

I have a theory...

Does anybody have Compiz Fusion turned on? What type of installation (git, stable, or default Gutsy CF)? Can you turn off Compiz fusion or turn off the Dbus plugin manually?

Also to note, Network manager is not telling me via bubble that I am connected.

I get this too.

Concurrency is set to 'none'.

# ls -l /etc/rc?.d/*dbus
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus

# ls -l /etc/rc?.d/*hal
/etc/rc1.d/K16hal
/etc/rc2.d/S13hal
/etc/rc3.d/S12hal
/etc/rc4.d/S12hal
/etc/rc5.d/S12hal

#ls -l /etc/rc?.d/*dhcdbd
/etc/rc0.d/K16dhcdbd
/etc/rc1.d/S24dhcdbd
/etc/rc2.d/S24dhcdbd
/etc/rc3.d/S24dhcdbd
/etc/rc4.d/S24dhcdbd
/etc/rc5.d/S24dhcdbd
/etc/rc6.d/K16dhcdbd

By running the following commands, I was able to then start GDM and log in without getting the error:

/etc/init.d/dbus start
/etc/init.d/dhcdbd start
/etc/init.d/hal start

Note that if you try starting hal before dhcdbd, hal will not start properly. Also, after starting dhcdbd, you will not be given another prompt. Rather, you will just be given a blank line. You can still start hal. Also, after starting hal, there is constant output (You are not given another command prompt). You can still start gdm like you normally would from the command line.

Is there any way to start these things automatically, so I don't have to boot into the command line every time?

oh my...
I disabled dbus in 'services' to try what st33med suggested. Now my permissions are removed and I can't try you suggestions. I also cannot get into 'services'.

Do you know how I can get 'services' to open again. I'm a newbee as you can figure.

I reinstalled dbus. I can try your recommendations now.

I tried you suggestions. Below is what I got. I am the admin of this system, but I don't have the permissions I guess.

abcd@ubuntu:~$ /etc/init.d/dbus start
open: Permission denied
 * Removing stale PID file /var/run/dbus/pid.
rm: cannot remove `/var/run/dbus/pid': Permission denied
abcd@ubuntu:~$ /etc/init.d/dhcdbd start
open: Permission denied
 * Starting DHCP D-Bus daemon dhcdbd open: Permission denied
                                                                         [ OK ]
abcd@ubuntu:~$ /etc/init.d/hal start
open: Permission denied
 * Can't start Hardware abstraction layer - detected chrooted sessio
abcd@ubuntu:~$

Kloudy you probably have to use the sudo command like sudo /etc/init.d/dbus start

By the way I have exactly the same problems and for me 3-M's suggestions did not work

I ran into this problem after a Feisty->Gusty upgrade on a Mac G3 (PowerPC) machine.
after renaming /etc/rc2.d/S50dbus to /etc/rc2.d/S12dbus the problem went away.
(all other rc?.d/*dbus links where correct - only the rc2.d one was wrong).

Since this is a fully backed-up machine, I checked my pre-upgrade backup (which was updated minutes before the upgrade): the file was properly named
/etc/rc2.d/S12dbus
Therefore it is the upgrade process that named the link S50dbus
Hope this helps...

Just adding the output of hald that I found in my syslog (when doing "sudo hald --daemon=yes --verbose=yes --use-syslog"):

Oct 21 16:46:39 thechair hald[10155]: 16:46:39.371 [i] hald.c:529: hal 0.5.9.1
Oct 21 16:46:39 thechair hald[10155]: 16:46:39.371 [i] hald.c:538: Will daemonize
Oct 21 16:46:39 thechair hald[10155]: 16:46:39.371 [i] hald.c:539: Becoming a daemon
Oct 21 16:46:39 thechair hald[10156]: 16:46:39.373 [i] hald_dbus.c:4807: local server is listening at unix:abstract=/var/run/hald/dbus-GDedVsW496,guid=1369e3dc8d0263f932971c0047
1b745f
Oct 21 16:46:39 thechair hald[10156]: 16:46:39.377 [i] hald_runner.c:299: Runner has pid 10157
Oct 21 16:46:39 thechair hald[10156]: 16:46:39.378 [W] ci-tracker.c:200: Could not get uid for connection: org.freedesktop.DBus.Error.NameHasNoOwner Could not get UID of name 'org.freedesktop.DBus': no such name
Oct 21 16:46:40 thechair hald[10156]: 16:46:39.378 [E] hald_dbus.c:4462: Cannot get caller info for org.freedesktop.DBus
Oct 21 16:46:40 thechair hald[10156]: 16:46:39.380 [i] hald_runner.c:180: runner connection is 0x6536b0
Oct 21 16:46:40 thechair hald[10156]: 16:46:39.382 [i] mmap_cache.c:161: Regenerating fdi cache..
Oct 21 16:46:49 thechair hald[10156]: 16:46:49.388 [i] mmap_cache.c:137: In regen_cache_cb exit_type=1, return_code=0
Oct 21 16:46:49 thechair hald[10156]: 16:46:49.388 [E] mmap_cache.c:190: fdi cache regeneration failed!
Oct 21 16:46:49 thechair hald[10156]: 16:46:49.388 [i] mmap_cache.c:193: fdi cache generation done
Oct 21 16:46:49 thechair hald[10156]: 16:46:49.388 [i] mmap_cache.c:251: cache mtime is 1192868046

Notice the error messages?... related to DBUS, I think...

Good news, folks!
Got my system working!
Did "sudo mv /var/cache/hald/fdi-cache~ /var/cache/hald/fdi-cache" and restarted the PC, and now it looks alright!!!
See bug #139155 for more info.

Actualy, the correct way to do it seems to be:
sudo /usr/lib/hal/hald-generate-fdi-cache
(see bug #146812)

Got my HAL working even through a complete power down and restart!

Here are the steps I took. (All are included above in previous posts.)

Compared my /etc/rc2.d filenames to those posted above. My rc2.d was S50dbus instead of S12dbus

sudo mv /etc/rc2.d/S50dbus /etc/rc2.d/S12dbus

sudo mv /var/cache/hald/fdi-cache~ /var/cache/hald/fdi-cache

Restarted PC and all seems fine.

I still have CONCURRENCY in /etc/init.d/rc set to none from shell. Does anyone think I should change it to shell to get faster boot-up speed, or will that hose up my HAL fixes again? I am not running a dual core machine.

Thanks to all the posters for your help and file comparisions.

Hi,

I cannot have the system booting also giving '/usr/lib/hal/hald-generate-fdi-cache'.
It's dbus that doesn't start now... I attach a strace output.
If I boot normally I see the system blocked on a 'Starting dbus ...' of something like that.
I have to boot into rescue mode. Then at prompt 'strace /etc/init.d/dbus start' gives this the output in the attachment.
Is there some command to refresh the cache for dbus like for hald?

root@mybox:/etc/rc2.d# ls | sort
K08vmware
README
S05vbesave
S10acpid
S10powernowd.early
S10sysklogd
S12dbus
S13hal
S16openvpn
S16ssh

Kloudy try using CONCURRENCY=shell and report if the HAL-Problem reoccurs. I would be interested in the outcome :)

I set the CONCURRENCY=shell and the HAL problem came back. rc2.d stayed at S12dbus this time, no S50dbus

Set CONCURRENCY=none, rebooted and HAL is working again.

The boot process is still slower than I remember in Feisty. I'll bet there still is a tweek somewhere to fix the real problem.

Got my HAL working even with CONCURRENCY in /etc/init.d/rc set to shell.

Here are the steps I took. (All are included above in previous posts and Bug #149881 link https://bugs.launchpad.net/ubuntu/+source/hal/+bug/149881 .)

Changed the CONCURRENCY setting by:

sudo gedit /etc/init.d/rc and editing CONCURRENCY=none to CONCURRENCY=shell. Then saving.

Compared my /etc/rc2.d filenames to those posted above. My rc2.d was S50dbus instead of S12dbus. Changed that by:

sudo mv /etc/rc2.d/S50dbus /etc/rc2.d/S12dbus

Saw in another thread that hal should be set to 13 so that it starts after dbus is started. My HAL was 12. Fixed that by:

sudo mv /etc/rc2.d/S12hal /etc/rc2.d/13hal

Another post said to change the Hal cache. Did that by:

sudo mv /var/cache/hald/fdi-cache~ /var/cache/hald/fdi-cache

Restarted PC and all seems fine.

Thanks to the Ubuntu posters for your help. Gutsy still starts up awlfully slow compared to Feisty.

Any other ideas are appreciated.

Kloudy can you please post your `ls /etc/rc2.d | sort`? I'm wondering if there's something missing on my box before dbus and hal starting..

thanks and regards

Pescio, here is my ls /etc/rc2.d | sort :

README
S05vbesave
S10acpid
S10powernowd.early
S10sysklogd
S10xserver-xorg-input-wacom
S11klogd
S12dbus
S12sl-modem-daemon
S13gdm
S13hal
S19cupsys
S20apmd
S20apport
S20hotkey-setup
S20makedev
S20nvidia-kernel
S20powernowd
S20rsync
S22consolekit
S24avahi-daemon
S24dhcdbd
S89anacron
S89atd
S89cron
S90binfmt-support
S98usplash
S99acpi-support
S99laptop-mode
S99rc.local
S99rmnologin
S99stop-readahead

Good news guys, I fixed it!

Fixing the init scripts I saw that klogd was blocking the booting process. I googled for "starting kernel daemon" and came here
https://bugs.launchpad.net/ubuntu/+bug/150006

Simply changing something on ldap.conf solved my problem. I'm on a ldap/AD managed lan.

Rebooted and voilà, the init process came to gdm.
I was wrongly thinking that it could be an hal/dbus problem because I removed the S11klogd script, which seemed to be bad.
Anyway thinking that it was a ldap timeout problem was really hard!

thanks.

That explains everything! I activated klogd (not knowing that it was kernel log when I deactivated it O.o) and that problem came up. I will try it later.

Thanks.

Ok, I also got booting on Gutsy with CONCURRENCY=shell to work using just

sudo mv /etc/rc2.d/S12hal /etc/rc2.d/S13hal
(Kloudy actually had a typo there moving "S12hal" to "13hal", which of course wouldn't work)
But shell didn't really speed up my boot. I still boot up in 25s, which isn't too bad either, but no improvement :)

This threat has been quiet for a while but I'm hoping there's still people reading this.

I've got the same problem, obviously. This is what I've tried so far:

- CONCURRENCY in /etc/init.d/rc was and is set to none

- Renamed the S12hal to S13hal in /etc/rc2.d

- "sudo update-rc.d -f dbus remove" and then "sudo update-rc.d dbus multiuser 12 20" as suggested by Alex Muntada (https://bugs.launchpad.net/~alex.muntada)

- Reinstalled package "hal"

- Tried "sudo dbus-daemon –system" and then "sudo dpkg-reconfigure hal"

- "sudo mv /var/cache/hald/fdi-cache~ /var/cache/hald/fdi-cache" didn't work since there was no "/var/cache/hald/fdi-cache~" so I did the " sudo /usr/lib/hal/hald-generate-fdi-cache" instead

- Used the command "sudo sysv-rc-conf" and checked the taps for hal for runlevels 2-5 as suggested in some other forum.

- I even added an endline to /etc/fstab as suggested in some other place

"ps -p $(< /var/run/dbus/pid)" gives ---->

 PID TTY TIME CMD
 4574 ? 00:00:00 dbus-daemon

Here are the current priorities of hal, dbus and dhcdbd

$ ls -1 /etc/rc?.d/*hal
/etc/rc1.d/K16hal
/etc/rc2.d/S13hal
/etc/rc3.d/S12hal
/etc/rc4.d/S12hal
/etc/rc5.d/S12hal

$ ls -1 /etc/rc?.d/*dbus
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus

$ ls -1 /etc/rc?.d/*dhcdbd
/etc/rc0.d/K16dhcdbd
/etc/rc1.d/K16dhcdbd
/etc/rc2.d/S24dhcdbd
/etc/rc3.d/S24dhcdbd
/etc/rc4.d/S24dhcdbd
/etc/rc5.d/S24dhcdbd
/etc/rc6.d/K16dhcdbd

I also have the same problem. I do too the same things tape did in the previous comment.

But when I tried

$ ls -1 /etc/rc?.d/*hal
ls: /etc/rc?.d/*hal: No such file or directory

$ ls -1 /etc/rc?.d/*dbus
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus

$ ls -1 /etc/rc?.d/*dhcdbd
ls: /etc/rc?.d/*dhcdbd: No such file or directory

Maybe there is something missing

I changed to older kernel and now it works fine. Except my Open Office keeps freezing, but I expect this to be another bug.

I just upgraded to Gutsy and am seeing this problem too. With all due appreciation for the benefits of free software (really!) I find it incredible that this bug has persisted through so many ubuntu releases, has been _refused_ for Gutsy, and that no Ubuntu developer has described a definitive and reliable workaround in this bug entry.

I am running Hardy Heron with kernel 2.6.22-14-generic on an Dell Inspiron 6400 and having this problem since I installed kernel 2.6.24. Now it does not matter wich kernel I boot, I am getting the error message on my desktop. When starting hal on the command line there's no problem.

If you would like to have information or logs, just ask. I will be glad to help.

Peter

I had a clean install of Gutsy on an AMD 2800+. No problems. I then manually started tuning for boot speed and changed the /etc/init.d/rc file and made CONCURRENCY=shell. Upon reboot, I immediately received this issue. I did the ls -l /etc/rc?.d/*hal *dbus and they had a S12 (everything as it should be). I manually changed the rc file back and made CONCURRENCY=none. Upon reboot, I no longer experienced this problem.

Just thought I would add this experience to the list in case someone has forgotten something they have tweaked and started getting this issue. I don't reboot often, so when I did get this, it took me a while to figure out what I had done.

Just did a fresh install of Hardy Alpha 3 everything was fine. Ran apt-get update and apt-get upgrade, rebooted and how have the same error.

I had the exact same problem as Paul Belanger, except I used aptitude update.

Same problem as Paul, on Macbook Pro 1st gen with Hardy alpha 3. Most of the proposed solutions didn't work.

Also started to happen for me after some updates in alpha 3. Bad thing is wireless no longer works, so no internet there. Didn't happen in fresh alpha 3

I have the same problem. I attached the output of "sudo hald --verbose=yes --daemon=no"

Moving the hal init.d script fixed it for me.

I got the error on a newly installed 64bits Gutsy setup, after I changed the init rc setting to concurrency and changed gdm to autologin.

The thing is, I didn't get the race condition with my old harddrive which is slower; I went from a WD raptor to a Mtron 7000 pro.
That might be why the race is hard to reproduce.

Some one should split this bug into more defined bug reports or something. I feel like there are atleast 3-4 other issues which causes the same error, which isn't all that related to the init.d boot order.

Correction; it does'nt matter if I have GDM autologin on or off. I still get the error if I turn on concurrent boot.

I have the same problem on same release. I'm running old Pentium-3 system. since then, no network. I'm not a Linux expert but lot of debugging experience. let me know what to check and I'll send the results.

I too have the same problem Kubuntu Hardy 2.6.24-4 kernel my error as follows on apt-get upgrade...

Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
7 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Setting up hal (0.5.10-5ubuntu5) ...
* Reloading system message bus config... Failed to open connection to system message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
invoke-rc.d: initscript dbus, action "force-reload" failed.
polkit-auth: This operation requires the system message bus and ConsoleKit to be running
polkit-auth: AuthorizationAlreadyExists: An authorization for uid 107 for the action org.freedesktop.policykit.read with constraint '' already exists
dpkg: error processing hal (--configure):
subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of hwdb-client-common:
hwdb-client-common depends on hal; however:
Package hal is not configured yet.
dpkg: error processing hwdb-client-common (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of hwdb-client-kde:
hwdb-client-kde depends on hwdb-client-common; however:
Package hwdb-client-common is not configured yet.
dpkg: error processing hwdb-client-kde (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of kde-guidance-powermanager:
kde-guidance-powermanager depends on hal; however:
Package hal is not configured yet.
dpkg: error processing kde-guidance-powermanager (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of kubuntu-desktop:
kubuntu-desktop depends on hal; however:
Package hal is not configured yet.
kubuntu-desktop depends on hwdb-client-kde; however:
Package hwdb-client-kde is not configured yet.
dpkg: error processing kubuntu-desktop (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of network-manager:
network-manager depends on hal (>= 0.5.7.1); however:
Package hal is not configured yet.
dpkg: error processing network-manager (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of network-manager-kde:
network-manager-kde depends on network-manager (>= 0.6.2); however:
Package network-manager is not configured yet.
dpkg: error processing network-manager-kde (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
hal
hwdb-client-common
hwdb-client-kde
kde-guidance-powermanager
kubuntu-desktop
network-manager
network-manager-kde
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@stinkpad:~#

Hope this helps! Cary

I also got the HAL notification after changing my concurrency to 'shell', renamed of S12hal to S13hal was all I needed to do. AMD turion dual @1.6 MHz.

wups, make that Ghz

I was able to "fix" this problem by installing all new updates.

Because I was unable to use WLAN I had to do the following steps:

1. Boot from the Ubuntu CD
2. Connecto to your WLAN (i.e. make sure that you have an internet connection)
3. Mount your linux partition (on my computer it got mounted at /media/disk)
4. Open the terminal
5. Do binding mounts
    sudo mount --bind /dev /media/disk/dev
    sudo mount --bind /proc /media/disk/proc
    sudo mount --bind /sys /media/disk/sys
6. chroot into your linux
    sudo chroot /media/disk
7. Update your system
    apt-get update
    apt-get dist-upgrade
8. Reboot

Now your system should be alive again.

worked
thanks
but what is the fix

Another report for gutsy, with upstart concurrency enabled. I fixed this with mv /etc/rc2.d/S12hal /etc/rc2.d/S13hal. Is there any chance hal and dbus could have different startup numbers for hardy?

I encountered this error on a Debian Etch installation on a MacBook, dist upgrading to the Testing version.

* Reloading system message bus config... Failed to open connection to system message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
invoke-rc.d: initscript dbus, action "force-reload" failed.

Repeated retries at apt-get dist-upgrade failed with the same error until I manually restarted dbus by:

/etc/init.d/dbus restart

Then, the dist-upgrade worked fine. And the machine works as expected without any dbus/hal issues there after.

After last GDM upgrade (version 2.20.3-0ubuntu3) on Hardy Alpha 4 I got this error on a Compaq Proliant 400 with AGP video card ATI Rage 3D. Tried to reinstall or downgrade Hal to a prior version was impossible due to dependency issues.
Packages with dependency related are:
gnome-mount
gnome-power-manager
gnome-volume-manager
hwdb-client-common
hwdb-client-gnome
network-manager
network-manager-gnome
sound-juicer
ubuntu-desktop
update-notifier

I had exactly the same after few weeks of use of a fresh Gutsy install, with apparently no reason.
I tried everything listed here and elsewhere:
- concurrency set to "none" (this never changed)
- reordered /etc/rc2.d/ levels (S12dbus and S13hal)
- installed/reinstalled packages
- reconfigured all packages

but still dbus was up, hald refused to start.
Then I checked:

less /etc/default/hal

and output was

DAEMON_OPTS=

Then I changed it with:

sudo nano /etc/default/hal

into:
DAEMON_OPTS=--retain-privileges

then save, and rebooted.
I'm not sure if the above tried procedures were somehow useful or just wasted time, but the problem is now solved.

Hope this helps.
-E-

I would like to know how to change message bus to start from /var/run/dbus instead of /usr/local/var/run/dbus

marcos@proliant_400:/etc/init.d$ sudo dbus-daemon --system
Failed to start message bus: Failed to bind socket "/usr/local/var/run/dbus/system_bus_socket": No such file or directory
marcos@proliant_400:/etc/init.d$

Dbus and Hal are broken and I can't reinstall them because dependency problems with hwdb-client-common and hwdb-client-gnome

When I try to reinstall dbus and hal I got the following errors ...

marcos@proliant_400:~$ sudo dpkg-reconfigure dbus
/usr/sbin/dpkg-reconfigure: dbus está quebrado ou não completamente instalado
marcos@proliant_400:~$ sudo dpkg-reconfigure hal
/usr/sbin/dpkg-reconfigure: hal está quebrado ou não completamente instalado
marcos@proliant_400:~$

I just reinstalled Hardy A4 after struggling an effort to recover broken packages dbus and hal without success.
Sorry but now I can't give any more feedbacks to solve this bug.

Hardy Heron Alpha 4
I have had this error for a couple or few days after an update.
My computer starts up, then an error message pops up "Internal Error Failed to initialize HAL!.
U.S.B. Wireless adapter does not work quite right.
Ethernet connect is not stable.
Icon in notify window has <!> exclamation point inside an orange triangle below the network status icon.
Shutdown takes a long long time, minutes and really slows everything down.

root@2HewittRand-desktop:~# ps -p $(< /var/run/dbus/pid)
  PID TTY TIME CMD
 4941 ? 00:00:00 dbus-daemon
root@2HewittRand-desktop:~# pidof hald
root@2HewittRand-desktop:~# ls -l /etc/rc2.d/*dbus*
lrwxrwxrwx 1 root root 14 2008-02-06 02:53 /etc/rc2.d/S12dbus -> ../init.d/dbus
root@2HewittRand-desktop:~#
root@2HewittRand-desktop:~# sudo /etc/init.d/dbus start
 * system message bus already started; not starting.
root@2HewittRand-desktop:~# ps -p $(< /var/run/dbus/pid)
  PID TTY TIME CMD
 4941 ? 00:00:01 dbus-daemon
root@2HewittRand-desktop:~# pidof hald
root@2HewittRand-desktop:~#
root@2HewittRand-desktop:~# sudo mv /etc/rc2.d/S20dbus /etc/rc2.d/S12dbus
mv: cannot stat `/etc/rc2.d/S20dbus': No such file or directory
root@2HewittRand-desktop:~#
root@2HewittRand-desktop:~# sudo ln -s ../init.d/dbus /etc/rc2.d/S12dbus
ln: creating symbolic link `/etc/rc2.d/S12dbus': File exists
root@2HewittRand-desktop:~#
root@2HewittRand-desktop:~# locate S??dbus
/etc/rc5.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc2.d/S12dbus
root@2HewittRand-desktop:~#
root@2HewittRand-desktop:~# sudo dbus-daemon --system
Failed to start message bus: The pid file "/var/run/dbus/pid" exists, if the message bus is not running, remove this file
root@2HewittRand-desktop:~#
root@2HewittRand-desktop:~# sudo dpkg-reconfigure hal
 * Stopping Hardware abstraction layer hald [ OK ]
 * Reloading system message bus config... [ OK ]
 * Starting Hardware abstraction layer hald invoke-rc.d: initscript hal, action "start" failed.
root@2HewittRand-desktop:~#
root@2HewittRand-desktop:~# sudo mkdir /var/run/dbus
mkdir: cannot create directory `/var/run/dbus': File exists
root@2HewittRand-desktop:~# sudo chown messagebus:messagebus /var/run/dbus
root@2HewittRand-desktop:~# sudo dbus-daemon --system
Failed to start message bus: The pid file "/var/run/dbus/pid" exists, if the message bus is not running, remove this file
root@2HewittRand-desktop:~# sudo dpkg-reconfigure hal
 * Stopping Hardware abstraction layer hald [ OK ]
 * Reloading system message bus config... [ OK ]
 * Starting Hardware abstraction layer hald invoke-rc.d: initscript hal, action "start" failed.
root@2HewittRand-desktop:~#
root@2HewittRand-desktop:~# ls -1 /etc/rc?.d/*dbus
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus
root@2HewittRand-desktop:~# ls -1 /etc/rc?.d/*dbus
/etc/rc1.d/K20dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus
root@2HewittRand-desktop:~# ls -1 /etc/rc?.d/*dhcdbd
/etc/rc0.d/K16dhcdbd
/etc/rc1.d/K16dhcdbd
/etc/rc2.d/S24dhcdbd
/etc/rc3.d/S24dhcdbd
/etc/rc4.d/S24dhcdbd
/etc/rc5.d/S24dhcdbd
/etc/rc6.d/K16dhcdbd
root@2HewittRand-desktop:~#
I did not use Automatix because it doesn't work on this version. Not sure about other 3rd Party apts changing global stuff.
root@2HewittRand-desktop:~# sudo mv /etc/rc2.d/S12hal /etc/rc2.d/S13hal
mv: cannot stat `/etc/rc2.d/S12hal': No such file or directo...

root@2HewittRand-desktop:~# gdb dbus 2>&1 | tee gdb-dbus.txt
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
dbus: No such file or directory.
(gdb) handle SIG33 pass nostop noprint
Signal Stop Print Pass to program Description
SIG33 No No Yes Real-time event 33
(gdb) set pagination 0
(gdb) run
Starting program:
No executable file specified.
Use the "file" or "exec-file" command.
(gdb)

root@2HewittRand-desktop:~# pidof dbus
root@2HewittRand-desktop:~# pidof /etc/init.d/dbus
root@2HewittRand-desktop:~#

root@2HewittRand-desktop:~# strace -Ff -tt /etc/init.d/dbus 2>&1 | tee strace-dbus.log
05:10:08.270937 execve("/etc/init.d/dbus", ["/etc/init.d/dbus"], [/* 31 vars */]) = 0
05:10:08.273015 brk(0) = 0x805e000
05:10:08.273395 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
05:10:08.273742 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f6f000
05:10:08.274064 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
05:10:08.274369 open("/etc/ld.so.cache", O_RDONLY) = 3
05:10:08.274659 fstat64(3, {st_mode=S_IFREG|0644, st_size=64796, ...}) = 0
05:10:08.274999 mmap2(NULL, 64796, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f5f000
05:10:08.275277 close(3) = 0
05:10:08.314090 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
05:10:08.314547 open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
05:10:08.314856 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1"..., 512) = 512
05:10:08.315179 fstat64(3, {st_mode=S_IFREG|0755, st_size=1364388, ...}) = 0
05:10:08.315490 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f5e000
05:10:08.315857 mmap2(NULL, 1369712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e0f000
05:10:08.316154 mmap2(0xb7f58000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149) = 0xb7f58000
05:10:08.316493 mmap2(0xb7f5b000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f5b000
05:10:08.316824 close(3) = 0
05:10:08.317151 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e0e000
05:10:08.317448 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e0e6b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
05:10:08.318002 mprotect(0xb7f58000, 4096, PROT_READ) = 0
05:10:08.318375 munmap(0xb7f5f000, 64796) = 0
05:10:08.318749 getpid() = 8794
05:10:08.319027 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
05:10:08.319325 geteuid32() = 0
05:10:08.319941 brk(0) = 0x805e000
05:10:08.320248 brk(0x807f000) = 0x807f000
05:10:08.320558 getppid() = 8792
05:10:08.320867 stat64("/home/root", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
05:10:08.321207 stat64(".", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
05:10:08.321563 open("/etc/init.d/dbus", O_RDONLY) = 3
05:10:08.321868 fcntl64(3, F_DUPFD, 10) = 10
05:10:08.322125 close(3) = 0
05:10:08.322373 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
05:10:08.322636 rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
05:10:08.322907 rt_sigaction(SIGINT, {0x8055a20, ~[RTMIN RT_1], 0}, NULL, 8) = 0
05:10:08.330491 rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0
05:10:08.330849 rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
05:10:08.331114 rt_sigaction(SIGTERM, NULL, {SIG_DFL}, 8) = 0
05:10:08.331375 rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0
05:10:08.331669 read(10, "#! /bin/sh\n### BEGIN INIT INFO\n#"..., 8192) = 4312
05:10:08.332235 stat64("/usr/bin/dbus-daemon", {st_mode=S_IFREG|0755, st_size=273972,...

Added My Info

Today's updates fixed this for me.
thanks, you can close the bug as it relates to me.

We should forcefully remove all old RC symlinks and reinstall them at level 12 at this stage, to fix this once and for all.

This is fixed in the proposed 1.1.20 packages in my PPA. Hardy upload pending approval in bug 196568.

This bug was fixed in the package dbus - 1.1.20-1ubuntu1

---------------
dbus (1.1.20-1ubuntu1) hardy; urgency=low

  * New upstream release: Tons of bug fixes, a security fix (CVE-2008-0595),
    and two small new features:
    - inotify support (to replace previous dnotify implementation); can be
      disabled with configure switch if it causes trouble
    - Add matching support for program binaries in dbus policy rules.
  * Merge with Debian unstable; remaining changes:
    - debian/patches/81-session.conf-timeout.patch: Raise the service startup
      timeout from 25 to 60 seconds. It may be too short on the live CD with
      slow machines.
    - Add consolekit (>= 0.2.3-3ubuntu2) dependency, which provides
      pam_console compatible stamps in /var/run/console. This keeps
      "at_console" policies working until we get rid of them completely.
      (See policykit-integration spec)
    - debian/dbus.{postinst,prerm}: Do not restart dbus on upgrades, since it
      breaks too many applications. Instead, trigger a "reboot required"
      notification. Since this cancels the postinst early, add an explicit
      update-rc.d call to the symlink migration.
    - debian/rules: Do not install /etc/X11/Xsession.d/75dbus_dbus-launch, we
      do not need it for Gnome, KDE, and XFCE, and it causes trouble.
      (LP #62163)
    - debian/dbus.preinst: Remove obsolete conffile
      /etc/X11/Xsession.d/75dbus_dbus-launch on upgrades. This needs to be
      kept until after Hardy's release.
  * Debian's forceful way of RC symlink migration should finally fix all the
    previous upgrade issues with wrong priorities. (LP: #25931)

dbus (1.1.20-1) unstable; urgency=medium

  [ Loic Minier ]
  * Forcefully remove old init script symlinks on upgrades to this version to
    properly reinstall the init script when using insserv or file-rc; thanks
    Petter Reinholdtsen; closes: #466503.

  [ Michael Biebl ]
  * New upstream release.

dbus (1.1.4-1) unstable; urgency=low

  [ Loic Minier ]
  * Merge patch from Ubuntu to build a devhelp file; thanks Martin Pitt;
    closes: #454142.
    - Build-dep on xsltproc.
    - New patch, dbus-1.0.1-generate-xml-docs, enables generation of XML docs
      which serve as source for the devhelp generation.
    - Add a XSLT file from the Fedora package, debian/doxygen_to_devhelp.xsl.
    - Generate the devhelp file from the XML files thanks to the XSL file via
      xsltproc in build/dbus-1-doc::.
    - Install the devhelp index in dbus-1-doc and move the HTML documentation
      around; add a symlink from the gtk-doc dir.
  * Misc smallish whitespace cleanups.
  * Start dbus at runlevel priority 12 and stop at priority 88. This
    eliminates the race condition of starting the X session before hal is
    running. Migrate rc?.d symlinks from 20 to 12/88 on upgrades. This need
    to be kept until after lenny is released.
  * Set LSB Default-Stop section to 1 and only install a shutdown script for
    runlevel 1 to only stop dbus when going down to single user mode; dbus can
    simply be killed like everything else on shutdown or reboot by sendsigs;
    drop rc0 and rc6.d symlinks on upgrades.
  * Bump up dbus-x11 ...

Had the same problem on my eeepc with Gutsy. Wireless wouldn't work nor would my ethernet device be detected. I could do a quick 'sudo /etc/init.d/hal start' and it my networking would work fine including the wireless auto starting. I would also have to manually mount my external cdrom and HD, even after I started HAL.

After researching extensively on this site and others, I tried changing my CONCURRENCY=none in /etc/init.d/rc. Now, no error, and my wireless, wired and external cdrom and external HD mount and initialize without issue. Thanks fellas.

--
Decaffeinated coffee is kinda like kissing your sister.

Hi,

I'm getting the "Failed to initialize HAL" error message after upgrading to 8.04 alpha last week.

Running this in a VMware Workstation virtual machine for testing.

Happens on every boot.

Investigated a few options people mention on the forums, but nothing worked.

Then looking at the /etc/rc2.d directory I noticed hal wasn't even listed!

S12dbus -> ../init.d/dbus
S13gdm -> ../init.d/gdm

and no hal at all.

Did a:

$ sudo ln -s ../init.d/hal S15hal

And rebooted, and now everything seems to start up properly. The "CONCURRENCY" level in /etc/init.d/rc hasn't been touched, it was already at "none" when I checked.

Hope this helps.

I think this has to do with my cd rom. It has always been a bit of a problem in that it won't recognise burnt cd's when it is the first type of cd I open. If I try factory made cd's first then I can try a burnt cd.
But today I got the above error when I booted with the cd in the drive. I just closed the error box and i was able to do everything else except open and cd rom files. None of my usual tricks are working now.

Having failed to re-install Ubuntu 8.04 on my E2160 [A] rig, I then succeeded on my Northwood P4 [B] rig.
Re-trying with my [A] rig, it was happy to re-install Ubuntu 7.10 but once again wouldn't take 8.04 (now withx483 updates !)
After Updates application and a very slow, reluctant re-start it failed to display normal drive icons and displayed an 'Internal error' 'failed to initialise HAL !' message.
Not being a Linux expert I nevertheless tried Justin Clift's entry in Terminal, to no avail. I will now try again, substituting $15hal for S15hal
(Don't know what I'm doing but I know that the slightest typo screws up command line instructions.)

Sorry, should have made it clear that I'm talking about 8.04 Beta. The re-type didn't work either and needed a hard reset, System, Quit no longer working.
(Note that 'crash report detected', then slowly reported - Sorry, the program "gnome-keyring-daemon" closed unexpectedly, etc, but Report Problem enentually said - Could not upload report to crash database: <urlopen error (-5, 'No address associated with hostname')>

Whilst waiting for a revised, complex set of Updates or further 8.04 releases, I'll have to revert to 7.10, pity, it was getting there !

Ubuntu 8.04 pre-release - 11 April 2008

Having just successfully applied the latest series of Partial Updates to my 3.0GHz Northwood rig, tried with my E2160 rig, first with its second Vista drive connected and then disconnected unless that was the problem, but no joy, 'Internal error' 'failed to initialise HAL!' with crash report failing exactly as before.

Once again, restored image of Gutsy installation performing without problems.

Tomorrow, after my blood pressure has gone down, I'll try HardyBeta installation on an E4600 rig, similar to the E2160 rig. AS you will gather from the attached partial screen shot, some functionality is present, like the GIMP, but ICONS are only displaying Linux, not former NTFS nomenclatures, plus some of the error messages.
The screen is locked up, not responding to Quit, needing a hard reset.

(Picture acquired from a drive after GRUB re-start into Windows XP

Later on, I tried another re-install on my E2160 rig, which took two hours, consisted of 509 packages and included new kernel 2.6.24-16-generic, removed kernel 2.6.24-15-generic and left kernel 2.6.24-12-generic.
Normal re-start into kernel 2.6.24-16-generic after a very slow re-boot, produced Linux, non-NTFS drive icons and very slow response before locking up and needing a hard reset, so selected kernel 2.6.24-12-generic which seems to be working well.
It's been another long day, not good for my blood pressure. After a nights rest, I'll finish checking functionality and package interactions.

The same issue on kernel 2.6.24-16-generic. After the long-long boot process.
PS Lets postpone final release, I have never met so much bugs in ubuntu.

I'm having the same "Fail to initialize Hal" error in my Hardy 2.6.24-16.
I can boot up correctly with 2.6.22-14, but I lose my fglrx ogl libraries and my keryring daemon crashes (yet it still seems to work).
I've tried all the reconfiguring/reinitialize of hald and dbus, as well as messing with rc configs; still nothing.

After looking at some of my log files, the only error I can find in concern to HAL comes when pulseaudio is first initializing. I'm not sure if it's the cause, and I don't know how to stop it from starting to see if it's the cause.

Ripps818 [2008-04-16 0:52 -0000]:
> I'm having the same "Fail to initialize Hal" error in my Hardy 2.6.24-16.
> I can boot up correctly with 2.6.22-14

Can you please open a new bug about this, and do the steps in
https://wiki.ubuntu.com/DebuggingHal, and include the logs? Thank you!

Unfortuatanaly I've got the same problem in Hardy. I assume it happened after I update Ubuntu. When I boot into Hardy I got the message "Failed to initialize Hal" and my network doesn't work at all. Everything worked fine before. Is there a solution for this bug?

I fixed my Hal problem by disabling all modules for my Tv Tuner. I read in a another HAL bug report that the newest round of kernel release caused this problem to people with TV Tuner cards.
Modules I blacklisted:
cx88xx
cx8800
cx88_alsa

In Report #216159 I reported that that Kardy kernels -15 and -16 caused problems for my E2160 with its Zarlink MT352 DBV-T (Aver A777) PCI card identified as the likely cause, the card being happier with -12 and perfectly happy with 7.10's kernel.

Now, Release Candidate 8.04 won't even install or run a LiveCD session on my E2160/Zarlink rig, let alone raise a HAL initialization failure.

So, in view of Ripps818 comment, I will next try Release Candidate installation on my 3.0GHz Nothwood rig, with and without its USB2 DibCom tuner attached before trying it out on a 'work in progress' E4600 rig which has NO tuner module (yet) and then report back.

(But first I'll add a comment to Bug Report #217726.)

YES, for Ubuntu 8.04 Release Candidate, its kernel 2.6.24-16-generic lack of TV tuner drivers is causing HAL initialization failure or worse for my [A] rig E2160 with its AverTV A777 PCI card using a Zarlink MT352 DVB-T chip. There's also no driver for my [C] rig Northwood P4 AverTV A800 USB module and its DiBcom 3000MC/P chip, which only prevents Freeview reception but doesn't block installation.
Indeed, my [C] rig gets so far as to confirm the absence of a suitable driver when configuring Kaffeine.
Re-installing Ubuntu 7.10 on my [A] or [C] rigs confirms the presence of drivers in the slightly modified 2.6.22-14-generic kernel.

It will probably take another hard days work to further confirm with my 'work in progress' E4600 rig, but I'm convinced, so thank you, Ripps818

I got this error when trying to boot the livecd of the RC on my computer, and therefore have no internet and sound; a releasecritical bug.

Output from lspci:
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
02:00.0 VGA compatible controller: ATI Technologies Inc RV516 XT Radeon X1600 Series (Primary)
02:00.1 Display controller: ATI Technologies Inc RV516 XT Radeon X1600 Series (Secondary)
03:05.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 70)
03:08.0 Ethernet controller: Atheros Communications Inc. AR5413 802.11abg NIC (rev 01)
03:09.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
03:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
03:0a.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a)

Hi Åskar

And I thought that my rigs were complex !
Mind you, I think that you will find it easier to tackle other problems if
you can
disable or even temporarily remove your Philips SAA7133/SAA7135 device.
The lack of suitable chipset drivers in the Release Candidate kernel seems
to be
preventing installation or at least masking other problems.

Please follow Martin Pitt comment if you really want to tackle down the problem.
Without proper debug information, we can't really now why hal failed to start.

Sorry, but while you are gathering more detailed evidence,
I am simply by-passing the problem.

In my case it's the, only recently surfaced, connection Philips Tv-card. I read through this whole thread, noting down dif'rent fixes that didn't seem to make much sense, until I hit on the Philips-tv card thing. I have a ZOLID tv-card (from ALDI), wich has a Philips chip SAA 71-something. I removed it, rebooted and the bug was solved.
What 'bugs' me is this: the problem didn't exist in the latest beta, until I did an update some weeks ago. before that, everything was fine. So it can't have to do with the kernel version (or maybe in some strange indirect way). Anyway, I just installed the RC, hoping not to get that threaded 'failed to initialise hal' message, and was mighty disappointed. I was about to reinstall my Gutsy (wich doesn't mind my tv-card, not even after the latest updates) until I tried removing the card. Think I'll stick with Hardy (I like my stuff cutting the edgez), but for how long I can't tell; I want to use my tv-card eventually...
So, another day, another clue. If needed i'll post more details to my system, just ask. For now; hope this get fixed, loooove ubuntu still, eventhough it's as hard as real love in the real world sometimes...

Leeuw a écrit :
> In my case it's the, only recently surfaced, connection Philips Tv-card.
> I read through this whole thread, noting down dif'rent fixes that didn't seem to make much sense,

So these means that your bug is different than the original one.
This bug report is really old and was cause by something simple : hal
was started too late. It was fix a long time ago and it seams your bug
is different. So you really should follow martin comment :
open a new bug and please FOLLOW https://wiki.ubuntu.com/DebuggingHal
TO GET REAL DEBUG INFORMATION. Thanks.
And stop commenting on this fixed bug, you will not get the visibility
you deserve.

I've make a new bug report, related to the current issue:
https://bugs.launchpad.net/bugs/218528

On Wed, 2008-04-16 at 09:01 +0000, Martin Pitt wrote:
> Ripps818 [2008-04-16 0:52 -0000]:
> > I'm having the same "Fail to initialize Hal" error in my Hardy 2.6.24-16.
> > I can boot up correctly with 2.6.22-14
>
> Can you please open a new bug about this, and do the steps in
> https://wiki.ubuntu.com/DebuggingHal, and include the logs? Thank you!
>

No longer occurs with definitive, 24th April Release, but please see #221953.

Hi everybody,

upgraded from Gutsy to Hardy. If I set concurrency to "shell", I still get that error message. Reverting concurrency back to "none" is a workaround, but not a solution for me. I assume my symlinks are the Hardy default ones:

~$ ls -1 /etc/rc?.d/*dbus
/etc/rc1.d/K88dbus
/etc/rc2.d/S12dbus
/etc/rc3.d/S12dbus
/etc/rc4.d/S12dbus
/etc/rc5.d/S12dbus

So, contrary to Bruce's experience, the final Hardy release did not solve this problem.
FYI, I'm running 2.6.24-16-generic

Hi Daniel Rheinbay - in case it helps.

I didn't Upgrade but made a fresh, internet-connected Manual
method install to 'free space' which resulted in HAL initialization
failure. ReStarting in recovery mode I obtained an indication
that my Zarlink DVB-T chip used by my AverTV A777 was not
being recognised, making ALL other messages irrelevant and
revealing that the release version was lacking DVB-T drivers of
earlier releases. So, could you have another item that's not being
recognised ? Recovery mode could provide a clue.
As I am NOT a Linux expert, please ignore this if it doesn't apply.

Daniel,

indeed the priorities are wrong for you. It should be S24, not S12 (that's too early and races with dbus). So far the upgrade only forces the symlinks to be correct for upgrades from dapper, not from gutsy. Seems we have to do that for those upgrades as well.

Argh, that was solved for dbus already.

BTW, did you guys use automatix, or any other third-party "tune your system" application? I wonder how you ended up with those broken RC levels in the first place.

Uploaded, awaiting peer review in the queue now:

hal (0.5.11~rc2-1ubuntu8) hardy-proposed; urgency=low

  * debian/hal.postinst: If hal has any start rc symlinks, force them back to
    24. A lot of people end up with priority 12 for some reason, which races
    with dbus startup, especially with CONCURRENCY=shell. (LP: #25931)

 -- Martin Pitt <email address hidden> Mon, 28 Apr 2008 07:44:11 +0200

http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/revision/230

Hi,

Mine was (probably) unusual, in that I upgraded a (newly installed and patched) 6.06 installation straight to 8.04.

Did this because my father has a PC running 6.06, and he never receives the "newer distribution available" update notice when he runs the update manager.

To see what might be going on, 6.06 got installed from CD into a VMware virtual machine, and then latest updates applied. Yep, he's right, there's no notification of a newer Ubuntu version being available.

Instead, ran the command to check if there are any development versions that can be upgraded to, and it suggested 8.04 (pre release at the time).

As this was a virtual machine I thought "what the heck" and let it proceed. Everything seemed ok afterwards except for the HAL initialisation failure error, that turned out to be because it wasn't in the rc levels after the upgrade.

Hope that helps. :)

Martin,

your fix appears to do the job. Though I didn't actually build a new package, I just ran
update-rc.d -f hal remove
update-rc.d hal start 24 2 3 4 5 . stop 16 1 .
which resulted in hal's priorities being deferred to S24. Everything's running smooth now.
Looking at hal's postinst script, I'm wondering why we don't invoke update-rc.d regardless of the hal version? Just to be on the safe side...
Glad we got this one squashed though :)

And, just for the records:
@Martin: Nope, haven't used Automatix.
@Bruce: Thanks for your comment, but my Inspiron 6400n (aka e1505) came pre-installed with Ubuntu, all of its components are supported by Ubuntu and I don't have any peripheral devices attached to it.

Hi Daniel,

Daniel Rheinbay [2008-04-28 17:48 -0000]:
> Looking at hal's postinst script, I'm wondering why we don't invoke
> update-rc.d regardless of the hal version? Just to be on the safe
> side...

Because forcibly removing and reinstalling the symlinks is already a
gross violation of Policy. We just clobber an administrator's
configuration without asking. So it should always be a last resort,
and not be done with every upgrade.

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

SRU ack for the fix from <http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/revision/230>.

Fixed in trunk, will upload to intrepid once the archive is open.

Accepted into hardy-proposed. Please test the packages from the archive and give feedback here. Thank you!

After upgrading from gutsy to hardy I experienced this problem of hald not starting and avahi-daemon also not starting. I redid the symlinks for hal (12->24) and gdm (13->30) but that didn't cure the problem.

Starting hald manually indicated that it was failing while trying to open /usr/local/var/run/dbus/system_bus_socket. In desperation I symlinked /usr/local/var/run/dbus/system_bus_socket to /var/run/dbus/system_bus_socket. That seemed to cure my problem. I don't know why /usr/local/var/run/dbus/system_bus_socket is needed.

hi finlay,

finlay [2008-04-30 11:59 -0000]:
> Starting hald manually indicated that it was failing while trying to
> open /usr/local/var/run/dbus/system_bus_socket.

Ugh, how weird. That's an entirely different issue then, can you
please file a new bug with the hal log? Thank you!

Martin,

just tested the new version in hardy-proposed. Works like a charme. Good job!

Thanks,
Daniel

I recreated the problem using hal package version 0.5.11~rc2-1ubuntu7 from Hardy. I then installed package version 0.5.11~rc2-1ubuntu8 from hardy-proposed and the symlinks were set properly.

I did not use the CONCURRENCY=shell option as it wasn't clear to from the test case what to look for.

I'm experiencing the same problem.
I tried many workaround but none seemed to work.
Here are my rc2.d links:
[...]
S12dbus -> ../init.d/dbus
[...]
S13hal -> ../init.d/hal
[...]
S30gdm -> ../init.d/gdm
[...]

I tried to reinstall hal, using
#sudo aptitude reinstall hal
but it not worked because hald cannot find the required file: /var/run/dbus/system_bus_socket indeed the directory is EMPTY!!!
Any suggestion about how to solve this annoying problem?

I just noticed that /var/run/dbus/system_bus_socket was hidden.
By the way it cannot be found by the hal.

Ok, I resolved the problem.

I would like to inform that the users whose are having the problem with:
log_daemon_msg : Not found

can try this workaround:
$ sudo mv init-functions.old init-functions

I tried to search the word: log_daemon inside init-functions but there was no match.
Then I found it in the .old, so I renamed .old to init-functions and rebooted with:
$ sudo reboot

Now everything works fine.

Copied to hardy-updates.

This bug was fixed in the package hal - 0.5.11~rc2-1ubuntu9

---------------
hal (0.5.11~rc2-1ubuntu9) intrepid; urgency=low

  * Add 03_increase_helper_timeout.patch: Increase helper timeout from 10 to
    20 seconds. Some CD-ROMs are too slow to do all the detection in 10
    seconds. (LP: #218834)

hal (0.5.11~rc2-1ubuntu8) hardy-proposed; urgency=low

  * debian/hal.postinst: If hal has any start rc symlinks, force them back to
    24. A lot of people end up with priority 12 for some reason, which races
    with dbus startup, especially with CONCURRENCY=shell. (LP: #25931)
  * Add 00upstream-fix-macbook-backlight.patch: Fix backlight control on
    MacBooks. Thanks to godlygeek! (LP: #206921)

 -- Martin Pitt <email address hidden> Wed, 30 Apr 2008 11:00:07 +0200

I just ran into this problem after updating to hal 0.5.11~rc2-1ubuntu8 (which was supposed to fix this bug for some people if I got the discussion right) on my Samung R20 running Hardy. Neither the subsequent update to 0.5.11~rc2-1ubuntu8.1 nor the downgrade to 0.5.11~rc2-1ubuntu7 did help. After logging in with gdm I get the infamous "Failed to initialize HAL" message. Wifi isn't working at first but comes up after about 30 seconds.

$ ls -l /etc/rc*/*dbus*
/etc/rc1.d/K88dbus -> ../init.d/dbus
/etc/rc2.d/S12dbus -> ../init.d/dbus
/etc/rc3.d/S12dbus -> ../init.d/dbus
/etc/rc4.d/S12dbus -> ../init.d/dbus
/etc/rc5.d/S12dbus -> ../init.d/dbus
$ ls -l /etc/rc*/*hal
/etc/rc1.d/K16hal -> ../init.d/hal
/etc/rc2.d/S24hal -> ../init.d/hal
/etc/rc3.d/S24hal -> ../init.d/hal
/etc/rc4.d/S24hal -> ../init.d/hal
/etc/rc5.d/S24hal -> ../init.d/hal
$ ls -l /etc/rc*/*gdm*
/etc/rc0.d/K01gdm -> ../init.d/gdm
/etc/rc1.d/K01gdm -> ../init.d/gdm
/etc/rc2.d/S13gdm -> ../init.d/gdm
/etc/rc3.d/S13gdm -> ../init.d/gdm
/etc/rc4.d/S13gdm -> ../init.d/gdm
/etc/rc5.d/S13gdm -> ../init.d/gdm
/etc/rc6.d/K01gdm -> ../init.d/gdm

changing the priority of hal in rc2.d from 24 to 13 seems to fix the problem for me.

by the way, my upgrade history is feisty -> gutsy -> hardy.

Hi Thomas,

your rc* symlinks are correct, so hal fails for some other reason on
your system. Your hal.log looks good, it doesn't seem to have crashed
(I guess you used Control-C to stop it). Can you please file a new bug
about this? I guess we have to debug that differently. Thanks!

Ah, sorry. You still have gdm on level 13, but it shuold be at 30. I guess you did not change that manually, so it is an upgrade bug from Feisty. Can you please create a new bug report against gdm for that? Thank you!

BTW, if you just wait a bit on the gdm prompt, it should work fine.

Thanks! I've changed the level of gdm to 30 and everything's fine now. I've created a new bug report against gdm which can be found at https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/227838

I also get the "failed to initilize hal" error, but ONLY if autologin is enabled. I guess it logs in too quickly because of an incorrect priority list?

rc0.d/K01gdm rc2.d/S13gdm rc4.d/S13gdm rc6.d/K01gdm
rc1.d/K01gdm rc3.d/S13gdm rc5.d/S13gdm

rc1.d/K88dbus rc2.d/S12dbus rc3.d/S12dbus rc4.d/S12dbus rc5.d/S12dbus

rc1.d/K16hal rc2.d/S24hal rc3.d/S24hal rc4.d/S24hal rc5.d/S24hal

rc0.d/K16dhcdbd rc2.d/S24dhcdbd rc4.d/S24dhcdbd rc6.d/K16dhcdbd
rc1.d/K16dhcdbd rc3.d/S24dhcdbd rc5.d/S24dhcdbd

This is a Thinkpad X40, running Hardy, which was upgraded from Fiesty.

As Martin said above, Aleksander, your GDM is starting too early. It's S13 -- it should be S30.

I had the similar problem. The problem appeared after I had upgraded from Ubuntu 7.10 to Ubuntu 8.04 (64bit, Intel Core-Duo) via the update manager. The system worked more or less fine for a couple of weeks. One of the glitches was that it took a 10-20 seconds after login to recognize the network connection.

The problem became serious after I ha inserted a data DVD in the DVD drive. The DVD drive on my machine (Dell Optiplex 745) never worked correctly under Ubuntu 7.10. I had to change the BIOS setting at every fresh bootup of Ubuntu to be able to open it and insert a CD/DVD. This is probably an issue of Dell, not of Ubuntu. However, after having inserted the data DVD, it first displayed the contents. At a 2nd trial, it refused to display anything. Only the DVD was spinning for a few seconds. That was the point of time after which I could not boot without the message 'Failed to initialize HAL'. The problems spread over the days to other functions such as access to USB memory sticks. Later, I was no longer able to shutdown (system froze after pressing the power-off icon on the upper right corner of the Gnome display). Fiinally, I was no able to start Gnome (gdm). Only the recovery mode saved me from loosing the PC.

The problem vanished after executing

   sudo mv /etc/rc.d/13gdm /etc/rc.d/30gdm

as advised above.

Manfred, Christian, Aleksander, as I already wrote, this is bug 227838, and it is in progress.

I don't know if this is a different bug, but I have searched high and low and cannot find a similar bug. This one is the closest to the problems I am having. I have Hardy 64bit (haven't tested 32bit) with a Gateway MX6433 (There are many other similar laptops from Gateway 6000 series) which has a Turion64 single core cpu and and I upgraded to Hardy from Gutsy. I use the -rt kernel for multimedia editing.
I tried to fix the problem using the notes above, but I run in KDE and kdm, not Gnome and my rc2.d links are all correct as noted above. Nothing changes it.
Here is the problem and here is the dmesg log section that identifies what happened:
[ 4233.202422] dbus-daemon[5257]: segfault at 7fe705dd18e0 rip 7fe704eedae2 rsp 7fff0daa4778 error 4
I will attach a full log.

I have no idea what error 4 is, but this seems to happen randomly whether I am at my machine or not. When dbus fails networkmanger and the battery monitor fail to report properly in KDE and it says that network manager is not running and the battery is not present. It is this second notification that alerts me when dbus crashes since network manager doesn't tell me it isn't running unless I go to use it. This doesn't seem to interrupt my use of the internet or local LAN however so it isn't a total show stopper, but it does prevent me from using my DVD writer (which also doesn't burn properly since Hardy either). DBus worked fine in Gutsy so this is definitely a regression of some kind or maybe a conflict with the new ATI drivers. I haven't had a chance to check this.

hi,
DaFlame [2008-05-22 17:53 -0000]:

> I don't know if this is a different bug

It is. Can you please open a separate report? This issue is already
closed.

> [ 4233.202422] dbus-daemon[5257]: segfault at 7fe705dd18e0 rip 7fe704eedae2 rsp 7fff0daa4778 error 4

Eww. Maybe you can enable the crash reporter again by setting
"enabled=1" in /etc/default/apport and have apport file the crash bug?
Thanks!

Thank you. I will do just that. It may also give me insight to it as well.

I confirm : on Hardy (8.04) I found /etc/rc2.d/S50dbus - after renaming to S12dbus (ie. must be less than gdm, pulseaudio and avahi), the system starts normally. Prior to that, there used to be a message after login 'Internal error : failed to initialize HAL' and NM and other things were not working. My system is https://wiki.ubuntu.com/LaptopTestingTeam/AcerAspire3023, with all recent updates.

Ran into this bug when doing a dist-upgrade from Edgy to Hardy (yes. directly!). Since I'm using KDE, I've moved /etc/rc[1-5].d/S13kdm to "S30kdm" and then rebooted my system - It's running fine now.
Maybe the S13 >> S30 wasn't even necessary...

I experienced this behaviour today (2009-01-19) on Ubuntu 8.10:

everything worked for me after the dist-upgrade some time ago.

But, today I accidentally disabled the 'dbus' service within the services-admin tool. The X server was restarted automatically and I was not able to login anymore. The cursor was blinking but no mouse or keyboard was usable. Switching to a shell by Alt+F6 was possible. Here I manaully started the dbus service and I could login again.

So, I opened the services-admin tool to re-enable the dbus service, rebooted the machine...and was not able to login. Same thing as before. I tried re-installing dbus, hal, system-tools-backends...no results.

I was able to fix the problem by changing the priority of the rc2.d/dbus script:

after disabling dbus in GUI:

user@host:/etc$ ls -l /etc/rc*/*dbus*
lrwxrwxrwx 1 root root 14 2008-04-28 18:11 /etc/rc1.d/K88dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2009-01-19 22:38 /etc/rc2.d/S50dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-28 18:11 /etc/rc3.d/S12dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-28 18:11 /etc/rc4.d/S12dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-28 18:11 /etc/rc5.d/S12dbus -> ../init.d/dbus
user@host:/etc$ ls -l /etc/rc*/*hal*
lrwxrwxrwx 1 root root 14 2008-04-28 18:11 /etc/rc0.d/S90halt -> ../init.d/halt
lrwxrwxrwx 1 root root 13 2008-05-09 17:36 /etc/rc1.d/K16hal -> ../init.d/hal
lrwxrwxrwx 1 root root 13 2008-05-09 17:36 /etc/rc2.d/S24hal -> ../init.d/hal
lrwxrwxrwx 1 root root 13 2008-05-09 17:36 /etc/rc3.d/S24hal -> ../init.d/hal
lrwxrwxrwx 1 root root 13 2008-05-09 17:36 /etc/rc4.d/S24hal -> ../init.d/hal
lrwxrwxrwx 1 root root 13 2008-05-09 17:36 /etc/rc5.d/S24hal -> ../init.d/hal
user@host:/etc$ ls -l /etc/rc*/*gdm*
lrwxrwxrwx 1 root root 13 2008-04-28 18:11 /etc/rc0.d/K01gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2008-04-28 18:11 /etc/rc1.d/K01gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2008-04-28 18:11 /etc/rc2.d/S30gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2008-04-28 18:11 /etc/rc3.d/S30gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2008-04-28 18:11 /etc/rc4.d/S30gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2008-04-28 18:11 /etc/rc5.d/S30gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2008-04-28 18:11 /etc/rc6.d/K01gdm -> ../init.d/gdm

Fix:
user@host:/etc$ sudo mv /etc/rc2.d/S50dbus /etc/rc2.d/S12dbus
user@host:/etc$ ls -l /etc/rc*/*dbus*
lrwxrwxrwx 1 root root 14 2008-04-28 18:11 /etc/rc1.d/K88dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2009-01-19 22:38 /etc/rc2.d/S12dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-28 18:11 /etc/rc3.d/S12dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-28 18:11 /etc/rc4.d/S12dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-28 18:11 /etc/rc5.d/S12dbus -> ../init.d/dbus

Finally everything is working again - but somewhere weird things happen.

The issue persists for me on Ubuntu 8.04. It occurs about %50 of the time after every reboot.

Forgot to mention:

jacob@jacob-laptop:/etc$ ls -l /etc/rc?.d/*dbus*
lrwxrwxrwx 1 root root 14 2008-04-29 03:54 /etc/rc1.d/K88dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-29 03:54 /etc/rc2.d/S12dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-29 03:54 /etc/rc3.d/S12dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-29 03:54 /etc/rc4.d/S12dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 14 2008-04-29 03:54 /etc/rc5.d/S12dbus -> ../init.d/dbus
jacob@jacob-laptop:/etc$ ls -l /etc/rc?.d/*hal*
lrwxrwxrwx 1 root root 14 2007-01-04 13:08 /etc/rc0.d/S90halt -> ../init.d/halt
lrwxrwxrwx 1 root root 13 2008-05-09 05:05 /etc/rc1.d/K16hal -> ../init.d/hal
lrwxrwxrwx 1 root root 13 2008-05-09 05:05 /etc/rc2.d/S24hal -> ../init.d/hal
lrwxrwxrwx 1 root root 13 2008-05-09 05:05 /etc/rc3.d/S24hal -> ../init.d/hal
lrwxrwxrwx 1 root root 13 2008-05-09 05:05 /etc/rc4.d/S24hal -> ../init.d/hal
lrwxrwxrwx 1 root root 13 2008-05-09 05:05 /etc/rc5.d/S24hal -> ../init.d/hal
jacob@jacob-laptop:/etc$ ls -l /etc/rc?.d/*gdm*
lrwxrwxrwx 1 root root 13 2007-06-04 17:03 /etc/rc0.d/K01gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2007-06-04 17:03 /etc/rc1.d/K01gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2007-06-04 17:03 /etc/rc2.d/S13gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2007-06-04 17:03 /etc/rc3.d/S13gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2007-06-04 17:03 /etc/rc4.d/S13gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2007-06-04 17:03 /etc/rc5.d/S13gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 13 2007-06-04 17:03 /etc/rc6.d/K01gdm -> ../init.d/gdm

It seems like this is my issue, as mentioned above:

https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/227838