Difference between revisions of "HAL"

From ArchWiki
Jump to navigation Jump to search
Line 146: Line 146:
For your changes to take effect you need to (re)start HAL:
For your changes to take effect you need to (re)start HAL:
  # /etc/rc.d/hal restart
  # /etc/rc.d/hal restart
==Deinstall HAL==
You can deinstall HAL if there are no dependencies to other packages. This is the typical case. Deinstall HAL via
  pacman -Rs hal
In the {{ic|/etc/rc.conf}} DAEMONS array remove '''HAL''' and make sure '''dbus''' is in the list. This might not be the case in old Arch installations.

Revision as of 21:11, 2 March 2012

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Template:Article summary start Template:Article summary text Template:Article summary end

Note: HAL is deprecated and has been dropped from the official repositories. Use udev/PolicyKit instead.

HAL (Hardware Abstraction Layer) is a daemon that allows desktop applications to readily access hardware information, to locate and use such hardware regardless of bus or device type. In this way a desktop GUI can present all resources to its user in a seamless and uniform manner.

HAL has become deprecated in favor of udev, udisks, upower, etc. and is no longer developed. Currently, a small number of programs still rely on and use HAL, though development is heading toward utilizing udev as a replacement.


There are a number of factors involved in 'hotplugging' and HAL is only one of them. When a new device is added, e.g. a USB drive is plugged in, the following occurs (roughly):

  • The kernel becomes aware of a new device and registers it in /sys.
  • Udev creates a device node (e.g. /dev/sdb1), and loads the drivers/modules needed.
  • The HAL daemon is notified by D-Bus and adds the device and what it can find out about it to its database.
  • The addition of the new device is broadcast by HAL over D-Bus to whatever programs are subscribing, e.g. Dolphin, which shows it as an icon in the shortcuts side panel.
  • Another program listening may be a volume manager, such as AutoFS, configured to automatically create mount points and mount certain types of drives, start Rhythmbox whenever an iPod is connected, etc.

HAL does not detect the hardware (kernel), manage the devices or the drivers (udev) or automount drives (volume managers). As a hardware abstraction layer, its role is more akin to a communications center, providing your applications with a clean interface to the devices. Problems with hot-plugged devices not being properly detected, usable, or mounted should be investigated, knowing that it is a long chain and there are more components involved (see 'Troubleshooting').

About volumes mount points

HAL-detected volumes are mounted by the volume manager under /media/some_folder. To determine what some_folder should be, the label of a volume is used. If the volume does not have a label, it uses the volume's type (eventually followed by a number if the directory already exists), for example: /media/disk, /media/disk-1 ...

To give a label to a partition you can use GParted or its KDE equivalent PartitionManager (both available in extra).

Also keep in mind these three common problems that prevent volume managers from properly mounting a device:

  • the directory /media/label_of_your_volume must not exist; it will be dynamically created and destroyed by the volume manager
  • the device must not be listed in fstab, otherwise HAL will ignore it, and it subsequently will not be mounted
  • you must have the proper permission to mount the device, see Permission Denied for more details

If for some reason you cannot give a label to your partition you can give a fake label to HAL, you will need two things to do so:

  • $device_uuid, the uuid of the device (ls -l /dev/disk/by-uuid/ may help you for that)
  • $device_name, the fake label you chose

Place this into /etc/hal/fdi/policy/20-$device_name.fdi without forgetting to replace $device_uuid and $device_name by their values.

 <?xml version="1.0" encoding="UTF-8"?>
 <deviceinfo version="0.2">
        <match key="volume.uuid" string="$device_uuid">
            <merge key="volume.label" type="string">$device_name</merge>

Install and configure HAL

Step 1: Install

It is no longer officially supported, but halAUR is still available in the AUR.

The /etc/rc.conf DAEMONS array must be configured to start HAL (and dbus) at boot. There are generally 2 methods for configuring this.

Method 1: Manually adding both

Add both dbus and hal to the array, with dbus preceding hal:

DAEMONS=(syslog-ng dbus hal network netfs ...)

This method directs dbus to be loaded before hal.

Note: Some users have reported problems with this setup. If you also experience problems try adding hal to the array only, as in 'Method 2', excluding dbus, as by default hal is directed to automatically start DBus.

Method 2: Adding HAL only

By default, HAL will automatically load dbus if it is not already running. Using this method, add hal only:

DAEMONS=(syslog-ng hal network netfs ...)
Note: Some users report that while using Method 2, dbus will not unload properly at shutdown. If you experience this issue, try adding dbus before HAL through your daemons array (Method 1).

HAL can be manually started by issuing the following command as root:

# /etc/rc.d/hald start

For D-Bus and HAL to be of any practical use, local user accounts should be members of the groups optical and storage. To achieve this, use /usr/bin/gpasswd as root:

# gpasswd -a username optical
# gpasswd -a username storage
Replace username with your actual username (e.g. johndoe).

For the group changes to take effect, the non-root account must logout and login.

Step 2: Configure

Your programs communicate with HAL controlled devices through a D-Bus interface. A number of interfaces are defined, each associated with a number of methods: The storage device interface, for example, has the methods 'eject' and 'close tray' (for optical drives). In order to 'mount' a partition on a USB key, you need access to the relevant D-Bus interface ('volume' in this case).

The configuration file /etc/dbus-1/system.d/hal.conf specifies HAL-specific privileges, i.e. which users have access to which interfaces. These are defined as exceptions to the overall restrictions imposed on using D-Bus interfaces, specified in /etc/dbus-1/system.conf. In short, you will need to see that hal.conf grants your user the right to access specific DBUS/HAL interfaces, because the D-Bus default is not to let you access them.

The default hal.conf will contain a number of policies denying and allowing access, amongst them this default (the later of two defaults and therefore seemingly the deciding one):

 <!-- Default policy for the exported interfaces -->
 <policy context="default">
   <deny send_interface="org.freedesktop.Hal.Device.SystemPowerManagement"/>
   <deny send_interface="org.freedesktop.Hal.Device.VideoAdapterPM"/>
   <deny send_interface="org.freedesktop.Hal.Device.LaptopPanel"/>
   <deny send_interface="org.freedesktop.Hal.Device.Volume"/>
   <deny send_interface="org.freedesktop.Hal.Device.Volume.Crypto"/>

In short, users are by default denied access to interfaces like Volume which has methods such as mount and unmount. This is overruled by policies allowing users of the groups 'power' and 'storage' to access their respective devices:

 <policy group="power">
   <allow send_interface="org.freedesktop.Hal.Device.SystemPowerManagement"/>
   <allow send_interface="org.freedesktop.Hal.Device.LaptopPanel"/>

 <policy group="storage">
   <allow send_interface="org.freedesktop.Hal.Device.Volume"/>
   <allow send_interface="org.freedesktop.Hal.Device.Volume.Crypto"/>

That is why you will want to add your user to those groups, thus reducing the number of customized configuration files.

Device specific policies

NTFS write access

Upon installing NTFS-3G, a HAL policy file will be created at /usr/share/hal/fdi/policy/10osvendor. This will use ntfs-3g for all NTFS volumes. Simply restart HAL, and NTFS volumes should be writeable.

Enable the noatime mount option for removable devices

This will speed up file operations and also reduce wear on flash memory devices like USB sticks or SD cards.

  <match key="block.is_volume" bool="true">
    <match key="@block.storage_device:storage.hotpluggable" bool="true">
      <merge key="volume.policy.mount_option.noatime" type="bool">true</merge>
    <match key="@block.storage_device:storage.removable" bool="true">
      <merge key="volume.policy.mount_option.noatime" type="bool">true</merge>
Disable Automount on login

You may want to disable automounting of ntfs(/or other filesystem) partitions on login.

  <match key="storage.hotpluggable" bool="false">
    <match key="storage.removable" bool="false">
      <merge key="storage.automount_enabled_hint" type="bool">false</merge>

Step 3: Start or re-start HAL

For your changes to take effect you need to (re)start HAL:

# /etc/rc.d/hal restart

Deinstall HAL

You can deinstall HAL if there are no dependencies to other packages. This is the typical case. Deinstall HAL via

 pacman -Rs hal

In the /etc/rc.conf DAEMONS array remove HAL and make sure dbus is in the list. This might not be the case in old Arch installations.


Note: for your changes to take effect you need to restart HAL with /etc/rc.d/hal restart !

Mounting fails for normal users

If you receive a Permission denied, "Unable to mount location", "Not authorized", or IsCallerPrivileged failed message when you try to mount a drive, you need to start your desktop envirornment with ck-launch-session by changing your ~/.xinitrc. Look for the line that starts your DE. For eg

# exec gnome-session 

and replace it with

# exec ck-launch-session gnome-session

or even

 # exec ck-launch-session dbus-launch gnome-session
Note: An alternative approach for solving this issue is presented in I won the struggle against hal and policykit. It also helps to correct issues with powerdown and shutdown of the system.

If you just upgraded to hal-0.5.11-7 and suddenly mounting a device stopped working for non-root users with one of these errors:

  • "PermissionDeniedByPolicy mount-removable no"
  • "PermissionDeniedByPolicy mount-removable-extra-options no"
  • "org.freedesktop.hal.storage.mount-removable no <-- (action, result)"
  • "org.freedesktop.hal.storage.mount-removable-extra-options no <-- (action, result)"

you can fix the situation by editing /etc/PolicyKit/PolicyKit.conf and paste the following into the <config> section:

        <match user="$USER">
        <!-- 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 action="hal-storage-mount-fixed-extra-options">
                <!-- for internal devices mounted with extra options like a wished mount point -->
                        <return result="yes" />
                <match action="hal-storage-mount-removable-extra-options">
                <!-- for external devices mounted with extra options like a wished mount point -->
                        <return result="yes" />
        </match> <!--  do not forget to delete this line if you deleted the first one -->

Restart dbus and hal. This was taken from Gullible Jones's "So long, Arch" thread as a hotfix for exactly this type of breakage and is probably not the best fix (especially for machines with a large number of users), but it works.

Note: make sure you type your user name like this <match user="myuser"> and NOT like <match user="$myuser">.
Alternate Fixes
  • Allowing everything (not recommended because of security constraints):
 <match user="yourusername">
     <return result="yes"/>
  • You could also:
<config version="0.1">
     <define_admin_auth user="USER"/>

Where USER is your username

This gives the user specified admin authority which is the same hal authority level used by the hal and root users:

exec ck-launch-session window-manager

Auto-mounting fails

Inserted CD/DVD does not get recognized by HAL

If inserted CDs/DVDs are not recognized by HAL (no icon on the desktop or notification), check /etc/fstab and remove the lines for the optical drives.

If that does not work, it may be because your device is not "checked" for automount by HAL. I am not sure why but you may have a file under /etc/hal/fdi/information/media-check-disable-storage_model_$YOUR_DEVICE.fdi which should have a content similar to:

 <deviceinfo version="0.2">
     <match key="info.udi" string="/org/freedesktop/Hal/devices/storage_model_DV$
       <merge key="storage.media_check_enabled" type="bool">false</merge>

First, change the value of "storage.media_check_enabled" to true, then reboot (or maybe restarting dbus and hal may work). If, after a reboot, it doesn't work, remove this file to resolve the issue.

If the file doesn't exist, use pmount to mount your device. First, check if one (or both) of these exist:

$ ls /dev/sr0; ls /dev/cdrom0

If they return /dev/sr0 or /dev/cdrom0 or both, then you should use one of these as the device. To mount, use:

$ pmount (device) (folder)

"Folder" is the name of the folder under /media (i.e, foo will mount to /media/foo). Then unmount it using

$ pumount (device)

This should end up tricking hal into making the file mentioned above, because you've started manually mounting. Now that the file's been made, edit /etc/hal/fdi/information/media-check-disable-storage_model_$YOUR_DEVICE.fdi and change false to true in it using your preferred text editor.

USB sticks and drives do not automount correctly

This sub-section is sourced from this forum page.

If you are experiencing problems with automounting USB sticks and/or drives, but do not have problems with mounting CDs or DVDs, and if you are able to manually mount the USB device in question, then you should create the file "preferences.fdi" in the folder /etc/hal/fdi/policy and paste the following line into the file

 <merge key="volume.ignore" type="bool">false</merge>

Also, if you have GParted installed, you might need to delete /usr/share/hal/fdi/policy/gparted-disable-automount.fdi as mentioned at the end of [1].

Also you should remove from /etc/fstab lines, corresponding to usb devices which should be mounted by hal automatically.

If this does not work, try adding

<match action="org.freedesktop.halstorage.mount-removable">
<return result="yes">

to the config section of /etc/PolicyKit/PolicyKit.conf (from http://bugs.archlinux.org/task/12221 ).

If this still doesn't work, follow the guidelines in [2].

If you get an error similar to: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.Hal.Device.Volume" member "Mount" error name "(unset)" destination "org.freedesktop.Hal")

Try adding:

  <policy group="storage">
    <allow send_interface="org.freedesktop.Hal.Device.Volume"/>
    <allow send_interface="org.freedesktop.Hal.Device.Volume.Crypto"/>

Also, make sure that your user is in the Storage group. If not, add it with sudo gpasswd -a your_user storage

Removing USB flash causes improper unmount

If you remove your USB flash without previously unmounting it, automatic unmount by HAL may work improperly.

You may find that corresponding records from /media/.hal-mtab is not deleted, and in nautilus device list (and also on GNOME desktop) remains link to an empty folder, where the device was previously mounted.

This may be corrected by unmounting flash drive with "lazy" parameter. To do so, you should do some tweaking:

1) Create an executable script /usr/lib/hal/hal-unmount.sh with access rights 755 and the following content

 # sanity check. DEVNAME should start with a / 
 [ "$DEVNAME" != "${DEVNAME#/}" ] || exit 0
 # Lazily unmount drives which are removed, but still mounted 
 if [ "$ACTION" = remove ] ; then
   if [ -x /usr/bin/pumount ] ; then
     /usr/bin/pumount -l "$DEVNAME";
     /bin/umount -l "$DEVNAME";
 exit 0

2) Then you should tell HAL to run this script when you remove your usb stick. To do so, you should add to /etc/udev/rules.d/90-hal.rules the following line:

 SUBSYSTEM=="block", ACTION=="remove", RUN+="/usr/lib/hal/hal-unmount.sh"

3) Execute

# /etc/rc.d/hal restart

NTFS issues

The last resort

Warning: This should only be used as a last resort 'hack' if HAL is unable to properly recognize and mount (rw) ntfs drives.

If the above policy does not work (make sure you restarted hal) you can force HAL (and all your other programs) to use the ntfs-3g driver instead of the standard ntfs driver. As root create a symbolic link from mount.ntfs to mount.ntfs-3g:

# ln -s /sbin/mount.ntfs-3g /sbin/mount.ntfs

Possible issues using this method:

  • if mount is called with the "-i" option it does not work
  • possible issues with the kernel ntfs module

Locale issues

Note: this should not happen anymore with ntfs-3g 2009.1.1 and newer.

You may have problem with filenames containing non-latin characters. This happens because your mounthelper is not parsing the policies and locale option correctly. There is a workaround for this:

  • Remove this symlink: rm /sbin/mount.ntfs-3g
  • Replace it with a new bash script containing:
 /bin/ntfs-3g $1 "$2" -o locale=en_US.UTF-8,$4  # put your own locale here
  • Make it executable: chmod +x /sbin/mount.ntfs-3g
  • Add a line to the pacman configuration file:
 NoUpgrade = sbin/mount.ntfs-3g

External links