Bug 188224 - volume.policy.desired_mount_point not used by hal mount script
volume.policy.desired_mount_point not used by hal mount script
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
: 186358 191057 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-04-07 04:29 EDT by Marc Dejardin
Modified: 2013-03-13 00:50 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-19 11:06:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Part of the log file generated when I plug the usb memory (--verbose=yes ---use-syslog) (21.37 KB, application/octet-stream)
2006-04-07 06:22 EDT, Marc Dejardin
no flags Details

  None (edit)
Description Marc Dejardin 2006-04-07 04:29:39 EDT
Description of problem:
I want to configure HAL to mount my devices at some fixed point.
I have made a script :
which defined the desired mount points for my devices.
The desired mount points are recognaized by hal since they appear
in hal-device-manager:
volume.policy.desired_mount_point    strlist    stick

The problem is that this info is not used by 

and the device is always mounted at /media/disk

I think that the argument is not passed from haldaemon to the script, since 
after the line:

The variable GIVEN_MOUNTPOINT is empty

Version-Release number of selected component (if applicable):
FC5, hal-0.5.7-3

How reproducible:

Steps to Reproduce:
1.Create a file /usr/share/hal/fdi/policy/20thirdparty/99-usbdisk-policy.fdi
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">

    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
        <match key="volume.uuid" string="428C-349F">
          <merge key="volume.policy.desired_mount_point"
    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
        <match key="volume.uuid" string="aa266bc4-86e9-4832-815e-df4ca1d71720">
          <merge key="volume.policy.desired_mount_point" type="string">extra</merge>
    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
        <match key="volume.uuid" string="4034-0469">
          <merge key="volume.policy.desired_mount_point" type="string">stick</merge>

2. restart hal
service haldaemon restart

3. Plug the device
Actual results:
device mounted on /media/disk

Expected results:
device mounted on /media/stick

Additional info:
Comment 1 Marc Dejardin 2006-04-07 06:22:25 EDT
Created attachment 127448 [details]
Part of the log file generated when I plug the usb memory (--verbose=yes ---use-syslog)
Comment 2 John (J5) Palmieri 2006-04-19 11:06:58 EDT
Policy has been removed athough upstream should have deprecated it first (for
their part they said they would be more careful in the future).  Upstream is
working on a more robust and secure way of setting policy using gnome-mount.
Comment 3 Marc Dejardin 2006-04-20 03:36:33 EDT
OK I wiil look at gnome-mount.
Unfortunatly I can't find any documentatiuon...
I guess that I have something to do with the file 
But I have absolutely no idea of the syntax of the file since the default file
is empty.
Comment 4 John (J5) Palmieri 2006-05-08 13:06:59 EDT
*** Bug 186358 has been marked as a duplicate of this bug. ***
Comment 5 John (J5) Palmieri 2006-05-08 13:07:17 EDT
*** Bug 191057 has been marked as a duplicate of this bug. ***
Comment 6 George Billios 2006-05-08 14:14:54 EDT
Dear All,

First of all I don't understand why Bug 186358 is a duplicate of this one and
not the other way around since Bug 186358 is:
1. Older than this one
2. Refers to the correct component for the problem which is gnome-mount and not hal.

But more important is that all 3 bug reports which are relevant were closed! 

Well I don't see a solution, why are they closed?

Marc, don't expect to see anything in gnome-mount documantation since there is
not documentation. As for gnome-mounts' development... where there is not
development at all at the moment!

John, besides closing bugs can you please ask for someone from 'upstream' come
down here and give a solution or at least talk about this problem?

Comment 7 John (J5) Palmieri 2006-05-08 14:54:56 EDT
Because I got all these bug reports and closed one first and the rest are all
duplicates.  gnome-mount is what does the mounting and policy now so it is the
correct component.  HAL got rid of its policy code.  This is not solvable in
FC-5 as is.  Development is going on upstream with HAL, gnome-mount and
PolicyKit to create a complete solution.  When it is ready I will evaluate
backporting it to FC-5.  Sorry it is the best answere I can give, cutting edge
technology and all. I expect PolicyKit will become the way for setting HAL
policy (not just mounting) for a long time to come. 
Comment 8 George Billios 2006-05-08 15:21:47 EDT
There is a very big problem here which you (and by that I include all the fc
people who decided to use gnome-mount in its current state) don't seem to

As I describe in Bug 186358 there is a big issue mounting volumes with non-latin
names or even mounting ntfs removable volumes with the correct permissions. 5
years ago it was acceptable to have automounting problems in linux but today it
is not.

Evaluating if the solution will be backported to FC5 it is not good enough, we
are talking about major bug correction, not adding an extra feature. If this bug
remains for long I (and imagine much more people) will have to change FC5 for
another distro that has a working automounting system, one that respects hal
policy like pmount. 

An answer that I would like from you is the expected bug resolving time, 1
month, 2 months, FC6 ? Can you please give me that so that I see what I will do?


Comment 9 John (J5) Palmieri 2006-05-08 15:50:56 EDT
I belive we mount utf8 - as for ntfs you could change the hal script but that
gets updated every time there is an upgrade.  I will ask david about an interim
Comment 10 Luis A. Florit 2006-07-07 22:42:51 EDT
Such an OLD and HUGE bug without any solution!!
Like many others... So: Is Fedora Core DYING???

Note You need to log in before you can comment on or make changes to this bug.