Description of problem: When I connect my usb camera hald doesn't even seem to notice it, and thus it doesn't get mounted. Version-Release number of selected component (if applicable): Todays Rawhide of everything relevant, including: hal-0.5.6-3.1 dbus-0.60-7.1 How reproducible: 100% Steps to Reproduce: 1. Connect the camera 2. 3. Actual results: nothing Expected results: It should get mounted. Additional info: If I start hald without the camera connected I get this output: [#] hald --daemon=no --retain-privileges ERROR: Could initialize HAL daemon: (null) missing x or y absolute axes missing x or y relative axes missing x or y absolute axes ************************************************** ************************************************** Doing addon-storage for /dev/hdb (bus ide) (drive_type cdrom) (udi /org/freedesktop/Hal/devices/storage_serial_4VO3131DE08288) ************************************************** ************************************************** ...and then nothing happens when I connect it. If the camera is connected when I start hald it looks like this: [#] hald --daemon=no --retain-privileges ERROR: Could initialize HAL daemon: (null) missing x or y absolute axes missing x or y relative axes missing x or y absolute axes ************************************************** ************************************************** Doing addon-storage for /dev/sda (bus usb) (drive_type disk) (udi /org/freedesktop/Hal/devices/storage_model_USB_DRIVEUNIT) ************************************************** ************************************************** ************************************************** ************************************************** Doing addon-storage for /dev/hdb (bus ide) (drive_type cdrom) (udi /org/freedesktop/Hal/devices/storage_serial_4VO3131DE08288) ************************************************** ************************************************** ...and then it's also visible in lshal (even after being disconnected). I get the feeling that this might be something with dbus?
Some additional information: I've now tried some more usb mass storage devices, and also tried on another computer (also running latest Rawhide) with the exact same result. When I plug the device the /dev stuff is created as it should, and after a manual mount everything works perfectly fine, but hal doesn't seem to notice anything... I also noticed that hal-device-manager takes exceptionally long to start (about a minute) so I did a strace. I noticed that it stops for quite long at the following place (I've really got no idea if this is even remotely relevant, or how many rows to copy): ---snip--- futex(0xa03cae8, FUTEX_WAKE, 1) = 0 futex(0xa03cae8, FUTEX_WAKE, 1) = 0 getcwd("/root", 1024) = 6 futex(0xa03cae8, FUTEX_WAKE, 1) = 0 futex(0xa03cae8, FUTEX_WAKE, 1) = 0 futex(0xa03cae8, FUTEX_WAKE, 1) = 0 gettimeofday({1139928893, 709653}, NULL) = 0 writev(14, [{"l\1\0\1\30\0\0\0\n\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org"..., 144}, {"\23\0\0\0org.freedesktop.Hal\0", 24}], 2) = 168 gettimeofday({1139928893, 710696}, NULL) = 0 poll([{fd=14, events=POLLIN, revents=POLLIN}], 1, 25000) = 1 read(14, "l\2\1\1\n\0\0\0\n\0\0\0=\0\0\0\6\1s\0\5\0\0\0:1.19\0\0"..., 2048) = 90 read(14, 0xa2e3df0, 2048) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1139928893, 711739}, NULL) = 0 writev(14, [{"l\1\0\1\204\0\0\0\v\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/or"..., 144}, {"\177\0\0\0type=\'signal\',interface=\'org"..., 132}], 2) = 276 gettimeofday({1139928893, 712866}, NULL) = 0 poll([{fd=14, events=POLLIN, revents=POLLIN}], 1, 25000) = 1 read(14, "l\2\1\1\0\0\0\0\v\0\0\0005\0\0\0\6\1s\0\5\0\0\0:1.19\0"..., 2048) = 72 read(14, 0xa2e3df0, 2048) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1139928893, 713447}, NULL) = 0 poll( ---snip---
It seems, that fstab-sync must be revived. In previous versions all actions on filling /etc/fstab be make by this program.
fstab-sync is no longer used. Please follow the steps outlined at http://www.freedesktop.org/wiki/Software_2fHalTraces so we can better diagnose what the issue is.
Created attachment 124879 [details] traces, information, etc Ok, loads of information in the attachted text file. The really strange thing is that now really something happens when I insert device (it didn't when I tried last week). Anyhow, it doesn't get mounted anywhere.
Are you running gnome-volume-manager?
Hmmm... Now that you mention it, no, it doesn't seem to be running. Starting it made things work again on this computer. I guess two questions remain: 1. Where is gvm normally started? Why wasn't it started here? 2. On the other computer on which I tested really _nothing_ happened with hal when inserting a device, so I guess it isn't the same fault there. I guess I'll just try again after a yum update (when I get access to that machine, won't be this week). (Hmmm... That wasn't really a question, was it? ;-)
It is started by gnome-session when you log in.
Tested on KDE 3.5.1 -- works. But: 1. What to do without KDE, Gnome ... from console-only? 2. It mounts devices automaticaly from root, and user have no chance to unmount it by hand. 3. Control of mount options is unclean. It may be useful to modify mount, that it will look not only to /etc/fstab, but to /etc/fstab.dyn. And something fstab-sync-alike will modify /etc/fstab.dyn. (not to touch and potentialy destroy main fstab).
Anton, That is something to talk about upstream but we went down that road with the mount developers during the fstab-sync days and they were totaly against it. You can mount at the console using gnome-mount. One thing to note (and I don't want to get in an debate about this here, but just to inform you) these technologies are being developed with the desktop in mind and you will have to expect in the future the console will be second class when it comes to HAL. This doesn't mean we are taking things away from the console it just means the new flashy things may be just DE only features. The fstab-sync allowing console only users to mount was a side effect. However fstab-sync was limited, expecially in terms of access controls. If someone wants to take a look at those issues and help solve them then I encourage them to join the HAL mailing lists and submit patches.
Things seem to work fine for me now on the machines where I had problems. Closing up.