Description of problem: hald will not start. It fails with the following error: *** [DIE] mmap_cache.c:di_rules_init():68 : Unable to open cache /var/cache/hald/fdi-cache Complete output with verbosity turned on: [root@localhost sbin]# hald --daemon=no --verbose=yes 17:15:11.719 [I] hald.c:529: hal 0.5.9 17:15:11.720 [I] hald.c:594: Will not daemonize 17:15:11.720 [I] hald_dbus.c:4807: local server is listening at unix:abstract=/var/run/hald/dbus-z1IRTgeTGz,guid=cd01c1053c1c19a32983db004669d4ef 17:15:11.725 [I] ck-tracker.c:387: got seat '/org/freedesktop/ConsoleKit/Seat1' 17:15:11.730 [I] ck-tracker.c:317: got session '/org/freedesktop/ConsoleKit/Session1' for seat '/org/freedesktop/ConsoleKit/Seat1' 17:15:11.732 [I] ck-tracker.c:270: Got active state (ACTIVE) and uid 0 on session '/org/freedesktop/ConsoleKit/Session1' 17:15:11.732 [I] ck-tracker.c:338: Got all sessions on seat '/org/freedesktop/ConsoleKit/Seat1' 17:15:11.732 [I] ck-tracker.c:414: Got seats 17:15:11.733 [I] ck-tracker.c:796: Got seats and sessions Runner started - allowed paths are '/usr/libexec:/usr/lib/hal/scripts:/usr/bin' 17:15:11.736 [I] hald_runner.c:299: Runner has pid 3448 17:15:11.736 [W] ci-tracker.c:200: Could not get uid for connection: org.freedesktop.DBus.Error.NameHasNoOwner Could not get UID of name 'org.freedesktop.DBus': no such name 17:15:11.737 [E] hald_dbus.c:4462: Cannot get caller info for org.freedesktop.DBus 17:15:11.737 [I] hald_runner.c:180: runner connection is 0x83633c8 17:15:11.738 [I] mmap_cache.c:161: Regenerating fdi cache.. Run started hald-generate-fdi-cache (10000) (0) ! full path is '/usr/libexec/hald-generate-fdi-cache', program_dir is '/usr/libexec' 17:15:11.748 [I] create_cache.c:608: Loading rules 17:15:11.957 [I] create_cache.c:674: preprobe: offset=00000014, size=3124 17:15:11.957 [I] create_cache.c:676: information: offset=00000c48, size=404468 17:15:11.957 [I] create_cache.c:678: policy: offset=0006383c, size=31440 17:15:11.957 [I] create_cache.c:680: Generating rules done (occupying 439052 bytes) /usr/libexec/hald-generate-fdi-cache exited 17:15:11.957 [I] mmap_cache.c:137: In regen_cache_cb exit_type=0, return_code=0 17:15:11.957 [I] mmap_cache.c:193: fdi cache generation done 17:15:11.957 [I] mmap_cache.c:251: cache mtime is 1180122636 *** [DIE] mmap_cache.c:di_rules_init():68 : Unable to open cache /var/cache/hald/fdi-cache Version-Release number of selected component (if applicable): HAL package version: 0.5.9 Kernel version: 2.6.21-1.3194.fc7 How reproducible: Perform hard disk install from F7 Live CD. hald service fails to start at boot time. Attempt to start manually, and status is FAILED. Additional info: I have not attempted this installation on another machine as I do not have one available at the moment. /var is on its own partition. After attempting to start hald, the cache file is being generated in the expected location. [root@localhost hald]# ls -al /var/cache/hald total 896 drwxr----- 2 root root 4096 2007-06-08 17:15 . drwxr-xr-x 11 root root 4096 2007-06-07 20:50 .. -rw-r--r-- 1 root root 439052 2007-06-08 17:15 fdi-cache
Got same problem after F7 install on Dell Latitude 610. The problem is directory /var/cache/hald is owned by root and permissions 0700. When privilege separation daemon runs as haldaemon, this directory is no longer readable. The fix is to change the ownership of /var/cache/hald to haldaemon:haldaemon . This bug is perplexing because it does not show up on Dell Dimension E520. On that machine, immediately after F7 install, the directory is owned by the correct user. I did both installs from the *same* F7 Live CD.
I installed F7 Live CD on a Sony Vaio FS640/W and the same problem occurred. That is, the /var/cache/hald directory was owned by root:root and inaccessible to haldaemon user.
Created attachment 159360 [details] syslog output from hald-generate-fdi-cache failure I'm seeing similar problems as well, which appear to be SELinux-related. I've attached the syslog output running hald with "--verbose=yes", as well as the avc denials. The directory in question, /var/cache/hald, looks like this: # ls -lAFZd /var/cache/hald drwx------ haldaemon haldaemon system_u:object_r:var_t /var/cache/hald/ # cd /var/cache/hald # ls -lAFZ -rw-r--r-- root root user_u:object_r:var_t fdi-cache It was resolved by doing a chcon of /var/cache/hald/fdi-cache to user_u:object_r:hald_cache_t. Perhaps the directory itself might benefit from that as well?
I should probably note as well: I upgraded this machine from the previous FC6 install via yum, rather than via the installer. SELinux was enabled in both cases, but perhaps the cache wasn't covered by policy previously?
Judging from comment 3, this looks like an SELinux issue. Dan, any ideas?
This is a labeling problem restorecon -R -v /var/cache Should fix this.
(In reply to comment #6) > This is a labeling problem > > restorecon -R -v /var/cache > > Should fix this. Wait. Things like this should work automatically without the end user having to resort to such thus. I believe the problem is that the 'hal' RPM got upgraded prior to the 'selinux-policy' or 'selinux-policy-targeted' packages. Edward, can you check your logs and confirm this?
THe update of policy should have done this via checking the difference between the two policies. But obviously this one was missed. I have no idea why and believe that it would be very difficult to duplicate.
Here's the yum.log* results for anything matching hal or selinux for the FC7 update that I did (plus the most recent upgrade): Jul 06 16:36:42 Updated: libselinux-devel.i386 2.0.14-2.fc7 Jul 06 16:40:05 Updated: libselinux.i386 2.0.14-2.fc7 Jul 06 16:42:26 Installed: hal-libs.i386 0.5.9-8.fc7 Jul 06 16:48:37 Updated: libselinux-python.i386 2.0.14-2.fc7 Jul 06 16:49:50 Updated: selinux-policy.noarch 2.6.4-23.fc7 Jul 06 16:54:38 Updated: selinux-policy-targeted.noarch 2.6.4-23.fc7 Jul 06 16:55:03 Installed: hal.i386 0.5.9-8.fc7 Jul 06 16:55:15 Installed: hal-info.noarch 20070516-2.fc7 Jul 16 10:31:54 Updated: selinux-policy.noarch 2.6.4-26.fc7 Jul 16 10:33:05 Updated: selinux-policy-targeted.noarch 2.6.4-26.fc7 What's interesting is that yum recorded it as an install rather than an update, but if I check today, there's only a single hal (or hal-info, or hal-libs) package installed. Hmm. One thing of interest: I seem to recall doing a smoltSendUpdate after finishing the FC7 upgrade, and it worked. (That's what initially alerted me to the problem: smolt couldn't connect to hald today when I tried to manually run it.) Does smolt.fedoraproject.org retain a history of such things? (If so, I could supply the UUID of this machine to help track that down, if you're interested.) The versions I was coming from (in FC6) were: Jan 08 08:40:29 Updated: hal.i386 0.5.8.1-6.fc6 Jan 18 17:46:19 Updated: libselinux.i386 1.33.4-2.fc6 Jan 18 17:47:38 Updated: libselinux-devel.i386 1.33.4-2.fc6 Jan 18 17:48:03 Updated: libselinux-python.i386 1.33.4-2.fc6 Jun 27 07:15:19 Updated: selinux-policy.noarch 2.4.6-75.fc6 Jun 27 07:15:51 Updated: selinux-policy-targeted.noarch 2.4.6-75.fc6 Hope this helps. :-)
*** Bug 248636 has been marked as a duplicate of this bug. ***
There have been several fixes to fixfiles that should fix this problem. Fixed in policycoreutils-2.0.16-13.fc7.src.rpm