Basically I'm having a carbon-copy of the Mandriva bug in the URL. When mounting gnome-mount, about 95% of the time it does not mount and I get a dialog that says "isCallerPrivilege() failed". This happens within nautilus or using gnome-mount from the command line. If/when this happens restarting hald consistently resolves the issue. I've tried with/without rc_parallel in /etc/rc.conf. Setting parallel to NO seems to help but it still occurs. I am running with the following: hal-0.5.14 udev-149 dbus-1.3.0-r1 consolekit-0.4.1 polkit-0.95 policykit-0.9-r1 gnome-mount-0.8-r1 policykit-gnome-0.9.2-r1 polkit-gnome-0.95 Also, it seems not to be an issue, for the root user, only for other uses (even users in the wheel group). Debug for gnome-mount: $ gnome-mount -b -d /dev/sdb1 --verbose ** (gnome-mount:3193): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_8576_8DC2 ** (gnome-mount:3193): DEBUG: read default option 'shortname=lower' from gconf strlist key /system/storage/default_options/vfat/mount_options ** (gnome-mount:3193): DEBUG: read default option 'flush' from gconf strlist key /system/storage/default_options/vfat/mount_options ** (gnome-mount:3193): DEBUG: read default option 'noatime' from gconf strlist key /system/storage/default_options/vfat/mount_options ** (gnome-mount:3193): DEBUG: read default option 'uid=' from gconf strlist key /system/storage/default_options/vfat/mount_options ** (gnome-mount:3193): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_8576_8DC2 with mount_point='TRAVELDRIVE', fstype='', num_options=4 ** (gnome-mount:3193): DEBUG: option='shortname=lower' ** (gnome-mount:3193): DEBUG: option='flush' ** (gnome-mount:3193): DEBUG: option='noatime' ** (gnome-mount:3193): DEBUG: option='uid=1010' ** Message: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_8576_8DC2 org.freedesktop.Hal.Device.Volume.UnknownFailure : IsCallerPrivileged() failed Also it seems not to matter whether using a USB stick, USB HD, or optical media and the filesytem doesn't seem to matter either (tried vfat, ext4, and iso9660).
Created attachment 212429 [details] emerge --info
As you are in unstable, try DeviceKit-disks and its frontend, gnome-disk-utility instead.
(In reply to comment #2) > As you are in unstable, try DeviceKit-disks > and its frontend, gnome-disk-utility instead. The tools that I use dont' really utilize those technologies. I'd rather see this issue resolved as it is supposed to work.
I've not tested this myself, but it seems that according to hal mailing list, hal-0.5.14 could have some problems with usb. Could you downgrade hal to 0.5.13 and test again ?
(In reply to comment #4) Hi Gilles. Thanks for your response. I did downgrade to hal-0.5.13-r2, but after rebooting I still goet the isCallerPriviliged() error. I then tried to downgrade to hal-0.5.12_rc1-r8, but when it was installing the configure script complained that I did not have “libvolume_id” installed, which is apparently only keyworded for FreeBSD (I'm running Linux). Also, this issue does not only occur with USB devices. I also get the error when inserting a CDROM into my SATA CD drive. So it appears to occur with multiple external media regardless of the bus type. I'm guessing it's some kind of race condition, as something is not started/configured correctly by the time hald is started, and when hald is restartd it works. I did an strace of gnome-mount when the isCallerPrivileged occurred. I then restarted hald and did an strace of gnome-mount when it succeeded. I will attach to this bz.
Created attachment 212582 [details] gnome-mount diff I'm attaching a screenshot from meld as apposed to a diff because I think it illustrates the important differences better. Most of the differences are different offsets/addreses, until you get about halfway down the diff. In the failed instance, the trace shows that it creates a connection to a dbus socket. It does some sending/receiving before eventually it gets an EAGAIN. In the second (successful) instance, instead of connecting to a dbus socket it connects to /tmp/.X11-unix/X0 socket and the communication on that socket is different (shorter). This may be an interesting clue. Nevertheless I will try this sans X (I think you can use gnome-mount w/o X) and report what happens.
I get the same behavior using gnome-mount w/o X. I looked around and found some interesting differences with dbus, but I don't understand what's going on enough to make any conclusions.
I got same error from hal, but in kde. So this problem is hal-related, not DE.
(In reply to comment #8) > I got same error from hal, but in kde. So this problem is hal-related, not DE. > Does the issue also resove itself when/if you restart hald?
> Does the issue also resove itself when/if you restart hald? > Yep, it disappears after hald restart.
One additional piece of info: When I got this error, then did a "sudo gnome-mount ..." and of course that was successfull. However when I wanted to unmount it I accidentally typed "umount ..." instead of "sudo umount", and then I got a core dump and a call trace. Apparently umount calls /sbin/umount.hal and this process crashed. I then re-built hal, dbus, gcc, and glibc with debug symbols enabled and rebooted. But as Murphy would have it after the reboot gnome-mount did not produce an error :|... Frustrating. Anyway I will attach debug info if/when this re-occurs.
Created attachment 213046 [details] umount.hal backtrace With debug on didn't really provide any extra info. I'm attaching the back trace that spits out via stderr. I'm not sure if this is even related to the original issue, but I guess too much information is better than not enough.
(In reply to comment #0) > Basically I'm having a carbon-copy of the Mandriva bug in the URL. When > mounting gnome-mount, about 95% of the time it does not mount and I get a > dialog that says "isCallerPrivilege() failed". This happens within nautilus or > using gnome-mount from the command line. If/when this happens restarting hald > consistently resolves the issue. I've tried with/without rc_parallel in > /etc/rc.conf. Setting parallel to NO seems to help but it still occurs. I am > running with the following: > > hal-0.5.14 > udev-149 > dbus-1.3.0-r1 > consolekit-0.4.1 > polkit-0.95 > policykit-0.9-r1 > gnome-mount-0.8-r1 > policykit-gnome-0.9.2-r1 > polkit-gnome-0.95 > > > Also, it seems not to be an issue, for the root user, only for other uses (even > users in the wheel group). > > Debug for gnome-mount: > > $ gnome-mount -b -d /dev/sdb1 --verbose > ** (gnome-mount:3193): DEBUG: Mounting > /org/freedesktop/Hal/devices/volume_uuid_8576_8DC2 > ** (gnome-mount:3193): DEBUG: read default option 'shortname=lower' from gconf > strlist key /system/storage/default_options/vfat/mount_options > ** (gnome-mount:3193): DEBUG: read default option 'flush' from gconf strlist > key /system/storage/default_options/vfat/mount_options > ** (gnome-mount:3193): DEBUG: read default option 'noatime' from gconf strlist > key /system/storage/default_options/vfat/mount_options > ** (gnome-mount:3193): DEBUG: read default option 'uid=' from gconf strlist key > /system/storage/default_options/vfat/mount_options > ** (gnome-mount:3193): DEBUG: Mounting > /org/freedesktop/Hal/devices/volume_uuid_8576_8DC2 with > mount_point='TRAVELDRIVE', fstype='', num_options=4 > ** (gnome-mount:3193): DEBUG: option='shortname=lower' > ** (gnome-mount:3193): DEBUG: option='flush' > ** (gnome-mount:3193): DEBUG: option='noatime' > ** (gnome-mount:3193): DEBUG: option='uid=1010' > ** Message: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_8576_8DC2 > org.freedesktop.Hal.Device.Volume.UnknownFailure : IsCallerPrivileged() failed > > Also it seems not to matter whether using a USB stick, USB HD, or optical media > and the filesytem doesn't seem to matter either (tried vfat, ext4, and > iso9660). > I have exactly the same problem. USB/CDROM, everything gnome-mount tried to mount failed with "iscallerprivilege() failed"
FYI, 2 things: #1 This seems to only apply to storage media (usb drives, cdroms, etc.). I hot-plugged such USB devices as digital cameras (not using usb-storage), webcams, and usb headsets and they all worked fine. #2 The Mandriva BZ appears to have a fix. I haven't seen yet how they fixed it, but it appeared to have been a problem with consolekit. I'll try to take a look at their update when I can.
Back, I looked at the spec file from Mandriva's consolekit-0.4.1.2mdv2010.1. They applied 2 patches to main.c: # (blino) acquire name only after D-Bus methods are registered # or "activation" from clients will fail since D-Bus assumes # the service and methods are available as soon as the name is # acquired Patch2: ConsoleKit-0.4.1-acquire_later.patch # (blino) daemonize only after ConsoleKit is available # or "activation" from clients will fail since D-Bus requires # the service name to be acquired before the daemon helper exits Patch3: ConsoleKit-0.4.1-daemonize_later.patch (Patch1 appears to have been applied earlier for a different reason). Will attach their patches momentarily.
Created attachment 213426 [details, diff] First Mandriva patch wrt Mandriva bug #54804
Created attachment 213428 [details, diff] Second Mandriva patch wrt Mandriva bug #54804
Disregard the patches. I think I pulled them from the wrong update. Nevertheless, they don't work. I'll wait until I see an update in the Mandriva BZ.
Try to add ConsoleKit to the default run-level: # rc-update add consolekit default
(In reply to comment #18) > Disregard the patches. I think I pulled them from the wrong update. > Nevertheless, they don't work. I'll wait until I see an update in the Mandriva > BZ. > For me, simply /etc/init.d/hald restart solved the problem. Only one time restart needed...
(In reply to comment #19) > Try to add ConsoleKit to the default run-level: > > # rc-update add consolekit default > For me consolekit is already set at the default runlevel. It's already running. that's not the problem.
> For me consolekit is already set at the default runlevel. It's already > running. that's not the problem. I'm sorry, this solved the bug for me with KDE but then it is probably a coincidence.
Ok, here is some info. Mandriva finally released their updated .rpms. In their updated package they have 3 relatively small patches. The patches seem to introduce some delays in the console-kit-daemon to work around a race condition. I took the patches they applied cleantly under Gentoo. Ok that was the good news. The bad news is that the patches did not seem to work, at least not for me. When I tried the patched console-kit-daemon I enountered 2 issues. 1. The delay patches seem to "confuse" Gentoo's init process. rc-status will show that the consolekit service has crashed, even though console-kit-daemon is running. 2. In spite of, or perhaps because of, the former, mounting external media still fails but this time it fails silently (i.e. without the isCallerPrivileged() error. So this is much worse than the former. And I somehow don't think this is the "correct" fix. However, I do have some kinda good news. It appears to be a race condition and hald needs to be re-started because something wasn't initialized (correctly) when it was started the first time. Using this information and the fact that it has something to do with consolekit, I looked at the consolekit and hald init scripts. hald has "use" for consolekit, but consolekit only has "need" for dbus. So, not knowing exactly what I'm doing, I added the following to the consolekit init script in the depend function: before hald I figured this would at least give consolekit more time to initialize before hald is started. Note you set rc_parallel to no in /etc/rc.conf. I made this change and rebooted 5 times and was able to mount my external drive on the first try for 4 out the 5 times (as opposed to 1 out of 10 before). So you may want to try this and report back your findings as well. HTH p.s. wrt comment #20 yes, you only need to restart hald once and it works fine, but for me that means I need to restart hald nearly every time I reboot my machine (which also disconnects me from the network and kills my X server). So while I agree that is an effective workaround, nevertheless it is a workaround ant not a fix.
*** Bug 301860 has been marked as a duplicate of this bug. ***
oh I didn't realize sooner that there's policykit involved here. The problem is most likely that hal is speaking to policykit-0.9 while consolekit-0.4 only knows about >=polkit-0.90 (not the difference in package name). The design of these two policykit are totally different so I wouldn't expect any interaction of the two to work at all. Please try to figure out what's pulling policykit-0.9 in your setup (hal useflag maybe ?) and drop that. It should make gnome-mount work again. Otherwise, you might want to stick with consolekit-0.3. @nirbheek, dang, could you guys confirm that I'm not saying anything stupid ?
At the moment, this appears to include at least nm-applet, which unconditionally requires it (by way of policykit-gnome). Qgrep also shows libvirt, hplip and blueman (unconditional again via policykit-gnome) as the main remaining offenders. Can we do anything about these, potentially turn this into a tracker, etc?
I require policykit as they are non-optional dependencies of NetworkManager. It's also a dependency of libvirt, though it's not working with the latest (per bug #291008).
Ok but what about your hal/consolekit setup ? Did you try disabling policykit support on say hal ?
Is this still an issue with hal-0.5.14-r2? It needs consolekit, rather than using consolekit. I suspect this was the issue requiring restarting hal. FTR, policykit works fine with consolekit 0.4 for finding at-console, so that shouldn't be an issue. I have policykit and polkit and consolekit-0.4.1 and automount of everything works fine.
No, unfortunately hal-0.5.14-r2 didn't solve the problem (even when I manually added "before hald" in consolekit). It wasn't every time, but I was still finding about half of my reboots failed to allow mounting through gnome-mount (which is what I was finding before the hal version bump). I've since removed policykit (and recompiled hal without policykit support) and am trying to clean up the packages that still depend on it (I'm testing out networkmanager-0.7.999 and libvirt was incorrectly depending on it too) and so far it's been fine. I'm looking forward to being able to drop hal at some point, now that everything seems to be moving towards devicekit/gudev/udisks...
I had the same issue. Trying to put RC_AFTER="consolekit" into /etc/conf.d/hald doesn't help. Then i tried rc-update add consolekit boot and now it works perfekt.
Adding consolekit to boot runlevel works for me too
(In reply to comment #32) > Adding consolekit to boot runlevel works for me too Ditto for me.
(In reply to comment #31) > I had the same issue. > Trying to put RC_AFTER="consolekit" into /etc/conf.d/hald doesn't help. > Then i tried rc-update add consolekit boot > and now it works perfekt. > Currently I am using this workaround as well, and haven't found any problems. But sorry for my stupid question: is it safe to put consolekit in boot level? Thanks.
(In reply to comment #31) > I had the same issue. > Trying to put RC_AFTER="consolekit" into /etc/conf.d/hald doesn't help. > Then i tried rc-update add consolekit boot > and now it works perfekt. > Seems to be working, but does anyone know _why_ this fixes it?
When I changed consolekit service from default to boot runlevel it started to work again here also.
> When I changed consolekit service from default to boot runlevel > it started to work again here also. ditto
*** Bug 317737 has been marked as a duplicate of this bug. ***
The following solves the bug for me: - remove consolekit from your runlevel, - remove the dependency ("need consolekit") from /etc/init.d/hald and any other scripts. Now dbus will autostart consolekit, as can be seen from /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service. I think the bug occurs because gentoo's manual launching of consolekit conflicts with dbus's, which appears to be the way the developers intended the daemon be launched.
I no longer use this crap. Unless anyone objects. I, the initiator, would like to close this bug. If you disagree please respond within 3 days.
I voted for this bug because comment #39 is very interesting and deserves to be addressed, but I guess that's off topic. Could the consolekit stuff be split out into a new bug?
Also note that two KDE bugs (#317737 and #301860) have been marked duplicates of this one - perhaps this bug should be renamed if the original gnome-mount issue is outdated/irrelevant.
sys-apps/hal doesn't use consolekit or policykit anymore, so at_console or plugdev group is required gnome-mount is now only for keyworded for ~x86-fbsd and command for gnome-base/gvfs[hal] linux has gvfs-mount (gvfs with USE="gdu udev") or plain udisks --mount
