Bug 241084

Summary: hal doesn't seem to provide some module to smolt
Product: [Fedora] Fedora Reporter: Răzvan Sandu <rsandu2004>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NOTABUG QA Contact: Ben Levenson <benl>
Severity: urgent Docs Contact:
Priority: medium    
Version: 7CC: davidz, mmcgrath
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-11 17:21:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output from hald
none
Output from lshal
none
Other output from lshal none

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

Hello,

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
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 230, in __init__
    _dbus_bindings.UInt32(0))
  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,
timeout)
dbus.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Hal was not provided by any .service files

Regards,
Răzvan

Version-Release number of selected component (if applicable):
smolt-0.9.7.1-4.fc7
hal-0.5.9-8.fc7
dbus-1.0.2-4.fc7
kernel-2.6.20-1.2948.fc6
kernel-2.6.21-1.3175.fc7


How reproducible:
Sometimes.

  
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
Hello,


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


Regards,
Răzvan


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'

Thanks.

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

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.


Regards,
Răzvan

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

/usr/bin/lshal

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

hal-0.5.9-8.fc7
hal-info-20070516-2.fc7

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...)

Regards,
Răzvan




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.ro>' to davidz was from you)

Thanks.


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
situation.

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

Răzvan



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
 lshal

Thanks!


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

Hello,

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

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

Regards,
Răzvan

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
Hello,

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
key=(null)

Regards,
Răzvan

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
Hello,


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.


Regards,
Răzvan


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
reboot