[arch-general] hal has lost its mind again.
Listmates, On my laptop, automounting of usb drives and mmc/sd cards were working fine, now I get the "...mount.removable no <-- (action, result)" Full error dialog: http://www.3111skyline.com/download/Archlinux/bugs/hal-mount.removable.jpg The system configures the drives or cards just fine, it just will not create the directory under /media to allow access. It is really ironic because the drives/cards are fully accessible under "media:/". So, nothing in "/media", but OK in "media:/". I am concerned that changes made in /etc/hal/fdi/policy/20-ntfs-config-write-policy.fdi to allow NTFS mounts messed something else up. The file contains: <deviceinfo version="0.2"> <device> <match key="volume.fstype" string="ntfs"> <match key="@block.storage_device:storage.hotpluggable" bool="true"> <merge key="volume.fstype" type="string">ntfs-3g</merge> <merge key="volume.policy.mount_filesystem" type="string">ntfs-3g</merge> </match> </match> </device> </deviceinfo> which is straight from the wiki. The everything log contains the following: May 17 02:50:23 alchemy kernel: tifm_core: MMC/SD card detected in socket 0:1 May 17 02:50:23 alchemy kernel: mmc1: new SD card at address e624 May 17 02:50:23 alchemy kernel: isa bounce pool size: 16 pages May 17 02:50:23 alchemy kernel: mmcblk0: mmc1:e624 SD02G 1.89 GiB May 17 02:50:23 alchemy kernel: mmcblk0: p1 May 17 02:55:20 alchemy hald: mounted /dev/mmcblk0p1 on behalf of uid 0 May 17 03:06:54 alchemy kernel: ACPI: EC: missing confirmations, switch off interrupt mode. I don't know if the ACPI kernel message is evidence of the problem, but I included it just in case. I am slowly trying to make friends with hal/dbus, but I could use any help you can give in sorting this out. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On or about Sunday 17 May 2009 at approximately 03:16:26 David C. Rankin, J.D.,P.E. composed:
Listmates,
On my laptop, automounting of usb drives and mmc/sd cards were working fine, now I get the "...mount.removable no <-- (action, result)" Full error dialog:
http://www.3111skyline.com/download/Archlinux/bugs/hal-mount.removable.jpg
The system configures the drives or cards just fine, it just will not create the directory under /media to allow access. It is really ironic because the drives/cards are fully accessible under "media:/". So, nothing in "/media", but OK in "media:/".
I am concerned that changes made in /etc/hal/fdi/policy/20-ntfs-config-write-policy.fdi to allow NTFS mounts messed something else up. The file contains:
<deviceinfo version="0.2"> <device> <match key="volume.fstype" string="ntfs"> <match key="@block.storage_device:storage.hotpluggable" bool="true"> <merge key="volume.fstype" type="string">ntfs-3g</merge> <merge key="volume.policy.mount_filesystem" type="string">ntfs-3g</merge> </match> </match> </device> </deviceinfo>
which is straight from the wiki. The everything log contains the following:
May 17 02:50:23 alchemy kernel: tifm_core: MMC/SD card detected in socket 0:1 May 17 02:50:23 alchemy kernel: mmc1: new SD card at address e624 May 17 02:50:23 alchemy kernel: isa bounce pool size: 16 pages May 17 02:50:23 alchemy kernel: mmcblk0: mmc1:e624 SD02G 1.89 GiB May 17 02:50:23 alchemy kernel: mmcblk0: p1 May 17 02:55:20 alchemy hald: mounted /dev/mmcblk0p1 on behalf of uid 0 May 17 03:06:54 alchemy kernel: ACPI: EC: missing confirmations, switch off interrupt mode.
I don't know if the ACPI kernel message is evidence of the problem, but I included it just in case. I am slowly trying to make friends with hal/dbus, but I could use any help you can give in sorting this out. Thanks.
Another interesting note. When I inserted the card, there was no entry created in /media. Now 10 minutes later after I have been copying the photos, etc., the mount of /dev/mmcblk0p1 has *appeared* mounted on /media/disk? Huh? I can't tell you when it appeared, but I can tell you that for at least 4-5 minutes. So why the initial error and why the magical appearance after the error telling me it wasn't going to be mounted? What to check for more info? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On or about Sunday 17 May 2009 at approximately 03:51:10 David C. Rankin,
Another interesting note. When I inserted the card, there was no entry created in /media. Now 10 minutes later after I have been copying the photos, etc., the mount of /dev/mmcblk0p1 has *appeared* mounted on /media/disk? Huh?
I can't tell you when it appeared, but I can tell you that for at least 4-5 minutes. So why the initial error and why the magical appearance after the error telling me it wasn't going to be mounted? What to check for more info?
Here is the deal, When I stick the card in, as my normal user I can't access the device shown under "Services" "Storage Media" and there is no "disk" entry in /media. If I start konqueror running as root and then access "Services" "Storage Media" and the SD card (/dev/mmcblk0p1 in this case), Presto the device automatically appears as "disk" under /media and then I *can* access it (rw) as my normal user. What gives? What permissions are stuck? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Mon, May 18, 2009 at 05:05:09AM -0500, David C. Rankin, J.D.,P.E. wrote:
When I stick the card in, as my normal user I can't access the device shown under "Services" "Storage Media" and there is no "disk" entry in /media.
I usually have to refresh the window (F5) to make removable devices appear in system:/media inside kdemod3 konqueror, regardless of the hal/policykit mount problems.
On or about Monday 18 May 2009 at approximately 05:27:02 Alessandro Doro composed:
On Mon, May 18, 2009 at 05:05:09AM -0500, David C. Rankin, J.D.,P.E. wrote:
When I stick the card in, as my normal user I can't access the device shown under "Services" "Storage Media" and there is no "disk" entry in /media.
I usually have to refresh the window (F5) to make removable devices appear in system:/media inside kdemod3 konqueror, regardless of the hal/policykit mount problems.
Alessandro, Thanks. But in this case with kdemod3 the card shows up in system:/media (or what I've been calling media:/ [not /media]) my card appears instantly and disappears as soon as I remove it. So I dunno, there is something else going on here. I'll find it, but if anyone else has a clue, please pass it along. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Thanks. But in this case with kdemod3 the card shows up in system:/media (or what I've been calling media:/ [not /media]) my card appears instantly and disappears as soon as I remove it. So I dunno, there is something else going on here. I'll find it, but if anyone else has a clue, please pass it along.
AFAIK, HAL doesn't mount/umount devices .. hal just notifies your DE (or whatever listens to its dbus signals) and then your DE makes a request for the device to be mounted or not (based on preference this could be automatic or manual). -- damjan
David C. Rankin, J.D.,P.E. wrote:
On or about Sunday 17 May 2009 at approximately 03:51:10 David C. Rankin,
Another interesting note. When I inserted the card, there was no entry created in /media. Now 10 minutes later after I have been copying the photos, etc., the mount of /dev/mmcblk0p1 has *appeared* mounted on /media/disk? Huh?
I can't tell you when it appeared, but I can tell you that for at least 4-5 minutes. So why the initial error and why the magical appearance after the error telling me it wasn't going to be mounted? What to check for more info?
Here is the deal,
When I stick the card in, as my normal user I can't access the device shown under "Services" "Storage Media" and there is no "disk" entry in /media.
If I start konqueror running as root and then access "Services" "Storage Media" and the SD card (/dev/mmcblk0p1 in this case), Presto the device automatically appears as "disk" under /media and then I *can* access it (rw) as my normal user. What gives? What permissions are stuck?
Short answer: Use this for your /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"> <!-- <define_admin_auth group="wheel"/> --> <match action="org.freedesktop.hal.storage.mount-removable"> <return result="yes"/> </match> <!-- <match action="org.freedesktop.hal.storage.eject-removable"> <return result="yes"/> </match> --> </config> Long answer: See: http://bbs.archlinux.org/viewtopic.php?pid=542472 I have to say, I'm not very fond of this new console-kit/policy-kit stuff being the default in hal now. I far prefer the simplicity of standard unix groups and permissions. DR
On or about Monday 18 May 2009 at approximately 09:48:00 David Rosenstrauch composed:
David C. Rankin, J.D.,P.E. wrote:
On or about Sunday 17 May 2009 at approximately 03:51:10 David C. Rankin,
Another interesting note. When I inserted the card, there was no entry created in /media. Now 10 minutes later after I have been copying the photos, etc., the mount of /dev/mmcblk0p1 has *appeared* mounted on /media/disk? Huh?
I can't tell you when it appeared, but I can tell you that for at least 4-5 minutes. So why the initial error and why the magical appearance after the error telling me it wasn't going to be mounted? What to check for more info?
Here is the deal,
When I stick the card in, as my normal user I can't access the device shown under "Services" "Storage Media" and there is no "disk" entry in /media.
If I start konqueror running as root and then access "Services" "Storage Media" and the SD card (/dev/mmcblk0p1 in this case), Presto the device automatically appears as "disk" under /media and then I *can* access it (rw) as my normal user. What gives? What permissions are stuck?
Short answer:
Use this for your /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"> <!-- <define_admin_auth group="wheel"/> --> <match action="org.freedesktop.hal.storage.mount-removable"> <return result="yes"/> </match> <!-- <match action="org.freedesktop.hal.storage.eject-removable"> <return result="yes"/> </match> --> </config>
Long answer:
See: http://bbs.archlinux.org/viewtopic.php?pid=542472
I have to say, I'm not very fond of this new console-kit/policy-kit stuff being the default in hal now. I far prefer the simplicity of standard unix groups and permissions.
DR
DR, thanks! I guess I'll like Policy Kit once I make friends with it, but it sure was a whole lot easier just issuing the 'mount /dev/whatever /media/whatever' command. It looks like I just didn't have enough in PolicyKit.conf. I had the following: <?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"> <define_admin_auth group="wheel"/> <match action="org.freedesktop.hal.storage.mount-removable"> <match group="users"> <return result="yes"/> </match> </match> <match user="david"> <return result="yes"/> </match> <match user="david"> <!-- replace with your login or delete the line if you want to allow all users to manipulate devices (keep security issues in mind though) --> <match action="org.freedesktop.hal.storage.*"> <return result="yes"/> </match> <match action="hal-storage-mount-fixed-extra-options"> <!-- for internal devices mounted with extra options like a wished mount point --> <return result="yes" /> </match> <match action="hal-storage-mount-removable-extra-options"> <!-- for external devices mounted with extra options like a wished mount point --> <return result="yes" /> </match> </match> <!-- don't forget to delete this line if you deleted the first one --> </config> Why in the heck the following wasn't good enough escapes me at present: <define_admin_auth group="wheel"/> <match user="david"> <return result="yes"/> </match> That's says let *me* do anything with anything (twice I might add). I guess in addition to giving yourself global authorization you also have to give yourself specific authorization as well. Also, why do you have .eject-removable commented out? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
David C. Rankin, J.D.,P.E. wrote:
Why in the heck the following wasn't good enough escapes me at present:
<define_admin_auth group="wheel"/>
<match user="david"> <return result="yes"/> </match>
That's says let *me* do anything with anything (twice I might add). I guess in addition to giving yourself global authorization you also have to give yourself specific authorization as well.
Also, why do you have .eject-removable commented out?
I really have no idea. I don't even understand this console kit/policy kit stuff, frankly. But in a nutshell, when you take out all the comments, my policy kit file essentially boils down to: <config version="0.1"> <match action="org.freedesktop.hal.storage.mount-removable"> <return result="yes"/> </match> </config> Dunno ... seems to work. Have you tried that? BTW, maybe it's not sufficient to restart hal, since theis isn't technically a HAL file, but rather a policy kit file. So I'd suggest logging out and then in again after the change. HTH, DR
On or about Monday 18 May 2009 at approximately 12:42:41 David Rosenstrauch composed:
BTW, maybe it's not sufficient to restart hal, since theis isn't technically a HAL file, but rather a policy kit file. So I'd suggest logging out and then in again after the change.
HTH,
DR
Well, I guess that would be yet another bug in PolicyKit. Per the PolicyKit.conf man page: <quote> Changes to this configuration file are immediately propagated to running processes using the PolicyKit library. If the configuration file is invalid, processes using this library will log this fact to the system logger and the library will only only return no as the answer to processes using it. </quote> Of all the changes I've made, no errors logged so it should be happily propagating, ... or fornicating, ... or whatever PolicyKit does to my system ;-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
2009/5/18 David C. Rankin, J.D.,P.E. <drankinatty@suddenlinkmail.com>:
<match group="users"> <return result="yes"/> </match>
I think this may be your problem. I searched some time ago and found out PolicyKit didn't support group matches. A quick look to the PolicyKit.conf(5) man page seems to confirm this is still the case. Now, I don't know if an invalid entry could invalidate the whole config, but it's worth a try. Corrado
On or about Tuesday 19 May 2009 at approximately 03:33:03 bardo composed:
2009/5/18 David C. Rankin, J.D.,P.E. <drankinatty@suddenlinkmail.com>:
<match group="users"> <return result="yes"/> </match>
I think this may be your problem. I searched some time ago and found out PolicyKit didn't support group matches. A quick look to the PolicyKit.conf(5) man page seems to confirm this is still the case. Now, I don't know if an invalid entry could invalidate the whole config, but it's worth a try.
Corrado
Corrado, You and I may be saying the same thing for two different circumstances. Admin_auth certainly allows both user and group auths for actions (man 5 PolicyKit.conf): define_admin_auth This element is used to specify the meaning of "authenticate as administrator". It is normally used at the top-level but can also be used deep inside a number of match elements for conditional behavior. There can only be a single attribute in each define_admin_auth element. POSIX Extended Regular Expression syntax is not supported in the value part, however multiple values to match on can be separated with the bar (|) character. The following attributes are supported: user Administrator authentication means authenticate as the given user(s). If no define_admin_auth element is given, the default is to use user="root" e.g. administrator authentication mean authenticate as the super user. group Administrator authentication means that any user in the groups matching the given value can be used to authenticate. Typically, on a system with the root account disabled one wants to use something like group="wheel" to e.g. enable all UNIX users in the UNIX group wheel to be able to authentication whenever administrator authentication is required. </quote> The strange thing is that I can specify myself or the wheel group as an admin with auth privileges and policy kit still doesn't allow access. I haven't had time to play with it anymore yet after DR sent his config over, but I'll let you know. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
2009/5/20 David C. Rankin, J.D.,P.E. <drankinatty@suddenlinkmail.com>:
On or about Tuesday 19 May 2009 at approximately 03:33:03 bardo composed:
2009/5/18 David C. Rankin, J.D.,P.E. <drankinatty@suddenlinkmail.com>:
<match group="users"> <return result="yes"/> </match>
I think this may be your problem. I searched some time ago and found out PolicyKit didn't support group matches. A quick look to the PolicyKit.conf(5) man page seems to confirm this is still the case. Now, I don't know if an invalid entry could invalidate the whole config, but it's worth a try.
Corrado
Corrado,
You and I may be saying the same thing for two different circumstances. Admin_auth certainly allows both user and group auths for actions (man 5 PolicyKit.conf):
define_admin_auth
I wasn't saying you can't use "group" as an attribute for "define_admin_auth", I was saying you can't use it as an attribute for "match". So at least that rule won't work, I tried it before. Now, I don't know how PolicyKit deals with wrong parameters, but in the worst case it could treat the whole file as invalid, and that could be why your *other* rules don't work. I hope I made myself clearer this time :) Corrado
On or about Wednesday 20 May 2009 at approximately 04:00:48 am bardo composed:
2009/5/20 David C. Rankin, J.D.,P.E. <drankinatty@suddenlinkmail.com>:
On or about Tuesday 19 May 2009 at approximately 03:33:03 bardo composed:
2009/5/18 David C. Rankin, J.D.,P.E. <drankinatty@suddenlinkmail.com>:
<match group="users"> <return result="yes"/> </match>
I think this may be your problem. I searched some time ago and found out PolicyKit didn't support group matches. A quick look to the PolicyKit.conf(5) man page seems to confirm this is still the case. Now, I don't know if an invalid entry could invalidate the whole config, but it's worth a try.
Corrado
Corrado,
You and I may be saying the same thing for two different circumstances. Admin_auth certainly allows both user and group auths for actions (man 5 PolicyKit.conf):
define_admin_auth
I wasn't saying you can't use "group" as an attribute for "define_admin_auth", I was saying you can't use it as an attribute for "match". So at least that rule won't work, I tried it before. Now, I don't know how PolicyKit deals with wrong parameters, but in the worst case it could treat the whole file as invalid, and that could be why your *other* rules don't work.
I hope I made myself clearer this time :)
Corrado
Yep, I'll give Policy kit another shot when I pop the archlinux drive back in. If Policy Kit is ignoring the whole file (which it shouldn't do, but seems like it is), then that should be logged somewhere. I have been through everything.log and messages.log, etc. and there isn't any message like that. If it isn't logging rejections, then we need to find a way to have it do so. It would sure make troubleshooting policy kit problems a whole lot easier. Thank you for your help.
On or about Monday 18 May 2009 at approximately 09:48:00 David Rosenstrauch composed:
<match action="org.freedesktop.hal.storage.mount-removable"> <return result="yes"/> </match> <!-- <match action="org.freedesktop.hal.storage.eject-removable"> <return result="yes"/> </match> -->
AAARRRGGHH! Still no joy: org.freedesktop.hal.storage.mount-removable no <-- (action, result) (yes, I restarted hal ;-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On or about Monday 18 May 2009 at approximately 09:48:00 David Rosenstrauch composed:
<match action="org.freedesktop.hal.storage.mount-removable"> <return result="yes"/> </match> <!-- <match action="org.freedesktop.hal.storage.eject-removable"> <return result="yes"/> </match> -->
What I don't get is this (from PolicyKit(5)): ALLOW EVERYTHING The users "davidz" and "bateman" are allowed to do any action: <match user="davidz|bateman"> <return result="yes"/> </match> I have: <match user="david"> <return result="yes"/> </match> I'm david, so what in the heck is the problem :-( -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
participants (5)
-
Alessandro Doro
-
bardo
-
Damjan Georgievski
-
David C. Rankin, J.D.,P.E.
-
David Rosenstrauch