hal 0.5.13-3 breaks volume mounting

Themaister · 2009-11-12 15:16:16

I -Syu'd today and hal got upgraded to 0.5.13-3 and I found that hal no longer wanted to mount my drives. PCManFM just gave me a long and weird error message. I built the 0.5.13-2 package, and it worked fine again.

Then I see:

upgpkg: hal 0.5.13-3
Disable ACL management
Disable consolekit support
Disable policykit suport
Switch to at_console rules instead of using policykit
Add some patched from fedora
revert ssb removal, new versions of networkmanager have fixes for this

A quite large change in the hal package. What is this at_console? I can see the benefit of moving away from the horrid PolicyKit. How to make at_console work well?

riivo · 2009-11-12 15:25:40

Same error here.

Anarconda · 2009-11-12 15:40:00

Same problem, same solution.

JGC · 2009-11-12 15:43:54

at_console means that you have to have a console file for your username in /var/run/console. This is done by consolekit, but as you probably hacked your policykit config to get 0.5.13-2 working, this doesn't work on your system.

JohannesSM64 · 2009-11-12 15:49:34

Same problem, same solution.

This is done by consolekit, but as you probably hacked your policykit config to get 0.5.13-2 working, this doesn't work on your system.

Yeah. I did hack my policykit config to get 0.5.13-2 working, and most likely, everyone else here also did.

Themaister · 2009-11-12 15:57:59

Indeed, indeed. I hacked my PolicyKit too How to you fix the console file for consolekit?

riivo · 2009-11-12 17:21:07

What policykit config hacking are you exactly talking about?

beepressure · 2009-11-12 17:25:12

So, What IS the solution to fixing the latest hal update?

Themaister · 2009-11-12 17:45:07

riivo wrote:

What policykit config hacking are you exactly talking about?

cat /etc/PolicyKit/PolicyKit.conf

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->

<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN"
"http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd">

<!-- See the manual page PolicyKit.conf(5) for file format -->

<config version="0.1">
<match action="org.freedesktop.hal.storage.mount-removable">
    <return result="yes"/>
</match>

<match action="org.freedesktop.hal.storage.mount-fixed">
    <return result="yes"/>
</match>
</config>

This, I suppose.

riivo · 2009-11-12 17:59:58

Themaister, such file doesn't exist on my computer, because I don't even have policykit installed.

JohannesSM64 · 2009-11-12 18:08:01

That PolicyKit.conf hack was needed to mount anything in 0.5.13-2, at least for me.

SomeGuyDude · 2009-11-12 18:42:44

That problem you're having is a really weird permissions issue. You can mount volumes as root. Which, while workable, isn't a "solution" just yet.

EDIT: For now, the AUR package hal-easy works just fine.

Last edited by SomeGuyDude (2009-11-12 18:46:07)

Anarconda · 2009-11-12 18:43:52

JohannesSM64 wrote:

That PolicyKit.conf hack was needed to mount anything in 0.5.13-2, at least for me.

Same here. In any case after change the file (I preserved a copy) and restarting hal the problem is still there.

Themaister · 2009-11-12 19:00:00

Well, I installed hal-easy from AUR and I'm happy hats now

JohannesSM64 · 2009-11-12 19:00:53

Me too!

SomeGuyDude · 2009-11-12 19:30:36

I'd almost suggest everyone use ONLY hal-easy. Remember the policykit fiasco from a while ago? Hal-easy fixed that, too. I don't even know why I uninstalled it, the thing has never been anything but perfet.

JGC · 2009-11-12 21:45:00

I would suggest people to start thinking instead of start hacking everytime we package something. If you don't want to use login managers like gdm and kdm, then make sure consolekit is integrated in your setup. Life without consolekit is going to be very hard in the near future. At this moment udev already sets ACLs based on consolekit logins, which replaces the need for audio, video, storage, etc groups. Every distribution is switching to consolekit based setups, and in the future we might even remove those groups.

Themaister · 2009-11-12 23:16:44

Consolekit has been a bit of a blackbox to me at least. It seems to me like a new policykit. How to you integrate consolekit with your setup, really? I couldn't find anything relevant on the Wiki. (Well, I found something that might ... )
Is it as simple as having

exec ck-launch-session openbox-session

in my .xinitrc rather than just exec openbox-session and the new hal would work with mounting again?

Last edited by Themaister (2009-11-12 23:25:52)

TheBodziO · 2009-11-13 00:35:13

Yup… all looks peachy… but now I'm struggling to make automounting work when I'm in console…

Last edited by TheBodziO (2009-11-13 00:35:35)

attila · 2009-11-13 06:21:33

JGC wrote:

I would suggest people to start thinking instead of start hacking everytime we package something. If you don't want to use login managers like gdm and kdm, then make sure consolekit is integrated in your setup. Life without consolekit is going to be very hard in the near future. At this moment udev already sets ACLs based on consolekit logins, which replaces the need for audio, video, storage, etc groups.

Okay, i don't have a problem because i use kdm and i don't use any automount feature. But is there any documentation for endusers about the configuration of this new *kit packages? If you know one (or more) url than this would be very nice because a first search of mine was not successful.

JGC wrote:

Every distribution is switching to consolekit based setups, and in the future we might even remove those groups.

It is true that all distros will be use this in the future and therefore your decision to switch to it is the right one. But removing this groups won't happens in the near future or what will happens than with the content of /etc/udev/permissions.d/udev.permissions?

skipio · 2009-11-13 08:59:32

no problems here with slim and openbox. i just added 'exec ck-launch-session openbox-session' in my ~/.xinitrc, so '/var/run/console/my_username' is created and everything works as expected.
no need to "hack", i guess you can do the same with any login manager.

for console login:
after logging, 'ck-launch-session' will start a new consolekit instance, so automounting, etc should work there.

Last edited by skipio (2009-11-13 10:36:32)

kokoko3k · 2009-11-13 12:10:08

i'm on a fresh install of kdemod3, last update broke volume mounting for mee too.
complete error message from kdialog is:

"Rejected send message, 1 matched rules; type="method_call", sender=":1.8" (uid=1000 pid=3578 comm="kded [kdeinit] --new-startup) interface="org.freedesktop.Hal.Device.Volume" member="Mount" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=3396 comm="/usr/sbin/hald))"

Rolled back to previous hal solved the issue, but i'd like to understand what's going on.

JGC · 2009-11-13 13:15:14

I don't know if kdemod3 has consolekit integration, kdemod3 isn't an official project and KDE3 isn't maintained anymore. When you upgrade hal from the policykit version to the non-policykit version, you need to reload dbus in case it failed to pick up the new rules, and you need to restart hal to get rid of hal's assumption you're using policykit.

kokoko3k · 2009-11-13 13:25:35

Yep, i'd like to avoid going to hal-easy, and i'd like to avoid kde4 too (still lots of memory leaks in plasma-desktop with no widgets at all apart from folder-view).
Now that i'm reading better about consolekit magics, if i understood properly,
maybe editing /etc/X11/sessions/kdemod3.desktop from

Exec=/opt/kde/bin/startkde
TryExec=/opt/kde/bin/startkde

to

Exec=ck-launch-session /opt/kde/bin/startkde
TryExec=ck-launch-session /opt/kde/bin/startkde

would solve the issue?

--EDIT--
Nope, it doesn't; kdm3 doesn't seems to like it.
I ended up copying /opt/kde/bin/startkde to /opt/kde/bin/startkde.old
then edited startkde, removed anything and just wrote:

#!/bin/sh
exec ck-launch-session /opt/kde/bin/startkde.old

So, just wrapped it, and now i can mount again with kde3.

Last edited by kokoko3k (2009-11-13 17:51:25)

madalu · 2009-11-14 17:12:12

skipio wrote:

no problems here with slim and openbox. i just added 'exec ck-launch-session openbox-session' in my ~/.xinitrc, so '/var/run/console/my_username' is created and everything works as expected.
no need to "hack", i guess you can do the same with any login manager.
for console login:
after logging, 'ck-launch-session' will start a new consolekit instance, so automounting, etc should work there.

Adding ck-launch-session to my .xinitrc does not work for me. I.e.,

exec ck-launch-session openbox-session

For the record, I've tried rebooting as well as restarting dbus and hal.

Still results in the following error message:

Rejected send message, 1 matched rules; type="method_call", sender=":1.34" (uid=1000 pid=4159 comm="exo-mount) interface="org.freedesktop.Hal.Device.Volume" member="Mount" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=3519 comm="/usr/sbin/hald)).

Please advise. It's all well and good for a developer to lecture people not to "hack" temporary solutions, but if an upgrade of hal breaks mounting, then it would be nice to have a developer chime in here with the "correct" solution.

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

Arch Linux

#1 2009-11-12 15:16:16

hal 0.5.13-3 breaks volume mounting

#2 2009-11-12 15:25:40

Re: hal 0.5.13-3 breaks volume mounting

#3 2009-11-12 15:40:00

Re: hal 0.5.13-3 breaks volume mounting

#4 2009-11-12 15:43:54

Re: hal 0.5.13-3 breaks volume mounting

#5 2009-11-12 15:49:34

Re: hal 0.5.13-3 breaks volume mounting

#6 2009-11-12 15:57:59

Re: hal 0.5.13-3 breaks volume mounting

#7 2009-11-12 17:21:07

Re: hal 0.5.13-3 breaks volume mounting

#8 2009-11-12 17:25:12

Re: hal 0.5.13-3 breaks volume mounting

#9 2009-11-12 17:45:07

Re: hal 0.5.13-3 breaks volume mounting

#10 2009-11-12 17:59:58

Re: hal 0.5.13-3 breaks volume mounting

#11 2009-11-12 18:08:01

Re: hal 0.5.13-3 breaks volume mounting

#12 2009-11-12 18:42:44

Re: hal 0.5.13-3 breaks volume mounting

#13 2009-11-12 18:43:52

Re: hal 0.5.13-3 breaks volume mounting

#14 2009-11-12 19:00:00

Re: hal 0.5.13-3 breaks volume mounting

#15 2009-11-12 19:00:53

Re: hal 0.5.13-3 breaks volume mounting

#16 2009-11-12 19:30:36

Re: hal 0.5.13-3 breaks volume mounting

#17 2009-11-12 21:45:00

Re: hal 0.5.13-3 breaks volume mounting

#18 2009-11-12 23:16:44

Re: hal 0.5.13-3 breaks volume mounting

#19 2009-11-13 00:35:13

Re: hal 0.5.13-3 breaks volume mounting

#20 2009-11-13 06:21:33

Re: hal 0.5.13-3 breaks volume mounting

#21 2009-11-13 08:59:32

Re: hal 0.5.13-3 breaks volume mounting

#22 2009-11-13 12:10:08

Re: hal 0.5.13-3 breaks volume mounting

#23 2009-11-13 13:15:14

Re: hal 0.5.13-3 breaks volume mounting

#24 2009-11-13 13:25:35

Re: hal 0.5.13-3 breaks volume mounting

#25 2009-11-14 17:12:12

Re: hal 0.5.13-3 breaks volume mounting

Board footer