Bug 241084
Summary: | hal doesn't seem to provide some module to smolt | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Răzvan Sandu <rsandu2004> | ||||||||
Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> | ||||||||
Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> | ||||||||
Severity: | urgent | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 7 | CC: | 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
Răzvan Sandu
2007-05-23 22:49:12 UTC
Hello, I get the same on Fedora 7, after the official launch, on many Fedora boxes. Still no solution ? Regards, Răzvan Two questions 1. What is the output of 'chkconfig --list haldaemon' 2. What is the output of 'lshal' Thanks. 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 Are you getting valid output from: /usr/bin/lshal 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. 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 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. Also, what is the output of 'getenforce' (as root)? Thanks. Created attachment 156134 [details]
Output from hald
Created attachment 156135 [details]
Output from lshal
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 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! 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
Possibly you need to relabel the whole file system; either way, reassigning to the appropriate SELinux component. Thanks for using Fedora. Could you attach your /var/log/audit/audit.log 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 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. 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 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 |