Bug 241084 - hal doesn't seem to provide some module to smolt
Summary: hal doesn't seem to provide some module to smolt
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2007-05-23 22:49 UTC by Răzvan Sandu
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2007-06-11 17:21:06 UTC

Attachments (Terms of Use)
Output from hald (210.86 KB, text/plain)
2007-06-04 21:10 UTC, Răzvan Sandu
no flags Details
Output from lshal (77.00 KB, text/plain)
2007-06-04 21:12 UTC, Răzvan Sandu
no flags Details
Other output from lshal (77.00 KB, text/plain)
2007-06-05 05:52 UTC, Răzvan Sandu
no flags Details

Description Răzvan Sandu 2007-05-23 22:49:12 UTC
Description of problem:


After upgrading from FC6 to F6.93, I tried to run smoltSendProfile, a script
from the smolt package. However, I get this:

[root@gateway1 ~]# smoltSendProfile
Traceback (most recent call last):
  File "/usr/bin/smoltSendProfile", line 95, in <module>
    profile = smolt.Hardware()
  File "/usr/share/smolt/client/smolt.py", line 258, in __init__
    mgr = self.dbus_get_interface(systemBus, 'org.freedesktop.Hal',
'/org/freedesktop/Hal/Manager', 'org.freedesktop.Hal.Manager')
  File "/usr/share/smolt/client/smolt.py", line 294, in dbus_get_interface
    proxy = bus.get_object(service, object)
  File "/usr/lib/python2.5/site-packages/dbus/_dbus.py", line 410, in get_object
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 230, in __init__
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 169, in __call__
    reply_message = self._connection.send_message_with_reply_and_block(message,
dbus.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Hal was not provided by any .service files


Version-Release number of selected component (if applicable):

How reproducible:

Actual results:
It seems a module is missing.

Expected results:
smoltSendProfile should send hardware profile to the smolt server.

Additional info:
Please see https://hosted.fedoraproject.org/projects/smolt/ticket/8

Comment 1 Răzvan Sandu 2007-06-04 16:58:13 UTC

I get the same on Fedora 7, after the official launch, on many Fedora boxes.
Still no solution ?


Comment 2 David Zeuthen 2007-06-04 17:00:56 UTC
Two questions

 1. What is the output of 'chkconfig --list haldaemon'
 2. What is the output of 'lshal'


Comment 3 Răzvan Sandu 2007-06-04 18:54:26 UTC

Here they are:

[root@gateway1 ~]# chkconfig --list haldaemon
haldaemon       0:off   1:off   2:off   3:on    4:on    5:on    6:off

[root@gateway1 ~]# lshal
Could not initialise connection to hald.
Normally this means the HAL daemon (hald) is not running or not ready.

Trying to manually (re)start haldaemon, service is not starting:

However, I didn't do any manual modification on these machines (beyond a default
instalation of Fedora + online updates). The only particularity is that they
were upgraded from FC6 to F7 via yum and not via CD.


Comment 4 Mike McGrath 2007-06-04 18:59:22 UTC
Are you getting valid output from:


Comment 5 David Zeuthen 2007-06-04 19:04:55 UTC
Please attach the output of

 /usr/sbin/hald --daemon=no --verbose=yes

when running as root. Also, what versions of hal and hal-info RPM's are you
using? Thanks.

Comment 6 Răzvan Sandu 2007-06-04 20:09:20 UTC
I'm running


Could you please specify a way to capture the output of 

/usr/sbin/hald --daemon=no --verbose=yes

in a text file ? Using a standard redirection ( > ) doesn't work and that's a
lot of output... (sorry, I'm not a programmer...)


Comment 7 David Zeuthen 2007-06-04 20:44:17 UTC
Do this as root

 /usr/sbin/hald --daemon=no --verbose=yes > hald_out.txt 2>&1

If the command doesn't return it's good. Then go to another terminal and type
'lshal > lshal_out.txt'.

Attach both hald_out.txt and lshal_out.txt to this bug.

(Also please avoid sending me mail directly on the bug report; I suspect the one
from 'root <root@gateway1.ircolours.ro>' to davidz@redhat.com was from you)


Comment 8 David Zeuthen 2007-06-04 20:52:42 UTC
Also, what is the output of 'getenforce' (as root)? Thanks.

Comment 9 Răzvan Sandu 2007-06-04 21:10:49 UTC
Created attachment 156134 [details]
Output from hald

Comment 10 Răzvan Sandu 2007-06-04 21:12:31 UTC
Created attachment 156135 [details]
Output from lshal

Comment 11 Răzvan Sandu 2007-06-04 21:15:07 UTC
Output from getenforce is "Enforcing". Putting "setenforce 0" doesn't change te

Sorry for the direct mail - it was a desperate try ;-)


Comment 12 David Zeuthen 2007-06-04 21:30:23 UTC
OK, so this is what I gather from comment 9 and comment 10

 1. Starting hald manually works fine

and from comment 11

 2. You're running in SELinux enforcing mode

> Putting "setenforce 0" doesn't change te
> situation.

Just to verify, try as root

 setenforce 0
 /etc/init.d/haldaemon start


Comment 13 Răzvan Sandu 2007-06-05 05:52:16 UTC
Created attachment 156171 [details]
Other output from lshal


Yes, it *is* selinux-related: the daemon starts now (please see the attached

But it's very strange, since I've *verified* this last time, when I first wrote
and *it didn't* worked...


Comment 14 David Zeuthen 2007-06-05 12:56:32 UTC
Possibly you need to relabel the whole file system; either way, reassigning to
the appropriate SELinux component. Thanks for using Fedora.

Comment 15 Daniel Walsh 2007-06-05 13:15:22 UTC
Could you attach your /var/log/audit/audit.log

Comment 16 Răzvan Sandu 2007-06-10 08:28:47 UTC

Here is the relevant entry:

type=AVC msg=audit(1181463991.299:120): avc:  denied  { getattr } for  pid=7414
comm="hald" name="fdi-cache" dev=sda2 ino=9689858
scontext=user_u:system_r:hald_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
type=SYSCALL msg=audit(1181463991.299:120): arch=c000003e syscall=4 success=no
exit=-13 a0=43b10f a1=7fffe4bfbe20 a2=7fffe4bfbe20 a3=6569a0 items=0 ppid=7413
pid=7414 auid=500 uid=68 gid=68 euid=68 suid=68 fsuid=68 egid=68 sgid=68
fsgid=68 tty=(none) comm="hald" exe="/usr/sbin/hald"
subj=user_u:system_r:hald_t:s0 key=(null)
type=AVC_PATH msg=audit(1181463991.299:120):  path="/var/cache/hald/fdi-cache"
type=AVC msg=audit(1181463991.303:121): avc:  denied  { write } for  pid=7416
comm="hald-generate-f" name="hald" dev=sda2 ino=9690180
scontext=user_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir
type=SYSCALL msg=audit(1181463991.303:121): arch=c000003e syscall=2 success=no
exit=-13 a0=7fff68b82780 a1=242 a2=1a4 a3=0 items=0 ppid=7415 pid=7416 auid=500
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
comm="hald-generate-f" exe="/usr/libexec/hald-generate-fdi-cache"
subj=user_u:system_r:hald_t:s0 key=(null)
type=AVC msg=audit(1181463991.305:122): avc:  denied  { read } for  pid=7414
comm="hald" name="fdi-cache" dev=sda2 ino=9689858
scontext=user_u:system_r:hald_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
type=SYSCALL msg=audit(1181463991.305:122): arch=c000003e syscall=2 success=no
exit=-13 a0=43b10f a1=0 a2=12 a3=2aaaabbc99d0 items=0 ppid=7413 pid=7414
auid=500 uid=68 gid=68 euid=68 suid=68 fsuid=68 egid=68 sgid=68 fsgid=68
tty=(none) comm="hald" exe="/usr/sbin/hald" subj=user_u:system_r:hald_t:s0


Comment 17 Daniel Walsh 2007-06-11 15:07:07 UTC
The problem here is that /var/cache/hald is mislabeled.

restorecon -R -v /var/cache/hald

Did this dir get removed and added back?  Somehow it got mislabled.

Comment 18 Răzvan Sandu 2007-06-11 15:45:11 UTC

The system was upgraded via yum from Fedora Core 6 to Fedora 7.

I didn't do any manual interventions other than the default ones, operated by
rpm when upgrading the new selinux-policy-targeted.

This happened on *many* systems, not on a single one.

Is it possible that the rpm package somehow „forgets” to set the proper SELinux
context for /var/cache/hald during upgrade ?

The matter is not about doing a manual relabel after upgrade, but to
unexpectedly inhibiting haldaemon.

I will leave this open for the time being, until we learn this.


Comment 19 Daniel Walsh 2007-06-11 17:21:06 UTC
I guess this is why upgrades are almost never fully supported.  Problem is all
directories in created are not necessarily labeled correctly during the upgrade.
 RHEL4-RHEL5 forces a relabel. 

So it is probably advisable to do a 

touch /.autorelabel

Note You need to log in before you can comment on or make changes to this bug.