starting hal causes kernel oops in sysfs_get_target_path()

[Daniel Silverstone]

Starting hal produces a kernel oops as shown in

  http://librarian.launchpad.net/3851218/dbus.log

and hal fails to start.

[Bruce Cowan (bruce89-deactivatedaccount)]

This happens to me as well. Terminal output:
<gtk.Menu object (GtkMenu) at 0x2aaaac5bb730>

[Mlt (mlt)]

When starting gnome the following comment comes up:

Internal error

failed to initialize HAL!

None of the USB functions work or, funnily enough does update-notifier. Trying to debug using wiki instructions for removable drives the following happens:

michael@ubuntu:~$ update-notifier
update-notifier: hal_initialize failed: (null)
: Resource temporarily unavailable
** (update-notifier:7881): DEBUG: tray_icons_init
michael@ubuntu:~$ killall gnome-volume-manager
gnome-volume-manager: no process killed
michael@ubuntu:~$ gnome-volume-manager -n 2>&1 | tee gvm.log

** (gnome-volume-manager:8147): WARNING **: manager.c/3016: hal_initialize failed: (null)
michael@ubuntu:~$
michael@ubuntu:~$ lshal > lshal.txt
error: libhal_ctx_init: (null): (null)
Could not initialise connection to hald.
 Normally this mean the HAL daemon (hald) is not running or not ready.

This is on an dist-upgrade from a fully functioning breezy installation. It was current as of the time & date of this comment.

[Miguel Martinez (el-quark)]

This also happens to me.

Normal user terminal output is:

$ hal-device-manager
<gtk.Menu object (GtkMenu) at 0x76a0502c>

While, if I run this using sudo, I get the following terminal output:

$ gksudo hal-device-manager
(hal-device-manager:4929): GnomeUI-WARNING **: While connecting to session manager:
Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.
<gtk.Menu object (GtkMenu) at 0x76a2e07c>

This is a dist-upgraded breezy install. And to make sure it wasn't a faulty install, I forced reinstall of several hal packages via synaptic.

[Daniel Silverstone (dsilvers)]

The last time I tried, it actually started after about 30 seconds or so.

It seems to use no cpu during that period though. Is this a timeout of some kind?

[Martin Pitt (pitti)]

Filed bug upstream.

AFAIK this is a deadlock between dbus and hal-device-manager waiting on each other until the request times out.

[Martin Pitt (pitti)]

problem in the dbus python bindings

[Martin Pitt (pitti)]

hal

[Neil Woolford (neil-neilwoolford)]

Also found here on Dapper flight three, updated to 1-Mar 18:00.

Following output from trying to start hal manually. Appears to bear out problem with python bindings, but I have *no* expertise here...

=====

neil@ubuntudapper3:~$ gksudo hal-device-manager
(hal-device-manager:4484): GnomeUI-WARNING **: While connecting to session manag er:
Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.
<gtk.Menu object (GtkMenu) at 0x76ccbe64>
Traceback (most recent call last):
  File "/usr/bin/hal-device-manager", line 20, in ?
    DeviceManager()
  File "/usr/share/hal/device-manager/DeviceManager.py", line 72, in __init__
    lambda *args: self.gdl_changed("DeviceAdded", *args))
  File "/usr/lib/python2.4/site-packages/dbus/_dbus.py", line 283, in connect_to _signal
    self._obj.connect_to_signal(signal_name, handler_function, dbus_interface, * *keywords)
  File "/usr/lib/python2.4/site-packages/dbus/proxies.py", line 128, in connect_ to_signal
    path=self._object_path,
  File "/usr/lib/python2.4/site-packages/dbus/_dbus.py", line 177, in add_signal _receiver
    named_service = bus_object.GetNameOwner(named_service, dbus_interface='org.f reedesktop.DBus')
  File "/usr/lib/python2.4/site-packages/dbus/proxies.py", line 79, in __call__
    reply_message = self._connection.send_with_reply_and_block(message, timeout)
  File "dbus_bindings.pyx", line 458, in dbus_bindings.Connection.send_with_repl y_and_block
dbus_bindings.DBusException: Could not get owner of name 'org.freedesktop.Hal': no such name

neil@ubuntudapper3:~$

=======
Neil

[Martin Pitt (pitti)]

 dbus (0.60-6ubuntu4) dapper; urgency=low
 .
   * Add debian/patches/dbus-poll-hang.patch:
     - Check to see if our data has already been read off the connection by
       another blocking pending call before we block in poll.
       (check_for_reply_and_update_dispatch_unlocked): Code taken from
       _dbus_connection_block_pending_call - checks for an already read reply and
       updates the dispatch if there is one.
     - This fixes e. g. the long startup hang of hal-device-manager.
       (Malone #31517)
     - Patch taken from upstream CVS.

[Martin Pitt (pitti)]

http://webcvs.freedesktop.org/dbus/dbus/dbus/dbus-connection.c?r1=1.115&r2=1.116&makepatch=1&diff_format=u

[Neil Woolford (neil-neilwoolford)]

Upgraded system at 11am 3rd March, after seeing above two messages from Martin Pitt.

Works here!

No Hal error on Gnome startup any more, and invoking System->Administration->Device Manager now works (albeit with a ten to fifteen second 'pause for thought' between the Device Manager appearing and actually populating with information).

Neil

[algogr (dim-par)]

Can you please give me a link on how to do this? I will appreciate.Thanks

[Martin Pitt (pitti)]

@algogr: do what? You should just upgrade your Dapper system (in particular, dbus packages), and it should be all well.

[Wes24 (wesleynuyens)]

Mmm, I upgraded Dapper and still get the error message. Update-notifier doesn't work either. I get the following error message when trying to start hal-device-manager:

wesley@wesley:~$ sudo hal-device-manager
Password:
<gtk.Menu object (GtkMenu) at 0xb6ac70a4>
Traceback (most recent call last):
  File "/usr/bin/hal-device-manager", line 20, in ?
    DeviceManager()
  File "/usr/share/hal/device-manager/DeviceManager.py", line 72, in __init__
    lambda *args: self.gdl_changed("DeviceAdded", *args))
  File "/usr/lib/python2.4/site-packages/dbus/_dbus.py", line 283, in connect_to _signal
    self._obj.connect_to_signal(signal_name, handler_function, dbus_interface, * *keywords)
  File "/usr/lib/python2.4/site-packages/dbus/proxies.py", line 128, in connect_ to_signal
    path=self._object_path,
  File "/usr/lib/python2.4/site-packages/dbus/_dbus.py", line 177, in add_signal _receiver
    named_service = bus_object.GetNameOwner(named_service, dbus_interface='org.f reedesktop.DBus')
  File "/usr/lib/python2.4/site-packages/dbus/proxies.py", line 79, in __call__
    reply_message = self._connection.send_with_reply_and_block(message, timeout)
  File "dbus_bindings.pyx", line 458, in dbus_bindings.Connection.send_with_repl y_and_block
dbus_bindings.DBusException: Could not get owner of name 'org.freedesktop.Hal': no such name
wesley@wesley:~$

[Martin Pitt (pitti)]

hm, is hal running for you at all? Does 'lshal' work? If not, does it work after

  sudo /etc/init.d/dbus restart

? Can you please copy the output of that command here?

[kidr (kidrdbz)]

I too am having the problem of "Internal error Failed to Initialize HAL!" dialogue popping up each time I boot my comp.

I typed 'lshal' and got:

lshal version 0.5.3
error: libhal_ctx_init: (null): (null)

and when I used:

"sudo /etc/init.d/dbus restart"

I got:

 * Stopping Hardware abstraction layer: /etc/dbus-1/event.d/20hal: line 49: kill: (6367) - No such process
                                                                         [ ok ]
 * Stopping system message bus... [ ok ]
 * Starting system message bus... [ ok ]
 * Starting Hardware abstraction layer: run-parts: /etc/dbus-1/event.d/20hal exited with return code 1

[vladanian (vladanian)]

I get "run-parts: /etc/dbus-1/event.d/20hal exited with return code 1" as well. It's two days before dapper's final, and hal isn't working for me...

[vladanian (vladanian)]

What just solved the problem for me was deleting the haldaemon user and then re-installing hal, which recreated it. Hal worked fine after that.

[Doomhammer (doomhammer-olivejar)]

I'm still getting the same errors / problems other have mentioned, and I'm running the latest version of Dapper (fresh install, just installed it yesterday).

It hangs at boot after:
Starting Hardware abstraction layer hald... [ ok ]

Then says:
Internal error Failed to Initialize HAL!

After bootup "lshal" doesn't work, it says that HAL isn't running, but does work after I run:
sudo /etc/init.d/dbus restart

Re-installing HAL isn't really a good solution, as uninstalling it will also remove ubuntu-desktop, and a few other (somewhat) crucial packages...

Here are some of the versions of the software I'm running, they might prove useful:
hal 0.5.7-1ubuntu18
hal-device-manager 0.5.7-1ubuntu18
dbus 0.60-6ubuntu8
dbus-1-utils 0.60-6ubuntu8

[kidr (kidrdbz)]

Well, I no longer get the errors, though the solution doesn't satisfy me.

The errors went away after I removed my firewire pci card from my computer. Now everything else works except the sound, which I had assumed was caused by the same hal problem, but apparently I was mistaken.

On the firewire card it says "Radius inc. firewire pci 2330", but in the computer it would show up as Texas Instruments LYNX Compatible 1394 something or other...

Just to make sure it was the firewire card I put the card back into the computer and the errors came back again. This makes me sad, as I had hoped to use my external DVD burner with ubuntu.

[jens_acamedia (commercial-acamedia)]

i upgraded to final dapper yesterday from flight 5...

everything was fine at first but when i installed fuse and began keeping my $HOME encrypted with encfs same problem as above occurred.

now i can not start hal nor dbus

jens@bigboy:~$ sudo /etc/init.d/dbus restart
Password:
 * Stopping NetworkManager dispatcher [ ok ]
 * Stopping Avahi Unicast DNS Configuration Daemon: avahi-dnsconfd [ ok ]
 * Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon [ ok ]
 * Stopping NetworkManager daemon [ ok ]
 * Stopping DHCP client manager... [ ok ]
 * Stopping Hardware abstraction layer hald [ ok ]
 * Stopping system message bus dbus [ ok ]
 * Starting system message bus dbus Unknown username "haldaemon" in message bus configuration file
                                                                         [ ok ]
 * Starting Hardware abstraction layer hald run-parts: /etc/dbus-1/event.d/20hal exited with return code 1
 * Starting DHCP client manager... [ ok ]
 * Starting NetworkManager daemon [ ok ]
 * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon [ ok ]
 * Starting Avahi Unicast DNS Configuration Daemon: avahi-dnsconfd [ ok ]
 * Starting NetworkManager dispatcher

[jens_acamedia (commercial-acamedia)]

ok - problem solved...

it was a problem with users...

i had a user called hal but none called haldaemon...

deleting the user hal and forcing a re-install of hal solved it - the user haldaemon was automatically created...

seems like something which could easily be fixed...

[Kaspars Krampis (kaspars-krampis)]

Yes, same here, deleting user 'hal' and reinstalling hal created new user called 'haldeamon' and now it seems to be working ok!

[Slight Slightly (slight--deactivatedaccount)]

It seems that people shouldn't have to be manually creating and deleting user accounts to get HAL working. I also have this problem and I'm happy enough to fix it manually, but really the symptoms here should be fixed as well as the original problem.

It takes about 10 minutes for my Dapper box to boot and once it does I get no auto-mounting of USB and whatnot.

Some debug:

tolan@thome:~$ lshal
error: libhal_ctx_init: (null): (null)
Could not initialise connection to hald.
 Normally this mean the HAL daemon (hald) is not running or not ready.

tolan@thome:~$ sudo /etc/init.d/dbus restart
Password:
 * Stopping Hardware abstraction layer hald [ ok ]
 * Stopping system message bus dbus [ ok ]
 * Starting system message bus dbus [ ok ]
 * Starting Hardware abstraction layer hald

[ **Hangs here for ages** ]

run-parts: /etc/dbus-1/event.d/20hal exited with return code 2

It really strikes me that as a fix has been released for this but people are still having the problem that it's not fixed, so I'm going to be cheeky and re-open it, sorry..

[Slight Slightly (slight--deactivatedaccount)]

I've re-opened this bug as people are still having the same symptoms. I'm presuming I'm *allowed* to re-open the bug as launchpad is letting me.. Sorry if I've misunderstood.

[Slight Slightly (slight--deactivatedaccount)]

Wrong status :/

Incidentally the user fix (delete 'hal' user and re-install didn't work for me)

[Svein Harald Soleim (sveinh)]

Same goes for me. I have a Asus A8N-E motherboard and run the 32 bit Kubuntu. Installed Dapper from scratch.

[Svein Harald Soleim (sveinh)]

hm. got something from dbus when I did a sudo /etc/init.d/dbus restart

[Chris Thompson (cthompsonx)]

I too get the "error failed to initialize HAL" when starting up Gnome.

When I change to KDE at startup, is "seems" to start normally, but if I try to use Konqueror to browse files, - i.e. by clicking on a folder - Konqueror hangs.

Also, if I recall corrrectly, when I clicked on the KDE main menu, system complained that "system processes terminated prematurely" or something to that effect...

[Chris Thompson (cthompsonx)]

I should add that I am using the most current version of the kernel - 2.6.15-26-386

[Chris Thompson (cthompsonx)]

I deeply, deeply regret to say that I was completely unable to find any workaround for this problem, other than to install open suse 10.1, which worked with the hardware flawlessly. Could I suggest that we raise the priority of this problem to High, as it completely precludes one from running Ubuntu with Gnomeh. Note that I have since installed 2 new systems with open suse, because I can't afford to play around with unstable systems that unexpectedly announce that they refuse to run Gnome.

[Svein Harald Soleim (sveinh)]

>Could I suggest that we raise the priority of this problem to High.

Indeed, if anyone botherd to read my error log, they would see that the restart of dbus produses a kernel oops, and that is more a critical error then medium.

[17602012.392000] Unable to handle kernel paging request at virtual address f800738f
[17602012.392000] printing eip:
[17602012.392000] c01bc870
[17602012.392000] *pde = 00000000
[17602012.392000] Oops: 0000 [#14]

I get this from two different mainboards, both amd64 but one with nforce3 and the other nforce4.

I have testet on 4 other 32bit computers and none of them have this problem.

[wilbur.harvey (wnh200405)]

I loaded Ubuntu 6.06LTS on my Medion MD95800
I am getting the same basic dbus/hal error.
It seems to have something to do with network manager or maybe a dhcpd permission.

[Slight Slightly (slight--deactivatedaccount)]

I've finally found what was kicking this off, though I think it's more a symptom than a cause.

I had SMB shares auto-mounting. Removing them from fstab fixed the problem, lshal now gives output and update-notifier now works.

From the variety of fixes that have worked for people it looks to me like something in the start-scripts for hal is being brittle...

[Hugh (derham)]

I've had the same problem on 2 machines after upgrading from breezy. A fresh install on an AMD Athlon 1700 went ok and seems to be running well with 2.6.16-26-k7, but the fresh install of Dapper on the laptop - Intel Sonoma, running a 386 kernel still gets the dbus or HAL error messages, and won't recognise USB drives.
If I resart dbus, avahi-daemon, hald and dbus shut down ok, then dbus, hald restart, but avahi-daemon takes ages in its attempt to restart, and eventually times out, and I've lost my desktop, both Gnome, AND xfce4.
I can't find a user hal or haldaemon in the usual newbie user utility. Where do I look for such users on a console?

[Martin Pitt (pitti)]

Hugh: Can you please copy&paste the output of

  id hal
  id haldaemon

here? Also, can you please attach /etc/fstab?

[Martin Pitt (pitti)]

(for the record, the linked upstream bug report is *entirely* unrelated to these last problems)

[Hugh (derham)]

Thanks Martin, here is the output:-

[Martin Pitt (pitti)]

Hugh, ok, so nothing unusual in your logs. This bug became horribly complicated since all sorts of different bugs got amalgated into this one, so let's clear up a bit.

This thread begun with hal-device-manager not starting, which was fixes ages ago.

The hang due to having samba shares is already known as bug 44874. Folks who have this problem, please have a look at that bug.

If anyone still has the problem of a non-existing 'haldaemon' user (check that 'id haldaemon' prints an error), please file a new bug. It works well when upgrading breezy to dapper, or installing dapper from scratch here.

So let's devote this bug to the kernel oops produced by starting dbus, as shown in
https://launchpad.net/distros/ubuntu/+source/dbus/+bug/31517/comments/33Hugh, ok, so nothing unusual in your logs. This bug became horribly complicated since all sorts of different bugs got amalgated into this one, so let's clear up a bit.

This thread begun with hal-device-manager not starting, which was fixes ages ago.

The hang due to having samba shares is already known as bug 44874. Folks who have this problem, please have a look at that bug.

If anyone still has the problem of a non-existing 'haldaemon' user (check that 'id haldaemon' prints an error), please file a new bug. It works well when upgrading breezy to dapper, or installing dapper from scratch here.

So let's devote this bug to the kernel oops produced by starting dbus, as shown in http://librarian.launchpad.net/3851218/dbus.log

Kernel gurus, can you make some head and tail of the oops trace?

[Martin Pitt (pitti)]

Whoops, sorry for the copy&paste problem in the previous comment.

[Ben Collins (ben-collins)]

Is it possible to find out which file in sysfs it is accessing when this occurs?

[Launchpad Janitor (janitor)]

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this linux-source-2.6.15 kernel bug to the new "linux" package. We appreciate your patience and understanding as we make this transition. Also, if you would be interested in testing the upcoming Intrepid Ibex 8.10 release, it is available at http://www.ubuntu.com/testing . Please let us know your results. Thanks!

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Leann Ogasawara (leannogasawara)]

This bug was reported a while ago and the last real comment made over 2 years ago. Please confirm if this is still an issue with the most recent Intrepid Ibex 8.10 release. Setting to Incomplete until we get further feedback. Thanks.

[Javier Jardón (jjardon)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!