Hald won't start after latest updates

Similar problem. The error message doesn't come up if I wait about 10 minutes before logging in.

~$ sudo /etc/init.d/dbus restart
 * Stopping NetworkManager dispatcher [ 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 [ ok ]
 * Starting Hardware abstraction layer hald
<Here it sits for a couple of minutes, so I guess that's where the problem is> [ ok ]
 * Starting DHCP client manager... [ ok ]
 * Starting NetworkManager daemon [ ok ]
 * Starting NetworkManager dispatcher [ ok ]

During the restart, gnome-panel stops responding. killall gnome-panel gets it going again, but it takes about a minute. Gnome-panel is also v slow on log-in, even if I wait for a while before log-in.

same issues as the above two entries, seems something in the hald last evening

Hi Martin,

There appears to be some useful debugging information in the
associated Debian bug.

Perhaps we got this behaviour when we pulled in the endian
probing patch?

I'll talk with Sjoerd to debug this. Unfortunately I cannot reproduce it myself.

Last night's batch of updates included hal, once I installed that update everything seems to be fixed. I'm not sure about anyone else who chimed in, but the bug can be closed for me.

Brandon, Jason, do you confirm/deny that it works now, too?

My issues aren't fixed yet.

I posted a dupe here: https://launchpad.net/distros/ubuntu/+source/hal/+bug/44091

With all updates installed I still have the same issues. Maybe mine is a different issue and shouldn't have been duped.

My issues are now 1/2 fixed.

I used to get an unusable system -- starting hald would kill all getties and X sessions.

After upgrading, it just runs for a while, and then dies. I am running dapper/amd64 and I see the same output as Dennis.

Actually, after restarting dbus, it seems hald seems to stay up. Previously I ran it manually using --daemon=no.

All working - thanks guys. Had a knock-on effect that gnome-panel is starting as it should. Also file browsing was slow to start and that's fixed too.

I think I was incorrect when I said that my problems were fixed. Although I didn't seem to get the error when I restarted my computer this morning, I have gotten the problems while starting up twice this evening.

Additionally, I am getting the "Internal error - failed to initialize HAL" error after I log in and while Gnome is starting up.

I don't believe that the Debian bug and this bug are about the same issue. In the debian bug, the hald-runner is crashing, here the root cause seems to be the input probing endianess fix. Can anyone please try this:

  sudo apt-get update
  sudo apt-get build-dep hal
  apt-get source hal
  cd hal-0.5.7
  rm debian/patches/13_probe_input_endianess.patch
  debuild -us -uc -b
  sudo dpkg -i ../hal_*.deb

and then reboot and check if it works again?

I stared at that patch again, and it indeed looks fishy now (incompatibility to the ioctl). I backed out the patch and will discuss this with the author and upstream.

hal (0.5.7-1ubuntu15) dapper; urgency=low
 .
   * Fix name of 14_prove_volume_invalidlabel.patch -> s/prove/probe/.
   * Disable debian/patches/13_probe_input_endianess.patch for now; it is
     incorrect (the ioctl expects chars, not long) and causes crashes.
     Closes: LP#43962 (and half a dozen dups)