Summary: | GVFS mounting broken after recent update (shadow/consolekit/polkit related) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthew Turnbull <sparky> |
Component: | Current packages | Assignee: | Freedesktop bugs <freedesktop-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
GDU polkit strace output
Nautilus polkit strace output |
Description
Matthew Turnbull
2010-10-29 14:54:55 UTC
Created attachment 252485 [details]
GDU polkit strace output
Created attachment 252487 [details]
Nautilus polkit strace output
Is gnome-extra/polkit-gnome installed? And does running '/usr/libexec/polkit-gnome-authentication-agent-1' by hand help? Assuming autostart from polkit-gnome-authentication-agent-1.desktop didn't kick in for some reason. Yes, I have polkit-gnome installed, and polkit-gnome-authentication-agent-1 is running. $ pkcheck --action-id org.freedesktop.udisks.filesystem-mount --process $(pgrep nautilus) $ echo $? 0 $ pkcheck --action-id org.freedesktop.udisks.filesystem-mount-system-internal --process $(pgrep nautilus) --allow-user-interaction polkit\56temporary_authorization_id=tmpauthz0 $ echo $? 0 $ killall polkit-gnome-authentication-agent-1 $ pkcheck --action-id org.freedesktop.udisks.filesystem-mount-system-internal --process $(pgrep nautilus) --allow-user-interaction polkit\56retains_authorization_after_challenge=1 Authorization requires authentication but no agent is available. $ echo $? 2 Killing polkit-gnome-authentication-agent-1 and manually running it has no affect. Don't know then, only seen 'Not authorized.' when polkit-gnome is missing with gvfs. Unusure where to even begin without reproducing it first, sorry. Ok, bit of an update: Per chance, I stumbled across an awesome little DBUS explorer called DFeet ( http://live.gnome.org/DFeet/ ). From nautilus.polkit.out: write(1, "** (process:3628): DEBUG: checking whether system-bus-name::1.16 is authorized for org.freedesktop.udisks.filesystem-mount\n", 123) = 123 system-bus 1.16 refers to /usr/libexec/gvfs-gdu-volume-monitor. Sure enough, all of the GVFS daemons have the XDG_SESSION_COOKIE of the inactive TTY1 consolekit session. If I restart gvfs-gdu-volume-monitor, it replaces the existing process, inherits the correct XDG_SESSION_COOKIE, and mounting works again. I'm guessing that this also goes back to the shadow update, with there now being 2 consolekit sessions, rather than 1. Though when I tried downgrading shadow it didn't help. But I may have missed something so I'll try that again. So, I guess the question now is what's actually spawning the GVFS daemons ans why are they receiving the old XDG_SESSION_COOKIE. How are you starting Gnome? I remember you had some weird symlink in bug 343033, that's not the case now, is it? Heh, that's an interesting question. I'm basically using gnome-light, but with xfce4-session and xfce4-panel instead of gnome-session and gnome-panel (thus avoiding a bunch of depreciated GNOME packages and upower) The link wasn't all that weird. Instead of using XSESSION="Xfce4" (which ultimately calls startxfce4) or startxfce4 (which just calls /etc/xdg/xfce4/xinitrc), I directly called /etc/xdg/xfce4/xinitrc. It was the xinitrc file that was broken, not my use of it. Regardless, my ~.xinitrc is now: #!/bin/sh command="xfce4-session" if [ -d /etc/X11/xinit/xinitrc.d ] ; then for f in /etc/X11/xinit/xinitrc.d/* ; do [ -x "$f" ] && . "$f" done unset f fi exec $command I've also tested it with command="startxfce4" and there was no difference. uh... just use 'exec ck-launch-session gnome-session' or 'exec ck-launch-session startxfce4' Just an idea in /etc/X11/xinit/xinitrc.d try moving 80-dbus *after* 90-consolekit, so to 95-dbus for instance then your .xinitrc might work, if that's the case, reopen the bug Bug 329317 might have been fixed wrong... Using "exec ck-launch-session startxfce4" worked, and updating to dbus-1.2.24-r2 also worked. So it looks like this can be properly resolved by stabilizing dbus-1.2.24-r1 or -r2. (In reply to comment #13) > Using "exec ck-launch-session startxfce4" worked, and updating to > dbus-1.2.24-r2 also worked. > > So it looks like this can be properly resolved by stabilizing dbus-1.2.24-r1 or > -r2. > bug 343323 |