hald: failed (VL5.9 SOHO) -- SOLVED

[LLL]

VL'ers,

I've finally had a moment to make use of my hot-green 5.9 SOHO CD's I ordered way back when. A great distro for sure!! I'm stuck though - having read every post on this forum on HAL (I'm hoping saying that will lead to a foot-in-mouth moment when one of you points me to an already posted solution "...you didn't read this one!"), but no luck.

So, during boot I get a "hald FAILED" message. Messagebus loads just prior in the boot sequence, but hald fails every time. Previously I was able to call it afterwards, as root "/etc/rc.d/rc.hald start", but now even that doesn't work.

Any ideas on getting me going? I've switched back to VL-hot, and might stick with it regardless, but would be nice to know the why's and how's of this HAL fix should I ever want it back.

So...what do you lovely wizards need to know in order to dig me out of this little hole?

Many thanks in advance!

LL-LLL
(Long-Lost LLL)


LLL-Edit: Marking this one solved - solution is in the last post on this page - scroll down.
Update 2: I found out what had updated glib - inkscape 0.46 requires it, and won't run without it...but I believe 0.45 will.

[M0E-lnx]

I would start by making sure HAL is up-to-date
as a matter of fact, HAL, dbus, udev, hal-info I think are all involved

One other *really* important thing I found out is that our util-linux shipped with even the latest 5.9 releases has problems (outdated) so I'd upgrade that too.

Try upgrading these and see if you can start it from a terminal..
Do you get any output from the terminal?

[LLL]

Thanks, M0E.

I made sure all were the latest from the repo (only one I hadn't found earlier was udev; there was nothing available for util-linux). But, still, nothing...and no terminal output beyond "FAILED" during boot, and this on a manual start:

1) I start HAL...says it started it:

vector://home/andy
root:# /etc/rc.d/rc.hald start
Starting HAL daemon:  /usr/sbin/hald --daemon=yes

2) Then, to confirm HAL is running, I check the process list, and only my "grep" comes back:

vector://home/andy
root:# ps aux |grep hal
root      3615  0.0  0.0   3048   812 pts/1    R+   09:10   0:00 grep hal

Any ideas? If the vl-hot udev rule is still active will it stop HAL from starting? I wouldn't think so, but...

Your help is appreciated!

LLL

[M0E-lnx]

how about executing hald in a terminal ... does that give you any feedback?

[LLL]

No immediate error output, and apparent success as far as the processes running:

vector://home/andy
root:# hald
vector://home/andy
root:# ps aux |grep hal
82        3671  9.1  0.3   5784  3920 ?        Ss   09:34   0:00 hald
root      3672  0.0  0.0   2948   984 ?        S    09:34   0:00 hald-runner
82        3678  0.0  0.0   2156   928 ?        S    09:34   0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
root      3679  0.0  0.1   3040  1080 ?        S    09:34   0:00 hald-addon-input: Listening on /dev/input/event4 /dev/input/event2 /dev/input/event1
root      3689  0.0  0.0   3036   984 ?        S    09:34   0:00 hald-addon-storage: polling /dev/hdc (every 2 sec)
root      3691  0.0  0.0   3048   816 pts/1    R+   09:34   0:00 grep hal

So the question is: Why doesn't it work when called from rc.hald?

We're getting there - thanks!

LLL

[kukibl]

Same problem here, except I am using 5.9.1 SOHO. Hal worked just fine, now it fails every time system boots up. I am talking about clean install, the only modifications I made were installing new packages from official repo (inkscape, vlc, firefox and gnutls upgrade).

Any ideas?

[bigpaws]

Have you checked the output from dmesg and /var/log/messages as
well as the faillog?

That might give you a clue. It is possible the HAL is trying to initialize
before dbus.

Bigpaws

[kukibl]

Have you checked the output from dmesg and /var/log/messages as
well as the faillog?

Sorry, I'm an idiot. It is incredible I haven't remembered to check logs.

Code:

$dmesg | grep hald
hald[3336]: segfault at 0 ip b7ed51dd sp bf8e9e80 error 4 in libglib-2.0.so.0.1600.6[b7eb0000+b6000]

Code:

#cat /var/log/messages | grep hald
Nov 26 15:22:12 meanmachine hald: mounted /dev/sdb on behalf of uid 1000
Nov 26 15:22:30 meanmachine hald: unmounted /dev/sdb from '/media/M2 512MB' on behalf of uid 1000
Nov 27 02:30:14 meanmachine hald: mounted /dev/sdb on behalf of uid 1000
Nov 27 02:32:04 meanmachine hald: unmounted /dev/sdb from '/media/M2 512MB' on behalf of uid 1000
Nov 27 15:21:18 meanmachine kernel: hald[3260]: segfault at 0 ip b7ee21dd sp bfff8cb0 error 4 in libglib-2.0.so.0.1600.6[b7ebd000+b6000]
Nov 27 16:16:56 meanmachine kernel: hald[3339]: segfault at 0 ip b7e851dd sp bfa9b720 error 4 in libglib-2.0.so.0.1600.6[b7e60000+b6000]
Nov 27 22:46:18 meanmachine kernel: hald[3298]: segfault at 0 ip b7e941dd sp bf9a86c0 error 4 in libglib-2.0.so.0.1600.6[b7e6f000+b6000]
Nov 27 22:49:42 meanmachine kernel: hald[3336]: segfault at 0 ip b7ed51dd sp bf8e9e80 error 4 in libglib-2.0.so.0.1600.6[b7eb0000+b6000]

 

[bigpaws]

Nov 27 02:30:14 meanmachine hald: mounted /dev/sdb on behalf of uid 1000
Nov 27 02:32:04 meanmachine hald: unmounted /dev/sdb from '/media/M2 512MB' on behalf of uid 1000

This is a permissions issue. Is this user a member of groups like plugdev ?

Bigpaws

[kukibl]

This is a permissions issue. Is this user a member of groups like plugdev ?

Bigpaws

Yes, it is. I am more worried with segfault, I guess that error is causing HAL fail on boot.

[bigpaws]

The very narrow grep is not giving enough information. Go through
dmesg line by line to see what is happening before the hald segfault.

After checking google for the past 30 minutes there appears to be several things
that can create the segfault.

Bigpaws

[kukibl]

I've checked dmesg, but can't see anything strange going on before getting hald segfault line. I've attached dmesg output. I can see some mISDN modules error reports after, but everything works the same as before hald failure.

I just don't get it, simply because hald failed without any special reason. First 5 boots worked just fine and now is failing every single time.

[bigpaws]

What about the other logs?

Bigpaws

[uelsk8s]

kukibl,
can you try reinstalling the hal package, it may have been corrupted, or worse is having a conflict with one of the other pkgs you upgraded

[kukibl]

What about the other logs?

Bigpaws

Ok. I attached output from /var/log/messages. Also I used some tips from hald man pages - using gdb to debug problems.

Code:

#gdb /usr/sbin/hald
run --daemon=yes --verbose=yes
Starting program: /usr/sbin/hald --daemon=yes --verbose=yes
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
01:23:13.934 [I] hald.c:634: hal 0.5.10
01:23:13.934 [I] hald.c:643: Will daemonize
01:23:13.934 [I] hald.c:644: Becoming a daemon

Output of --daemon=no --verbose=yes you can find in attachment.

kukibl,
can you try reinstalling the hal package, it may have been corrupted, or worse is having a conflict with one of the other pkgs you upgraded

I've reinstalled hal and hal-info package, but nothing changes. I really don't know which packages hal could conflict, since all upgrades are done using official pkgs from VL repo.

UPDATE:

Woo-hoo, problem solved. I totaly forgot to check /var/log/removed_packages/ for upgraded packages. I did that and found out that glib2 package itself was upgraded - stock 2.12.13 with 2.16.6. I don't know which package exactly pulled down newer glib2 as dependecy, but it is obviously a mistake by slapt-get or packager. Anyway, now everything works just fine.

Thank you very much uelsk8s for your tip and bigpaws for your effort and good will to help. I really appreciate it.