HAL taking over

[Kevin Oberman]

> From: Joe Marcus Clarke <marcus at marcuscom.com>
> Date: Thu, 02 Nov 2006 20:52:04 -0500
> 
> On Thu, 2006-11-02 at 14:39 -0800, Kevin Oberman wrote:
> > HAL looks wonderful, but it seems to be trying to take control of my
> > system. 
> > 
> > I have my system set up to ignore the lid switch
> > (hw.acpi.lid_switch_state: NONE)
> > 
> > When I have HALD running, it suspends my system, anyway, and it does not
> > resume. It reboots.
> 
> You will have to ignore the lid button in HAL.  Basically, create
> a /usr/local/share/hal/fdi/preprobe/20thirdparty/10-acpi-lid.fdi file
> with the following contents then restart hald:
> 
>   <?xml version="1.0" encoding="UTF-8"?>
>   <deviceinfo version="0.2"> 
>     <device> 
>       <!-- ignore ACPI lid buttons -->
>       <match key="button.type" string="lid">
>         <merge key="info.ignore" type="bool">true</merge>
>       </match>
>     </device>
>   </deviceinfo>
> 
> If that still doesn't work, HAL may need a patch to support ignoring
> these kind of events.
> 
> > 
> > When I have HALD running, I can no longer unmount disks. I can't do it
> > from the command line (volume busy) or from nautilus (Not authorized).
> 
> Which disks?  Volumes mounted by HAL can be controlled with the
> gnome-mount command provided you have appropriate access (see
> http://www.freebsd.org/gnome/docs/faq2.html#q19 ).
> 
> > 
> > I suspect HALD can be configured to make all of this work right, but I
> > don't know quite where to look. (OK, I have some hints on the unmounting
> > issue, but I have not gotten it to work yet.
> > 
> > Finally, the disks are no longer labeled in a meaningful fashion. What
> > used to be the "D" drive on my system is now showing up as "7.8 GB". Not
> > too useful and made a bit worse because I often mount two partitions of
> > almost exactly the same size.
> 
> You can label volumes using tunefs -L.  After doing this, they should
> appear with more meaningful names.

Mixed success. First, The big one...the XML for the lid worked
perfectly. I can now close the lid without suspending!

The disk labeling was a mixed bag. One partition showed up with it's
label and one did not. The third is a FAT slice, so I don't really
expect it to work (and was afraid to try). If I label it under Windows,
will that label be read by HAL?

The partition that did not show a label looks fine when I do a dumpfs on
it, so the tunefs did the trick.
> dumpfs /dev/ad2s1
magic   19540119 (UFS2) time    Mon Jul  3 11:27:14 2006
superblock location     65536   id      [ 44a8d938 cf608db3 ]
ncg     4       size    262144  blocks  253815
bsize   16384   shift   14      mask    0xffffc000
fsize   2048    shift   11      mask    0xfffff800
frag    8       shift   3       fsbtodb 2
minfree 8%      optim   time    symlinklen 120
maxbsize 16384  maxbpg  2048    maxcontig 8     contigsumsize 8
nbfree  29311   ndir    42      nifree  64765   nffree  1733
bpg     8193    fpg     65544   ipg     16448
nindir  2048    inopb   64      maxfilesize     140806241583103
sbsize  2048    cgsize  12288   csaddr  2112    cssize  2048
sblkno  40      cblkno  48      iblkno  56      dblkno  2112
cgrotor 0       fmod    0       ronly   0       clean   1
avgfpdir 64     avgfilesize 16384
flags   none
fsmnt   /
volname aux     swuid   0

If I select "Properties", nautilus crashes. (No, no dump or backtrace at
this time.)

As always, thanks for the help.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20061103/9f3cd870/attachment.pgp