LinuxQuestions.org - a blacklist for hal?

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - a blacklist for hal? (https://www.linuxquestions.org/questions/linux-software-2/a-blacklist-for-hal-371726/)

a blacklist for hal?

is there a way to "blacklist" a hardware device from hal? i have problems with my toshiba cdrw/dvdrw and hal, and I want to configure it to run without listening for events on this device.

Try editing /etc/fstab by puting your own entry for the device in fstab. Do so while the device is not connected or hal will autogenerate an entry for the device. If you do this properly, hal will respect your entry and not attempt to autogeneragte a fstab entry for the device when it is connected. At least that's what I've found.

Quote:

Originally posted by kilgoretrout
Try editing /etc/fstab by puting your own entry for the device in fstab. Do so while the device is not connected or hal will autogenerate an entry for the device.

thanks. the device (/dev/hdb) is my cd/dvd drive in a laptop so I hessitate to physically disconnect it. maybe i can kill hald, edit fstab, and then restart it?

is there a kernel parameter to ignore a device at boot?

thanks again!

I've only tried this trick with usb devices that were giving hal problems and it worked. I assumed your drive was one that connected through the pcmcia slot, i.e. it was removable. That type of device would normally be picked up by hal. Please post your fstab. Try something like this for hdb:

/dev/hdb <mount point> auto umask=0,user,iocharset=iso8859-1,codepage=850,noauto,ro,exec,users 0 0

Quote:

Originally posted by kilgoretrout
Please post your fstab. Try something like this for hdb:

/dev/hdb <mount point> auto umask=0,user,iocharset=iso8859-1,codepage=850,noauto,ro,exec,users 0 0

my fstab

Code:

# This file is edited by fstab-sync - see 'man fstab-sync' for details

/dev/VolGroup00/LogVol00 /                      ext3    defaults        1 1

LABEL=/boot            /boot                  ext3    defaults        1 2

/dev/devpts            /dev/pts                devpts  gid=5,mode=620  0 0

/dev/shm                /dev/shm                tmpfs  defaults        0 0

/dev/proc              /proc                  proc    defaults        0 0

/dev/sys                /sys                    sysfs  defaults        0 0

/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0

/dev/hda1              /mnt/winxp              ntfs    ro,defaults,umask=0222  0 0

/dev/hdb                /media/cdrecorder      auto    pamconsole,exec,noauto,managed 0 0

i will repace the line

Code:

/dev/hdb /media/cdrecorder auto pamconsole,exec,noauto,managed 0 0

with the line you gave in the previous post and follow up with what happened.

Thanks again!

you're right, hal won't write over that line if it there. I replaced the "managed" line for hdb with your suggestion, ran /etc/init.d/haldaemon restart and the new line remained unchanged. My problem didn't get fixed. I get the messages

Code:

Oct 11 08:19:05 oszver kernel: ATAPI device hdb:

Oct 11 08:19:05 oszver kernel:  Error: Not ready -- (Sense key=0x02)

Oct 11 08:19:05 oszver kernel:  Incompatible medium installed -- (asc=0x30, ascq=0x00)

Oct 11 08:19:05 oszver kernel:  The failed "Read Cd/Dvd Capacity" packet command was:

Oct 11 08:19:05 oszver kernel:  "25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "

every 2 seconds in /var/log/messages if my drive is empty. Killing hald is the only way I have been abble to stop these messages, but I do not _KNOW_ it's hal. These messages persist after putting your line of code in fstab, so maybe it is more complicated than hal and my cd?

There's a bugzilla report on this problem at https://bugzilla.redhat.com/bugzilla....cgi?id=167542 which is what prmpted my blacklist question.

For now, I have to keep a cd in the drive or kill hald to stop my hd from endlessly sipping to write lines to messages!

i would really like to nail this down, i have seen many posts about this problem, but no solutions!

Check out this article:

http://www.redhat.com/magazine/003ja...tures/hal/#fdi

the config files seem to be xml located somewhere in /usr/share/hal. The article will give you some overview of how hal is implemented in FC. It references some command line utilities, lshal, hal-get-property, hal-set-property, and hal-device-manager. Hal-device-manager is a gui tool and might be a good place to start. Perhaps you can reset some properties for the device there.

Quote:

Originally posted by kilgoretrout
Check out this article:
http://www.redhat.com/magazine/003ja...tures/hal/#fdi

i will, thanks for the ref!

the above article give a good crash course in how hal identifies and works with devices.
OK, I have a work around until they fix the above refrence bug.

I edited the file

Code:

/usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi

as follows. I removed the lines

Code:

 <device> 

    <match key="storage.media_check_enabled" bool="true"> 

        <append key="info.addons" type="strlist">hald-addon-storage</append> 

    </match> 

 </device>

which was at the end of my file. I'm not sure what the info.addons key does, but some experimentation with hal options indicated that that the
storage.media_check_enabled variable set to "true" is not the culprit. There could be unknown (to me) consequences as well! All I know is that the horrible
erro message is now written three times at boot, and never more! Maybe this will help someone else out too.

Glad you found a workaround. I was curious and looked into this a bit myself. Apparrently to blacklist a device, you have to create an fdi file for it somewhere in /usr/share/hal/fdi. Those are all xml files and I have no idea on how to even start doing that. Worse yet, there is very little documentation on hal or fdi configuration. The whole thing is bringing back nightmares of editing the windows registry.

thanks kilgoretrout, your reference did the trick for me. i think my solution is too severe and i am going to try an alternate:

restore the deleted lines above, and add the following to the optical drive section of the same file

Code:

<match key="storage.bus" string="ide">

      <match key="storage.model" string="TSSTcorpCD/DVDW TS-L532M">

        <match key="block.device" string="/dev/hdb">

          <merge key="storage.media_check_enabled" type="bool">false</merge>

        </match>

      </match>

</match>

this should, i think, tell hal to skip the append key action for /dev/hdb, but it will continue the append key action for other storage devices (i.e., it woun't mess with hal's hadling of usb drives, cameras etc...

i'll post a follow up if it works. the errors at boot will be gone as well, or at least that's my guess.

here's my follow up:

i prefer this new work around:

starting fesh with the "stock" file

Code:

/usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi

i added the following lines in the optical device section

Code:

<match key="storage.bus" string="ide">

        <match key="storage.model" string="TSSTcorpCD/DVDW TS-L532M">

          <match key="block.device" string="/dev/hdb">

            <merge key="storage.media_check_enabled" type="bool">false</merge>

          </match>

        </match>

      </match>

This keeps the last action read by hal:

Code:

<device>

    <match key="storage.media_check_enabled" bool="true">

      <append key="info.addons" type="strlist">hald-addon-storage</append>

    </match>

  </device>

from being applied to my cd/dvd drive. that is, "storage.media_check_enabled" bool="true" is no longer a "match". Now I am speaking out of school, but killing this append key stops my error messages without killing the same feature for cameras etc... here's some evidence that all is as I think it is from the output of lshal

Code:

udi = '/org/freedesktop/Hal/devices/storage_serial_654M401196'

  info.callouts.remove = {'fstab-sync'} (string list)

  info.callouts.add = {'hald-add-selinux-mount-option', 'fstab-sync'} (string list)

  storage.policy.desired_mount_point = 'cdrecorder'  (string)

  storage.policy.mount_filesystem = 'auto'  (string)

  storage.policy.should_mount = true  (bool)

  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_654M401196'  (string)

  info.udi = '/org/freedesktop/Hal/devices/storage_serial_654M401196'  (string)

  storage.cdrom.write_speed = 4234  (0x108a)  (int)

  storage.cdrom.read_speed = 4234  (0x108a)  (int)

  storage.cdrom.support_media_changed = true  (bool)

  storage.cdrom.dvdplusrdl = false  (bool)

  storage.cdrom.dvdplusrw = false  (bool)

  storage.cdrom.dvdplusr = false  (bool)

  storage.cdrom.dvdram = false  (bool)

  storage.cdrom.dvdrw = false  (bool)

  storage.cdrom.dvdr = true  (bool)

  storage.cdrom.dvd = true  (bool)

  storage.cdrom.cdrw = true  (bool)

  storage.cdrom.cdr = true  (bool)

  storage.firmware_version = 'HR04'  (string)

  storage.serial = '654M401196'  (string)

  storage.requires_eject = true  (bool)

  storage.hotpluggable = false  (bool)

  info.capabilities = {'storage', 'block', 'storage.cdrom'} (string list)

  info.category = 'storage'  (string)

  info.product = 'TSSTcorpCD/DVDW TS-L532M'  (string)

  storage.removable = true  (bool)

  storage.physical_device = '/org/freedesktop/Hal/devices/pci_8086_266f_ide_0_1'  (string)

  storage.drive_type = 'cdrom'  (string)

  storage.vendor = ''  (string)

  storage.model = 'TSSTcorpCD/DVDW TS-L532M'  (string)

  storage.automount_enabled_hint = true  (bool)

  storage.media_check_enabled = false  (bool)

  storage.no_partitions_hint = true  (bool)

  storage.bus = 'ide'  (string)

  block.is_volume = false  (bool)

  block.minor = 64  (0x40)  (int)

  block.major = 3  (0x3)  (int)

  block.device = '/dev/hdb'  (string)

  linux.hotplug_type = 3  (0x3)  (int)

  info.parent = '/org/freedesktop/Hal/devices/pci_8086_266f_ide_0_1'  (string)

  linux.sysfs_path_device = '/sys/block/hdb'  (string)

  linux.sysfs_path = '/sys/block/hdb'  (string)

this is my solution for now. thanks again for your help

I updated my kernel to 2.6.15-1.1830_FC4smp i686 today (with yum update kernel), and the hal problem is gone as is verified by commenting out the above code and restarting haldaemon with

Code:

/etc/init.d/haldaemon restart