have you merged all the .new files ?

Yes .new files are merged. I'm prompted to remove the dbus package and any scripts/configuration files that remain and then reinstall. If that doesn't work I'll do the same with HAL. Should have thought of it sooner, thanks for the prompt.

#hal-device lists all the devices, so I think the problem may be with the dbus installation.

HAL is now working!

Slackware upgrade, 11.0 - 12.0, 2.6.22.1 kernel.

I removed DBUS and HAL and any remaining files to clean the system of previous installs. After reinstalling, hald would NOT start during boot.

Running the script in a terminal:
An alternative approach, similar to the rc.hald script, with verbose for debugging:
--retain-privileges option:
HAL daemon is running, cdrom spins up and down, as before, but no desktop icon/automount.

For details;
Added --retain-privileges to the rc.hald script (plus --verbose=yes --use-syslog, for debugging output).

The syslog entry, "Not adding device object" is no longer present, but still no desktop icon and automounting.

However, after logging out of the desktop, and logging back in, HAL and automount worked perfectly!

Next step was to remove the --retain-privileges option from the rc.hald script to see if hald would start normally.
Unfortunately it didn't, the --retain-privileges option is still required.

Still working on this.

Do you have a haldaemon user and group? The HAL daemon drops root privileges and runs at that user as much as possible, so I'm guessing you didn't *truly* merge *all* of the .new files (in this case, the passwd.new and group.new). This was covered in the official guide to upgrading - http://slackware.osuosl.org/slackware-12.0/UPGRADE.TXT

Thanks Robby, I take your point and will go back over the process again. Something is amiss.
I did edit the group file and have haldaemon user and group and the appropriate users in the appropriate groups. I did not touch the passwd file as per recommendations in the instructions. I will edit the previous post to outline the procedure I followed, rather than assume that the problem is fixed!

Cheers!

Addendum.

Went over passwd and group files with a fine toothcomb. I had previously added the required groups as recommended in the "instructions." However, there were errors and these are now fixed. The errors were not related to assigning users and groups for HAL and DBUS, they were very subtle omissions in the files and difficult to spot. e.g haldaemon::82:haldaemon,username as opposed to haldaemon:x:82:etc....

As the PC is a clean install and HAL is working correctly, and user names and passwords are identical to the laptop, I compared the group and passwd files, making changes where appropriate, but with regard to HAL and DBUS they were identical; laptop still requires --retain-privileges.
Am I correct in assuming that the hal daemon checks for appropriate users/groups while it is starting and exits if not found, --retaining-privileges causes HAL to work in the users desktop as root. That's why log out, log in is necessary to configure the desktop? Not absolutely sure about that. WIP. Any suggestions?

Forgive the simple questions, but I recently upgraded to Slackware 12.0 and am having a different set of problems from that listed below. I've added myself to the plugdev group, so when I plug in the USB memory stick, I get a konqueror window showing the contents as system:/media/sdd1. However, in a command line window, ls /media doesn't show the device, nor do I get any sort of icon on the desktop (I'm using KDE). I also can not write to the device. This all seems to imply that, even though I see the contents in the konqueror window, the memory stick is not actually mounted yet. Is this correct? If so, what do I still need to do to have the device automatically mounted? Should it be in fstab? If this isn't correct, why don't I see the device, and why can't I write to it?

Navigating to that url ( system:/media/sdd1 ) in konqueror should mount the drive and allow you to access it, and it will then be accessible from a terminal as well. HAL doesn't mount anything - that's done by a separate layer that can be (and is usually) built into the desktop environment (kde, gnome, and xfce have it), but also a combination of ivman and pmount will allow it to work from either the console or other window managers.

I think you can configure kde to automatically mount removable devices when they're plugged in, but I'm not terribly familiar with kde, so I won't swear to that. Somewhere in this thread (or maybe it was another one - I've lost track), instructions for getting desktop icons in kde were given as well.

If you're using Xfce, then you could install the thunar-volman plugin to automatically mount removable devices when they're inserted, and there are quite a few other plugins that enhance the user experience. I've got most of them packaged - see the links in my signature.

I took the advice that I usually give to new linux users and completely read the *** thread. From that I saw the instructions on getting the desktop icons loaded. I also added myself to the cdrom, audio, video, messagebus, and haldaemon groups, as recommended at various points in the thread. However, I still can't write to the device, nor does it show up doing an ls on media from a terminal. More interestingly, locate does not find either pmount (although it does find apmount, which was part of the kdeedu package) or ivman. I've done a full install of the generic Slackware 12.0 packages, but haven't done any of the extra packages yet. Are they included there? Either way, any other advice on what to try?

Outlander:

It looks like the messagebus service is not running.

You don't need to be in messagebus and haldaemon groups - remove yourself from them.

pmount and ivman are not available in stock Slackware, and you don't need them if you're using kde, gnome, or xfce. If you decide you want them, then have a look at http://slackbuilds.org.

What kind of device is this? It's not really clear on whether it's actually being detected or not, whether it's mounted or not, etcetera.
EDIT: I see that it's a usb flash drive. There are quite a few things I'd like to look at, but it's easier to debug this in real-time. Please consider joining the ##slackware channel on irc.freenode.net or #slackware on irc.oftc.net and looking me up. I'm not available all the time, of course, but I'll be glad to look into this when I am.

I don't have much to add, but after finally compiling my custom kernel I would just like to confirm pappy's results -- to access the root partition through media:/ in Konqueror you must have an initrd.gz. So, basically, make sure to compile filesystems as modules and enable the initrd and ramdisk settings when compiling your custom kernel (basically just follow the same layout for the ramdisk and filesystems as in the generic kernels). Easy solution to a potential custom kernel problem.

Umm Why would you want to access / through media: ?

I have no idea. I would never want to access / through media:/. It's more confusing to me than just navigating to / instead of accessing it as a partition. However, people were complaining (in this thread and in other threads) that they couldn't access / through media:/ like they used to in Slackware 11.0. For those people that do want that, pappy found the answer when using custom kernels. I just wanted to verify it after compiling my own. I hardly ever use Konqueror anyway (I would rather use a terminal to navigate to my files) and when I do use Konqueror it's only really to browse what's in my home directory (so I don't need to use media:/ anyway), but hey, to each his own.

This is entirely off-topic for a HAL discussion anyway, so I will leave it at that.

I don't see that what you said is off topic, since it directly relates to working with Slack-12 and hal in reference to using custom compiled kernels. Since it is clear that there are many in the Linux community who are all about custom kernels and tweaking them to within inches of being operable (I'm getting there quickly), I think it's a good thing to let those people, and everyone else here know that they need to have smp support compiled in, and an initrd.gz file to get everything going as expected under hal.

Also, thank you for the vote of confidence. I was starting to feel a little like the red-headed step-child after the last few weeks. It's good to know that even though I am not a guru, I can be right sometimes.

Blessed be!
Pappy

Hi Robby,

I've verified that messagebus is working, ps -e, and other services such as kbluetooth are using it without problems.
As user it appears not to be talking to hald. I thought the /dev/null issue might fix it, but no such luck. WIP.

Edit.
If I understand correctly, a possible reason that hald requires --retain-privileges and does not otherwise communicate with dbus, is that my desktop is running in a different console to the one HAL expects, and is refusing connections to DBUS?

"DBUS needs to determine the session that the calling application stems from. HAL would refuse service unless it is from a session on an active console (Zeuthen 2006, pp-23).

Come to think of it, hald is not starting as root in anycase, although DBUS is starting? WIP

References

http://people.freedesktop.org/~david...006-davidz.pdf