hal 0.5.13-3 breaks volume mounting

ninian · 2009-11-14 17:31:54

@madalu:

I'm getting rather baffled too as to what is the "right" thing to do. I've got problems with the skvm daemon which seemed to happen after the last dbus and hal upgrades.

Am using hal and just use exec xinit -- :0 in my .bash_profile to start X - no SLiM, GDM, etc.
What's especially confusing is what should launch Openbox in .xinitrc:

exec openbox-session
or
exec ck-launch-session openbox-session
or
exec dbus-launch --exit-with-session openbox-session

(The last was recommended somewhere in the Wiki.)

I'd be most grateful if the rationale could be made a bit clearer by those dbus/hal/ConsoleKit experts in the know.

kokoko3k · 2009-11-14 18:55:21

ninian wrote:

I'd be most grateful if the rationale could be made a bit clearer by those dbus/hal/ConsoleKit experts in the know.

Me too; i solved my own problem and i can mount again, but i admit to be a bit (a lot) confused about hal, policykit and now consolekit too.
Sorry for this lillte offtopic:
Is policykit really deprecated? Maybe i am wrong, but isn't it a young project? gui has been made for gnome and kde4(!) too.
I hope someone can provide a (bunch of) link(s) to clarify.
Thanks in advance!

madalu · 2009-11-14 19:29:34

kokoko3k wrote:

ninian wrote:
I'd be most grateful if the rationale could be made a bit clearer by those dbus/hal/ConsoleKit experts in the know.
Me too; i solved my own problem and i can mount again, but i admit to be a bit (a lot) confused about hal, policykit and now consolekit too.

Would you mind sharing how you solved this problem? The only solution that's worked for me is downgrading to hal 0.5.13-2. Thanks.

I second the request for more information. If there really is such a major change as the deprecation of policykit, wouldn't that merit an entry in the Arch Linux news/announcements feed? Thus far, the hal 0.5.13-3 upgrade has broken USB mounting for me (in Thunar and pcmanfm), even though I have consolekit installed and activated via .xinitrc.

Gusar · 2009-11-14 21:08:49

@ninian:
This should work as .xinitrc:

#!/bin/sh
eval $(dbus-launch --sh-syntax --exit-with-session)
exec ck-launch-session openbox-session

grey · 2009-11-14 21:42:01

What do you need the first line for? dbus should already be running, and DBUS_SESSION_BUS_ADDRESS should already be defined.

grey · 2009-11-14 21:56:54

Here is what I've been able to figure out regarding hal / polikcykit / consolekit:

Policykit is still a dependency of KDE (via polkit-qt), but its policies are being ignored by hal.
Consolekit and polkit don't have any configuration files that can be used to define access control. At least I didn't see anything in the project documentation.

For hal 0.5.13-2, access control was defined in:
/etc/dbus-1/system.d/hal.conf
/etc/PolicyKit/PolicyKit.conf
/usr/share/PolicyKit/policy/org.freedesktop.hal.*.policy

For hal 0.5.13-3, access control is defined in /etc/dbus-1/system.d/hal.conf.

The new default access controls are more permissive than they were before: A user that is "at_console" (by launching ck-launch-session) is now able to mount internal drives via hal, which was previously not the case.

Defining group base access control in hal.conf still works.

Last edited by grey (2009-11-14 21:57:59)

ninian · 2009-11-14 22:14:17

@Gusar and grey:

grey wrote:

What do you need the first line for? dbus should already be running, and DBUS_SESSION_BUS_ADDRESS should already be defined.
....
A user that is "at_console" (by launching ck-launch-session) is now able to mount internal drives via hal, which was previously not the case.

After booting with just 'exec ck-launch-session openbox-session' in .xinitrc, the variable is indeed already defined:

$ echo $DBUS_SESSION_BUS_ADDRESS
unix:abstract=/tmp/dbus-L6c8xnUk8A,guid=0fd9f6dc2055fee487fedec24afeeb2a

Thanks for clarifying that bit about hal.conf.

Gusar · 2009-11-14 22:32:47

grey wrote:

What do you need the first line for? dbus should already be running, and DBUS_SESSION_BUS_ADDRESS should already be defined.

The system dbus should be running, yes, but not the user one. At least it wasn't here - I use lxde - and gvfs wasn't working. Adding that line I now have a user dbus session and gvfs works.

grey · 2009-11-14 22:58:09

OK - I don't use gvfs. I noticed that some applications - e.g. firefox - will start a user dbus session automatically. But as far as hal and access control is concerned I'm not sure it's needed. I can mount internal drives via hal (e.g. using pcmanfm) without a user dbus session. All I need for that is a consolekit session.

Last edited by grey (2009-11-14 22:58:37)

skottish · 2009-11-14 23:45:46

For everyone still having trouble and are using Openbox, try simply:

ck-launch-session openbox

in ~.xinitrc. You may be having conflicts between session managers.

Bonzodog · 2009-11-15 00:06:55

Can I ask a quick question -- Why are people worrying about automounting relying on hal/consolkit/policykit when udevd does it all for you?

PLEASE look at the wiki section about udev automounting -- http://wiki.archlinux.org/index.php/Ude … SB_devices

That pretty much solves most automounting problems, although lately, i've noticed its mounting everything as root rather than user, which it did when i first started using it. I do have hal installed and running as a dep to something else, but do not rely on it doing anything in the mounting dept.

Last edited by Bonzodog (2009-11-15 00:07:40)

grey · 2009-11-15 00:35:51

As I understand it, this thread is about mounting, not automounting.

But leaving that aside, I personally just don't like the idea of automounting. I don't want to have anything mounted automatically *as root*, and since Linux is a multi-user system there is no natural choice for a non-root user that could own the mount. I want the system to show me all available devices, and if I want to mount something, I click on it. It just feels right that way.

madalu · 2009-11-15 00:53:32

skottish wrote:

For everyone still having trouble and are using Openbox, try simply:
ck-launch-session openbox
in ~.xinitrc. You may be having conflicts between session managers.

Thanks for the tip, but when I try this, my ~/.config/openbox/autostart.sh doesn't run. Any advice?

MarCustomized · 2009-11-15 01:18:12

madalu wrote:

skottish wrote:
For everyone still having trouble and are using Openbox, try simply:
ck-launch-session openbox
in ~.xinitrc. You may be having conflicts between session managers.
Thanks for the tip, but when I try this, my ~/.config/openbox/autostart.sh doesn't run. Any advice?

ck-launch-session openbox-session

The openbox command alone runs "stand-alone" openbox. The openbox-session command runs openbox and it's autostart.sh file. You can read about in the openbox man page.

kokoko3k · 2009-11-15 01:36:23

madalu wrote:

Would you mind sharing how you solved this problem? The only solution that's worked for me is downgrading to hal 0.5.13-2. Thanks.

my own problem was with kdm3+kdemod3, i already wrote (in this thread) how i managed to get kde mounting again (ck-launch-session wrapped in kdm3).

Last edited by kokoko3k (2009-11-15 01:37:37)

skottish · 2009-11-15 02:24:38

MarCustomized wrote:

madalu wrote:
skottish wrote:
For everyone still having trouble and are using Openbox, try simply:
ck-launch-session openbox
in ~.xinitrc. You may be having conflicts between session managers.
Thanks for the tip, but when I try this, my ~/.config/openbox/autostart.sh doesn't run. Any advice?
ck-launch-session openbox-session
The openbox command alone runs "stand-alone" openbox. The openbox-session command runs openbox and it's autostart.sh file. You can read about in the openbox man page.

I wasn't sure if this stuff was in conflict or not:

if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS"; then
       eval `dbus-launch --sh-syntax --exit-with-session`
fi

ralle · 2009-11-15 18:39:09

...is someone using E17 with Entrance and experiencing this hal-no-mount-scenario? I commented out the lines I added to my PolicyKit.conf which allowed me to mount before the upgrade... Didn't even know this was so much of a "hack".
Anyway, all mentioned solutions refer to the xinitrc starting method. But as stated above I use Entrance, the E17 login manager, which is fired up with the inittab method. I did try changing the Xsession entry by adding "ck-launch-session", but Entrance wouldn't start anymore...

Can somebody help me please? Where do I add the ck-launch-session in this case?
Thanks in advance!

Lyceuhns · 2009-11-16 12:51:02

A easy "hack" to solve the problem, it's removing restriction to users outside the console.

In the /etc/dbus-1/system.d/hal.conf we have this:

<!-- Only allow users at the local console to manipulate devices -->
  <policy at_console="true">

So, just set 'false' to allow everyone:

<!-- Only allow users at the local console to manipulate devices -->
  <policy at_console="false">

Cheers. o/

grey · 2009-11-16 13:17:18

Did you actually test that? It looks like this wouldn't allow everyone, it would allow users not at console.

Last edited by grey (2009-11-16 13:17:43)

Lyceuhns · 2009-11-16 14:16:40

grey wrote:

Did you actually test that? It looks like this wouldn't allow everyone, it would allow users not at console.

Yes, i did it, and it's working fine.
And you're right, when i said "everyone" i wanted to say the users out the console.

grey · 2009-11-16 15:18:08

I see. I was wondering why you didn't say <policy context="default"> if you wanted to remove restrictions for everyone.

Lyceuhns · 2009-11-16 19:25:47

Well, in this topic on the Brazilian forum, a user posted a suggest as solution adding the following code to the /etc/dbus-1/system.d/hal.conf:

<policy group="users">
  <allow send_interface="org.freedesktop.Hal.Device.SystemPowerManagement"/>
  <allow send_interface="org.freedesktop.Hal.Device.VideoAdapterPM"/>
  <allow send_interface="org.freedesktop.Hal.Device.LaptopPanel"/>
  <allow send_interface="org.freedesktop.Hal.Device.Volume"/>
  <allow send_interface="org.freedesktop.Hal.Device.Volume.Crypto"/>
</policy>

So reading the file hal.conf, and taking was posted here about consolekit, i found that piece of code familiar and tried change it, and it worked.

I don't know about '<policy context="default">', what value do you suggest to set here?

See ya. o/

grey · 2009-11-16 22:00:05

<policy context="default"> defines the default access permissions. It also has the lowest priority. See the <policy> section of the dbus-daemon manpage for more information.

BTW I found the pointer to the man page via google "hal.conf" -> http://www.linuxquestions.org/questions … nf-668215/. The lack of information / documentation surrounding this area is pretty bad.

toketin · 2009-11-17 12:08:17

Today i've discovered to had this strange problem with Hal that didn't mount an usb device so i've fixed by reading this thread and adding in my .xinitrc the line exec ck-launch-session openbox-session, i've restarted X and hal mounted correctly the device thanks at all for the information!
P.s. i use openbox on my netbook with Slim as login manager

Last edited by toketin (2009-11-17 12:09:01)

madalu · 2009-11-17 14:05:30

toketin wrote:

Today i've discovered to had this strange problem with Hal that didn't mount an usb device so i've fixed by reading this thread and adding in my .xinitrc the line exec ck-launch-session openbox-session, i've restarted X and hal mounted correctly the device thanks at all for the information!
P.s. i use openbox on my netbook with Slim as login manager

That's great for you. But for some of us here (see above), adding ck-launch-session does not solve the problem. Are you doing anything else?

I "solved" this by following Lyceuhns's advice and changing

to

in /etc/dbus-1/system.d/hal.conf.

But I would be very eager for an expert to come along and suggest the orthodox solution to this.

Thanks.

Last edited by madalu (2009-11-17 14:11:52)

Arch Linux

#26 2009-11-14 17:31:54

Re: hal 0.5.13-3 breaks volume mounting

#27 2009-11-14 18:55:21

Re: hal 0.5.13-3 breaks volume mounting

#28 2009-11-14 19:29:34

Re: hal 0.5.13-3 breaks volume mounting

#29 2009-11-14 21:08:49

Re: hal 0.5.13-3 breaks volume mounting

#30 2009-11-14 21:42:01

Re: hal 0.5.13-3 breaks volume mounting

#31 2009-11-14 21:56:54

Re: hal 0.5.13-3 breaks volume mounting

#32 2009-11-14 22:14:17

Re: hal 0.5.13-3 breaks volume mounting

#33 2009-11-14 22:32:47

Re: hal 0.5.13-3 breaks volume mounting

#34 2009-11-14 22:58:09

Re: hal 0.5.13-3 breaks volume mounting

#35 2009-11-14 23:45:46

Re: hal 0.5.13-3 breaks volume mounting

#36 2009-11-15 00:06:55

Re: hal 0.5.13-3 breaks volume mounting

#37 2009-11-15 00:35:51

Re: hal 0.5.13-3 breaks volume mounting

#38 2009-11-15 00:53:32

Re: hal 0.5.13-3 breaks volume mounting

#39 2009-11-15 01:18:12

Re: hal 0.5.13-3 breaks volume mounting

#40 2009-11-15 01:36:23

Re: hal 0.5.13-3 breaks volume mounting

#41 2009-11-15 02:24:38

Re: hal 0.5.13-3 breaks volume mounting

#42 2009-11-15 18:39:09

Re: hal 0.5.13-3 breaks volume mounting

#43 2009-11-16 12:51:02

Re: hal 0.5.13-3 breaks volume mounting

#44 2009-11-16 13:17:18

Re: hal 0.5.13-3 breaks volume mounting

#45 2009-11-16 14:16:40

Re: hal 0.5.13-3 breaks volume mounting

#46 2009-11-16 15:18:08

Re: hal 0.5.13-3 breaks volume mounting

#47 2009-11-16 19:25:47

Re: hal 0.5.13-3 breaks volume mounting

#48 2009-11-16 22:00:05

Re: hal 0.5.13-3 breaks volume mounting

#49 2009-11-17 12:08:17

Re: hal 0.5.13-3 breaks volume mounting

#50 2009-11-17 14:05:30

Re: hal 0.5.13-3 breaks volume mounting

Board footer