Slack Current and KDE 3.5 automount

Originally Posted by rkelsen So, what would happen in the situation where (as a result of a bad write) the file is corrupted and you don't realise until the next time you try to boot your computer?

Can't say I've ever heard of this happening even when HAL *did* use fstab-sync... Ever.

But it sounds like a good reason to stop using the fstab entirely and replace it with a dynamic, automatic system that can keep track of devices and their mountpoints.

Wait a sec...

Originally Posted by rkelsen That has already been pointed out. Please try to keep up.

Troll much?

Originally Posted by rkelsen So, what would happen in the situation where (as a result of a bad write) the file is corrupted and you don't realise until the next time you try to boot your computer?

The machine's going to either stop the boot process because it can't read the list in fstab, or it's going to fail to mount some filesystems that it was probably supposed to. Do you have any other unrelated trivia questions to ask?

Originally Posted by rkelsen It doesn't work under KDE 3.4.2. In fact, I couldn't get it working under Slackware 10.2 at all. So they deprecated fstab-sync and haven't replaced it with anything? This all sounds too complicated.

It only sounds complicated if you don't read documentation. Without it one has no idea what's going on, so one guess is as good as any another I suppose.

Originally Posted by Stik I believe pmount utilises pam for permissions.

Ah. That explains it.

Originally Posted by evilDagmar Troll much?

No.

Originally Posted by evilDagmar The machine's going to either stop the boot process because it can't read the list in fstab, or it's going to fail to mount some filesystems that it was probably supposed to.

But you said that fstab-sync was harmless?

Originally Posted by zborgerd But it sounds like a good reason to stop using the fstab entirely and replace it with a dynamic, automatic system that can keep track of devices and their mountpoints.

I'll believe HAL can do all that when I see it. If it can do all that right now, I tip my hat. Otherwise, you're talking vapour.

Originally Posted by rkelsen Ah. That explains it. No. But you said that fstab-sync was harmless?

It doesn't have anything to do with the system booting up, as you seem to believe. It has even less to do with the system booting up now that it's been deprecated. Before then it's only role during that cycle was to clear out stale entries that might otherwise cause the typical `mount -a` invocation to chatter a bit about mounting filesystems that might no longer be there. ...and no, I didn't say that "fstab-sync was harmless". What I've said and will continue to say is that most of your claims and concerns about it and HAL bear little relation to reality.

Ignorance breeds fear. Fear breeds hate. You are talking about technology you clearly know next to nothing about. I suggest you abandon this thread.

Originally Posted by rkelsen I'll believe HAL can do all that when I see it. If it can do all that right now, I tip my hat. Otherwise, you're talking vapour.

But I use it every day.

*shrugs*

Originally Posted by zborgerd But I use it every day.

Well, I'll have to try it again, won't I?

Last time I tried it (September last year), it sucked. Having used free software for many years, I can't believe that this project has come as far as you say it has in a few short months. As I said before, I'll give it another go one day. I am very happy with my current setup though.

Zborgerd, you've been avoiding my question:

Originally Posted by rkelsen Out of interest, where do you place the *BSDs? There are many thousand people worldwide who use them both at home and in business, yet a standard *BSD installation is far more "spartan" than Slackware.

I asked this question earlier in response to your concerns about where Slackware is headed.

Originally Posted by evilDagmar Fear breeds hate.

If anyone has posted anything spiteful here, it is you evilDagmar.

Originally Posted by rkelsen Originally Posted by evilDagmar Fear breeds hate. If anyone has posted anything spiteful here, it is you evilDagmar.

Okay, now I can definitely see that you don't troll much, if attempting to quote something out of context is the best you can do.

I will say again: Ignorance breeds fear, fear breeds contempt.

If we scroll up a bit we see...

Originally Posted by rkelsen Which is just as well, because it is a nasty hack IMO.

You're entitled to your opinion of course, but to call someone else's work, and particularly the outgrowths of Project Utopia a "nasty hack" is a bit uncalled for. For the most part, development on the software arising from that has proceeded at a lightning-fast pace, helped more than a little by the very concise device identification system that both PCI and USB use. What was originally a pile of shell scripts just to "make it go" and suss out any unforseen procedural problems has since become a rather elegant and powerful tool for dealing with hardware that's been working practically side by side with the kernel team working out the next-gen methods of device node enumeration.

Then we've got...

Originally Posted by rkelsen Getting HAL & DBUS working was the single most difficult thing I've ever had to do on any Linux machine. At the end of all the hoop jumping, I was left with a setup wihch would dangerously alter system files when a user did something as innocuous as inserting a USB stick.

You're using something akin to circular logic by referring to "dangerously alter[ing] system files" when in reality all that would normally happen (with previous versions) would be an entry in /etc/fstab so that mount may be called externally. You are the person who set those things up, so if they were doing anything "dangerously" it's you who are to blame.

I can understand where people who aren't yet familiar with the concepts of device abstraction in the new kernels would find dealing with HAL daunting, since it is also rather picky about udev being completely operational (and up to date), but rectifying that is simply a matter of familiarizing oneself with device abstractions and udev. This is the ignorance breeds fear problem in a nutshell. You don't like HAL and dbus because you don't fully understand what they're supposed to be doing. When you start talking about autofs in comparison, it becomes even more obvious that you're unclear about the purpose of HAL.

One of the more interesting things that the Project Utopia tools can do that autofs isn't likely to be able to accomplish anytime soon is mounting in different places based on the inserted media, rather than every cdrom going to /mnt/cdrom or every USB stick going to /mnt/media/usb. Mounting a USB stick to ~/thumbdrive is no real problem at all anymore, and if that's not enough extra power there's unique IDs attached to thumbdrives that can be hooked to make (if one is so inclined) a particular thumbdrive mount to ~/.gnupg, another one can go to ~/.evolution, and so forth. ...and I do mean specific removeable devices and/or media, not just whichever one was inserted/attached first.

Autofs has it's strengths, but those strengths are mainly centered around dealing with mounting remote filesystems from more than one (possibly downed) host. HAL/dbus's only interaction in that space would be to call various network mounting scripts when a new network device appears, and provides nice, clean interfaces for all the tasks related to what it's touched in the process.

Originally Posted by rkelsen So they deprecated fstab-sync and haven't replaced it with anything? This all sounds too complicated.

Ignorance breeds fear, fear breeds contempt.

Yes, there's a lot of new stuff to figure out, and most of it has moved almost terrifyingly fast in the last year, but Linux is finally getting some exposure to people interested in solving larger problems in a procedural fashion, i.e., it's getting "polish" instead of just tiny, isolated subsystem after tiny, isolated subsystem with all the ugly little redundancies those tend to entail. Abstraction layers like HAL and dbus are part of the solution. There's no more mucking about with having something half-in and half-out of kernel space, and no more messing with solutions for single tasks that span multiple facilities (like supermount-ng). HAL handles hardware appearances and hands off control messages to the relevant facilities (like udev and the messagebus). That's all it does. It makes sure that hardware events are made available to the rest of the system in a coherent manner. This API "flatness" gives it a well-defined scope of operation, and makes for nice clean transitions into userspace operations like the resulting mount of a cd-rom after a messagebus handler running on behalf of the logged-in user is told about a new optical disc being detected.

Sitting around decrying something you don't like because you don't yet know what it does is really not much better than sitting around in the dark because electricity is "scary" and lightning hurts people.

Wading through the documentation on that stuff, at least for system builders, is well worth the effort. I wouldn't recommend end-users bother. That's what system builders are for.

Originally Posted by rkelsen Zborgerd, you've been avoiding my question: Out of interest, where do you place the *BSDs? There are many thousand people worldwide who use them both at home and in business, yet a standard *BSD installation is far more "spartan" than Slackware.

I don't believe it is relevant to Slackware and usability. As such, I don't really have an opinion because I don't use BSD. However, you may find this interview with the FreeBSD developers of interest.

http://bsd.slashdot.org/article.pl?sid=06/05/13/0740227

Most of HAL's core is kernel independent. This is why there is work in progress to port it to BSD UNIX variants.

http://www.bsdunix.ch/s9y/index.php?...-Desktop!.html
http://lists.freedesktop.org/archive...ay/005087.html

I would say that it is as Scott Long indicates. Most of the core development comes from Linux developers. It would be a good time for FreeBSD to step in and get involved. Looks like they are already trying to implement it into FreeBSD Current.

So I installed Slackware-current (current as at 14th May 2006) on a spare partition, and upgraded udev to 0.92. Then I installed dbus-0.61 and hal-0.5.7 and pmount.

With minor hackage of some init scripts, I managed to get it all working without PAM. pmount can mount anything & everything from the CLI, and under KDE the "Whaddya wanna do?" dialogue pops up whenever a CD/DVD or USB device is inserted.

Now, I have some questions:

1. Is it possible to have CDs & DVDs auto unmount when I close their file browser window? Or maybe have them unmount when I press the eject button?

2. On another setup (running Slack 10.2), I have installed libgphoto which gives me access to the contents of my camera which uses the PTP protocol. This camera cannot be accessed as a storage device. It is detected by HAL when I plug it in (and the dialogue pops up in KDE), but when I try to browse its contents I get an error about an "unknown protocol." I tried installing libgphoto, but it still did the same thing. Does HAL integrate with libgphoto? Or is there a better method of accessing a PTP camera with HAL?

3. I'm getting errors with my LS-240 drive under the GUI. It mounts fine with pmount from the CLI, but under KDE I get an error about it being already mounted. I can browse to its auto-generated mount point and view its contents, but it shows up as unmounted in the KDE "storage media" folder. I have to open a console and use pumount to unmount it before I can eject it.

You guys were right. I've only been messing with HAL for a few hours, and it certainly has come a long way in a very short period of time. I am impressed.

I've tried searching the web for solutions to the above questions, but most of the documentation I found is obsolete. With all the various forum postings about HAL on the internet, there is a very low signal to noise ratio. I'm happy to be told to RTFM if someone could please point out where TFM is hiding.

Thanks in advance.

Originally Posted by rkelsen So I installed Slackware-current (current as at 14th May 2006) on a spare partition, and upgraded udev to 0.92. Then I installed dbus-0.61 and hal-0.5.7 and pmount. With minor hackage of some init scripts, I managed to get it all working without PAM. pmount can mount anything & everything from the CLI, and under KDE the "Whaddya wanna do?" dialogue pops up whenever a CD/DVD or USB device is inserted.

We aren't playing much with the new Udev releases right now. We're hanging on 0.75 for a while until we see where Slackware goes with it. The big change will be when Hotplug is totally depreciated and Udev is its replacement. I did experiment with newer Udev releases before we released DLG 2.14.1, but you may be better off using Udev 0.75 since that is the version that's required (bare minimum) for the latest HAL, and it doesn't require that you tweak Slackware too much more.

You can probably even install the Dropline or Freerock packs without actually installing any of the other stuff. I think that Dbus needs QT bindings of some sort for KDE though, and we don't build them in our pack because of the lack of QT on some systems. You may want to take a look at the scripts, as there are a few things that might also help in making things work a bit better. We've spent a lot of time in ironing out the issues.

We have some scripts up here, but they are for our functions-based build engine, but most of it should be easy to adapt to a SlackBuild. The SVN tree is a few weeks out of date, and I'll soon be updating it. it's kinda a work-in-progress at the moment, just to get Subversion online and to move off of Sourceforge.

http://svn.droplinegnome.org/

One thing to note is that Udev has a "firmware_helper" application now. I believe it is in the /extras/ subdirectory of the Udev source. This feature is not included in Slackware's udev.rules by default because Slackware uses Hotplug's loader instead. You probably only need to worry about it if you want to use HAL in combination with a system that has to use devices that need to load firmware on startup. There are a few ohter things that had to be worked around with Udev, to make HAL work on Slackware, but the scripts detail all of it.

It's very hard to do some of these things without PAM... At least on GNOME. I know that the Freerock developers have managed to get around the pam_console requirement in new gnome-volume-manager with some crafty patches. I'm not sure how it is on KDE though. It's good that you were able to make it work though.

Now, I have some questions: 1. Is it possible to have CDs & DVDs auto unmount when I close their file browser window? Or maybe have them unmount when I press the eject button?

It's possible, but the file browser thing would have to be programmed into KDE. I'm not too sure about HAL and KDE, since I've never actually used them together.

There has been talk on the HAL development lists about making the CDROM eject buttons actually unmount the disks and eject it. To be honest, I've not looked into it much, but I do think it would be a nice thing to have. I typically just use the right-click/eject function on the GNOME desktop. I haven't tried it any other way yet. I'll check it out.

2. On another setup (running Slack 10.2), I have installed libgphoto which gives me access to the contents of my camera which uses the PTP protocol. This camera cannot be accessed as a storage device. It is detected by HAL when I plug it in (and the dialogue pops up in KDE), but when I try to browse its contents I get an error about an "unknown protocol." I tried installing libgphoto, but it still did the same thing. Does HAL integrate with libgphoto? Or is there a better method of accessing a PTP camera with HAL?

This is a bit more difficult, unfortunately. We have this working on Dropline GNOME, but it does indeed utilize PAM to handle the permissions. I suspect that this could be a permissions issue. You may want to try to access the device as root to see if it works, or simply modify the permissions device.

Libgphoto uses a hotplug script in /etc/hotplug/usb/usbcam that utilizes a pam console.lock file to determine who is currently logged into the system. Without PAM, that lockfile doesn't exist. It sets the permissions on the device according to $CONSOLEOWNER. You may simply be able to modify the hotplug script though, with relaxed priveledges (since there is no way of doing this on a stock Slackware system without pam_console). You might want to see what the Freerock guys do to get around this. It should be trivial to modify the hotplug usbcam script to do this differently.

3. I'm getting errors with my LS-240 drive under the GUI. It mounts fine with pmount from the CLI, but under KDE I get an error about it being already mounted. I can browse to its auto-generated mount point and view its contents, but it shows up as unmounted in the KDE "storage media" folder. I have to open a console and use pumount to unmount it before I can eject it.

The new HAL release is a bit picky about anything that has an existing fstab entry and I haven't had the time yet to really examine why this is the case. It's kinda weird because it doesn't use fstab-sync anymore, but still checks to see if an fstab entry even exists. It will generally fail if one is there. I wonder if that's the case here? To be honest, with the removal of fstab-sync, HAL is doing things quite a bit different now than it did last fall, when we released DLG 2.12.x. Users with existing fstab entries often get an error: "You do not have permission to mount this device" or something to that effect on GNOME systems with gnome-mount. Unfortunately, I have no experience with KDE, so I'm not sure if it says the same sort of thing, but I would imagine that HAL behaves the same way in either case.

You guys were right. I've only been messing with HAL for a few hours, and it certainly has come a long way in a very short period of time. I am impressed. I've tried searching the web for solutions to the above questions, but most of the documentation I found is obsolete. With all the various forum postings about HAL on the internet, there is a very low signal to noise ratio. I'm happy to be told to RTFM if someone could please point out where TFM is hiding. Thanks in advance.

It still has some quirks, but we've knocked pretty much all of them out for GNOME on Slackware. I really wish that I could offer some assistance on making this stuff operate on KDE. Feel free to use the Dropline forums to see if other users have tried this. Be sure to mention that I suggest that you ask there, so that some folks don't say "this is a GNOME forum!" if you decide to go there for answers. I do know that some folks were talking about making this work on KDE a while back. Maybe I'll see if I can dig some info up as well. I think it would be beneficial to have this information available for KDE users on Slackware.

Originally Posted by zborgerd You can probably even install the Dropline or Freerock packs without actually installing any of the other stuff.

Good idea. I might just grab your udev package. Does it have any dependancies which I need to be aware of?

Originally Posted by zborgerd You may want to take a look at the scripts, as there are a few things that might also help in making things work a bit better. We've spent a lot of time in ironing out the issues.

I'll have a look at your scripts. Thanks.

Originally Posted by zborgerd This feature is not included in Slackware's udev.rules by default because Slackware uses Hotplug's loader instead.

So once this is all working properly, will it be safe to remove the hotplug package?

Originally Posted by zborgerd I typically just use the right-click/eject function on the GNOME desktop.

I just found out how to get the device icons to show on the KDE desktop. I'll test it when I get home. The right-click/eject thingy isn't too bad. Without the device icon on the desktop though, you have to go hunting thru the storage media folder. If the icon appears on the desktop, then it will be more usable IMO.

Originally Posted by zborgerd I suspect that this could be a permissions issue.

I'll try running KDE as root and see what happens when I plug the camera in.

Originally Posted by zborgerd You might want to see what the Freerock guys do to get around this.

Thanks for the tip! I'll have to look into that as well.

Originally Posted by zborgerd The new HAL release is a bit picky about anything that has an existing fstab entry and I haven't had the time yet to really examine why this is the case.

This one's a head scratcher because I made sure that I deleted all the removable media references from the fstab file.

Originally Posted by zborgerd I really wish that I could offer some assistance on making this stuff operate on KDE.

For the most part, it is working. I'll mess around with it some more tonight. Thanks for all of your suggestions above.

Originally Posted by zborgerd Feel free to use the Dropline forums to see if other users have tried this.

Thanks. I will do that if I can't figure it all out.

Once I have it working properly I'll post up a web page with all the fine details. It wasn't really difficult to get everything to this point.

Thanks for all your help.

Rkelsen (or anybody, really), did you have to modify any files relating to pmount or hal to get pmount to automatically mount devices on insertion? I have the setup working with fstab-sync, and I can use pmount just fine from the CLI, but it doesn't seem to want to work automatically for me.

I'm using KDE, with udev 071, dbus 0.50, hal 0.5.4, and pmount 0.9.7. Udev is from slack-current, pmount is home-built, and dbus and hal are from Freerock.

Far as I know, kde and friends needs rebuilt with hal/dbus support to use this
functionality.. Which parts of kde I don't know because I have no desire to have
it even installed on my system. Tried khal and kdbus? hahaha... j/k

Originally Posted by rkelsen Good idea. I might just grab your udev package. Does it have any dependancies which I need to be aware of?

I don't believe so. It should be a drop-in replacement. You may want to be aware that the doinst.sh will "chmod -x" the hotplug firmware agent so that it doesn't interfere with udev's. It also backs up the udev.rules file as well because it needs one with the firmware loader (otherwise, it's identical to the one in current). We polled the users on this and they seemed to be okay with this in order for things to "just work" so that HAL could be used without requiring the users to monitor a bunch of scripts. Please examine the package though and be sure that that's okay before you install it though.

http://prdownloads.sourceforge.net/d...l.tgz?download

So once this is all working properly, will it be safe to remove the hotplug package?

I don't believe that it's a good time to do that just yet. Slackware 10.2 was built with the intention that hotplug is installed. It's something that I've experimented with a bit on some systems, but I believe we're all of the opinion that it's a good idea to wait until Pat makes that call. The current Udev/Hotplug combo works quite well for everything so far, aside from meeting the needs of HAL. Piter Punk has done a lot of work on assisting Pat on some of these things:

http://piterpunk.info02.com.br/extra/

The way I've understood it is that some versions of Udev before 0.80 still require Hotplug for several things. I may be wrong though. Slackware Current has Udev 0.71 I believe for these reasons. We found that 0.75 was safe though, and was compatible with HAL according to the documentation (though, in my experience, 0.71 works just fine with HAL).

I just found out how to get the device icons to show on the KDE desktop. I'll test it when I get home. The right-click/eject thingy isn't too bad. Without the device icon on the desktop though, you have to go hunting thru the storage media folder. If the icon appears on the desktop, then it will be more usable IMO.

I just tested GNOME's HAL support in regards to using the drive's own eject button. It appears I can have a CDROM or DVD automounted, and pressing the physical eject button on the DVD drive causes it to send the eject command. I forgot that I had tested this previously and found that it actually works as of the latest HAL releases (as long as there are no active Nautilus windows open and browsing the device).

You can actually see what it's doing though by monitoring it like this:

root@katana:~# dbus-monitor --system
signal sender=org.freedesktop.DBus -> dest=:1.31 interface=org.freedesktop.DBus; member=NameAcquired
 string ":1.31"
signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Device; member=Condition
 string "EjectPressed"
string ""
signal sender=org.freedesktop.DBus -> dest=(null destination) interface=org.freedesktop.DBus; member=NameOwnerChanged
 string ":1.32"
string ""
string ":1.32"
signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Device; member=PropertyModified
 int32 2
[ (dbus-monitor too dumb to decipher arg type 'r')
 (dbus-monitor too dumb to decipher arg type 'r')
]signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Device; member=PropertyModified
 int32 1
[ (dbus-monitor too dumb to decipher arg type 'r')
]signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Device; member=PropertyModified
 int32 1
[ (dbus-monitor too dumb to decipher arg type 'r')
]signal sender=org.freedesktop.DBus -> dest=(null destination) interface=org.freedesktop.DBus; member=NameOwnerChanged
 string ":1.32"
string ":1.32"
string ""
signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Manager; member=DeviceRemoved
 string "/org/freedesktop/Hal/devices/volume_label_Slk102d1"

There is a string above where a signal "EjectPressed" is sent on the messagebus. Then, you can see "DeviceRemoved" and the volume label for the disk. In this case, I used Slackware 10.2 Disk 1.

One difference between your install and mine is that GNOME systems have gnome-volume-manager and gnome-mount. We don't use pmount on DLG, so I don't know how it might act differently than gnome-mount. The pmount-HAL wrapper is supposed to help with the interaction with HAL though.

I can spy on the gnome-volume-manager with --daemon=no option, and I see this when I mount a CD.

manager.c/2261: Device added: /org/freedesktop/Hal/devices/volume_label_Slk102d1
manager.c/2074: Changed: /dev/hdc
manager.c/1565: mounting /org/freedesktop/Hal/devices/volume_label_Slk102d1...
manager.c/777: executing command: /usr/bin/gnome-mount --hal-udi=/org/freedesktop/Hal/devices/volume_label_Slk102d1
gnome-mount 0.4
manager.c/2354: Mounted: /org/freedesktop/Hal/devices/volume_label_Slk102d1
manager.c/777: executing command: /usr/bin/nautilus -n --no-desktop '/media/Slk102d1'

It invokes the gnome-mount command which tells HAL to do it's thing. Gnome-mount is kinda a replacement for the actual mount, umount, and eject commands on GNOME systems. I believe that Ubuntu doesn't use this right now though, opting for pmount instead (which is supposed to be able to interact with HAL the same way)... So it should be okay, but I don't have personal experience with it. Either way, these tools are intended to do the work without having the fstab entries for the devices, making mountpoint naming completely dynamic (by volume label).

When I press the eject button on the fron to the drive:

manager.c/2442: ejecting /org/freedesktop/Hal/devices/volume_label_Slk102d1...
manager.c/777: executing command: /usr/bin/gnome-mount --eject --hal-udi=/org/freedesktop/Hal/devices/volume_label_Slk102d1
gnome-mount 0.4
manager.c/2380: Unmounted: /org/freedesktop/Hal/devices/volume_label_Slk102d1
manager.c/2298: Device removed: /org/freedesktop/Hal/devices/volume_label_Slk102d1

So, the key here, at least on a GNOME system, is having gnome-mount to tell HAL to do its thing. It passes the --eject command along with the HAL udi for the device.

I'll try running KDE as root and see what happens when I plug the camera in. Thanks for the tip! I'll have to look into that as well.

Cool. Looks like the sf.net SVN viewer is down right now. I was going to take a look at the Freerock libgphoto stuff what they have for the hotplug usb events in place of the PAM console.lock stuff.

This might help. I found a LQ.org thread where Shepper talks about how he does it without PAM:

http://www.linuxquestions.org/questi...52#post1731052

My Panasonic DMC-LZ2 camera does this when I plug it in in PTP mode:

root@katana:~# dbus-monitor --system
signal sender=org.freedesktop.DBus -> dest=:1.41 interface=org.freedesktop.DBus; member=NameAcquired
 string ":1.41"
signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Manager; member=DeviceAdded
 string "/org/freedesktop/Hal/devices/usb_device_4da_2374_noserial"
signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Manager; member=DeviceAdded
 string "/org/freedesktop/Hal/devices/usb_device_4da_2374_noserial_if0"
signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Manager; member=DeviceAdded
 string "/org/freedesktop/Hal/devices/usb_device_4da_2374_noserial_usbraw"

And when I monitor gnome-volume-manager:

manager.c/2261: Device added: /org/freedesktop/Hal/devices/usb_device_4da_2374_noserial
manager.c/2261: Device added: /org/freedesktop/Hal/devices/usb_device_4da_2374_noserial_if0
manager.c/2261: Device added: /org/freedesktop/Hal/devices/usb_device_4da_2374_noserial_usbraw
manager.c/777: executing command: gthumb --import-photos

This one's a head scratcher because I made sure that I deleted all the removable media references from the fstab file. For the most part, it is working. I'll mess around with it some more tonight. Thanks for all of your suggestions above.

I wish I knew what to suggest. You can try to monitor what HAL's doing by spying on the messagebus with "dbus-monitor --system" as shown above. It's a really excellent tool when trying to examine how this stuff works.

Once I have it working properly I'll post up a web page with all the fine details. It wasn't really difficult to get everything to this point. Thanks for all your help.

That's awesome. The more resources the better.

Originally Posted by quip Rkelsen (or anybody, really), did you have to modify any files relating to pmount or hal to get pmount to automatically mount devices on insertion? I have the setup working with fstab-sync, and I can use pmount just fine from the CLI, but it doesn't seem to want to work automatically for me. I'm using KDE, with udev 071, dbus 0.50, hal 0.5.4, and pmount 0.9.7. Udev is from slack-current, pmount is home-built, and dbus and hal are from Freerock.

Well, the thing about HAL is that its primary functionality is that it is largely just something that keeps track of the devices. It requires that some outside source send it some commands to mount the media once it's detected. Otherwise, it's just kinda in limbo on its own.

As shown above, GNOME systems use gnome-volume-manager to tell gnome-mount to pass the information to HAL. Pmount is supposet to be able to do the same thing, but I'd imagine that it need a HAL-capable daemon to watch for these events and tell it to do the mounting (as gnome-volume-manager does).

With just a quick glance at Google, there appear to be some resources on doing this on KDE:

http://www.mail-archive.com/blfs-dev.../msg04918.html
http://www.mayrhofer.eu.org/Default....ex=7&pageid=27

This one looks rather useful, straight from the KDE wiki. Note the Slackware specifics at the bottom:

http://wiki.kde.org/tiki-index.php?page=DBUS