Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 241084 - hal doesn't seem to provide some module to smolt
hal doesn't seem to provide some module to smolt
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-05-23 18:49 EDT by Răzvan Sandu
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-11 13:21:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Răzvan Sandu 2007-05-23 18:49:12 EDT
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 12:58:13 EDT

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 13:00:56 EDT
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 14:54:26 EDT

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 14:59:22 EDT
Are you getting valid output from:

Comment 5 David Zeuthen 2007-06-04 15:04:55 EDT
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 16:09:20 EDT
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 16:44:17 EDT
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 16:52:42 EDT
Also, what is the output of 'getenforce' (as root)? Thanks.
Comment 9 Răzvan Sandu 2007-06-04 17:10:49 EDT
Created attachment 156134 [details]
Output from hald
Comment 10 Răzvan Sandu 2007-06-04 17:12:31 EDT
Created attachment 156135 [details]
Output from lshal
Comment 11 Răzvan Sandu 2007-06-04 17:15:07 EDT
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 17:30:23 EDT
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 01:52:16 EDT
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 08:56:32 EDT
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 09:15:22 EDT
Could you attach your /var/log/audit/audit.log
Comment 16 Răzvan Sandu 2007-06-10 04:28:47 EDT

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 11:07:07 EDT
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 11:45:11 EDT

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 13:21:06 EDT
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.