From owner-freebsd-gnome@FreeBSD.ORG Tue Oct 17 20:53:33 2006 Return-Path: X-Original-To: gnome@freebsd.org Delivered-To: freebsd-gnome@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 698A716A403 for ; Tue, 17 Oct 2006 20:53:33 +0000 (UTC) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id A267B43D55 for ; Tue, 17 Oct 2006 20:53:32 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 3AE10F1BE6; Tue, 17 Oct 2006 13:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at mcneil.com Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0Husq9row7l; Tue, 17 Oct 2006 13:53:27 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id C4CEEF183B; Tue, 17 Oct 2006 13:53:27 -0700 (PDT) From: Sean McNeil To: Joe Marcus Clarke In-Reply-To: <1161115290.23262.58.camel@shumai.marcuscom.com> References: <1161114358.3416.7.camel@triton.mcneil.com> <1161115290.23262.58.camel@shumai.marcuscom.com> Content-Type: text/plain Date: Tue, 17 Oct 2006 13:53:27 -0700 Message-Id: <1161118407.10744.22.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: gnome@freebsd.org Subject: Re: HAL tutorial and rc.d scripts X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 20:53:33 -0000 On Tue, 2006-10-17 at 16:01 -0400, Joe Marcus Clarke wrote: > On Tue, 2006-10-17 at 12:45 -0700, Sean McNeil wrote: > > I've just managed to get my system updated to GNOME 2.16 after some > > difficulties. I understand that HAL is supported with this version, but > > I cannot find any man page for hald or any tutorial for how it is used. > > Can someone please point me in the right direction? > > There is a README installed, but in general, you just want to add > yourself to the operator group (if not already there), and start hald. > Everything else should just work. > > If you'd like to submit documentation for the FreeBSD GNOME FAQ, or add > to the README, your patches would be happily accepted. If I understood how it works, I would be glad to add patches. Perhaps you can describe what is happening to my setup and that would help my understanding: I have the following ata devices: ATA channel 0: Master: ad0 ATA/ATAPI revision 7 Slave: ad1 ATA/ATAPI revision 7 ATA channel 1: Master: acd0 ATA/ATAPI revision 6 Slave: acd1 ATA/ATAPI revision 7 ATA channel 2: Master: ad4 Serial ATA v1.0 ATA channel 3: Master: ad6 Serial ATA v1.0 ATA channel 4: Master: ad8 Serial ATA v1.0 Slave: no device present ATA channel 5: Master: ad10 Serial ATA v1.0 ad4 - My root filesystem ad0 - Part of a gmirror /dev/mirror/folka ad1 - Part of a gmirror /dev/mirror/folka and extra space as /export (glabel /dev/ufs/export) ad6 and ad8 - gmirror /dev/mirror/home ad10 - /users (glabel /dev/ufs/users) my fstab has: # Device Mountpoint FStype Options Dump Pass# /dev/ad4s1b none swap sw 0 0 /dev/ad4s1a / ufs rw 1 1 /dev/mirror/home /home ufs rw,acls 1 1 /dev/mirror/folka /folk ufs rw,acls 1 1 /dev/ufs/users /users ufs rw,acls 1 1 /dev/ufs/export /export ufs rw,acls 1 1 proc /proc procfs rw 0 0 linproc /compat/linux/proc linprocfs rw 0 0 /dev/cd0 /mnt/dvd0 udf rw,noauto 0 0 /dev/cd1 /mnt/dvd1 udf rw,noauto 0 0 /dev/cd0 /mnt/cdrom0 cd9660 rw,noauto 0 0 /dev/cd1 /mnt/cdrom1 cd9660 rw,noauto 0 0 (tried with acd* as well) My df shows: Filesystem Size Used Avail Capacity Mounted on /dev/ad4s1a 69G 21G 42G 33% / devfs 1.0K 1.0K 0B 100% /dev /dev/mirror/home 361G 83G 250G 25% /home /dev/mirror/folka 111G 60G 42G 59% /folk /dev/ufs/users 180G 128G 38G 77% /users /dev/ufs/export 73G 520M 67G 1% /export procfs 4.0K 4.0K 0B 100% /proc linprocfs 4.0K 4.0K 0B 100% /compat/linux/proc /dev/md0 124M 64K 114M 0% /tmp devfs 1.0K 1.0K 0B 100% /var/named/dev I'm guessing fstab doesn't really have anything to do with hald. In Nautilus, I now end up with a new icon on the desktop that is part of my /dev/mirror/folka. I think it's from ad1 as it must have decided since /export is on there to pull that in as well. In "Computer" from nautilus, I see: CD-RW/DVD-R Drive 114.5 GB Volume 372.6 GB Volume 372.6 GB Volume (2) export users Filesystem Network So it is obvious to me that the separate drives are showing for gmirror (which is a bug?) instead of the mirrors, but I'm puzzled about my /folk disk as it only shows one of the discs. I also only see one of my DVD drives and I can't get it to mount anything. To make everything complete, here is my /var/log/message of disc detection: Oct 17 12:30:37 triton kernel: ad0: 117245MB at ata0-m aster UDMA133 Oct 17 12:30:37 triton kernel: ad1: 194481MB at ata0-s lave UDMA133 Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device folk created (id=2225642390). Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device folk: provider ad0s1 detected . Oct 17 12:30:37 triton kernel: acd0: DVDR at ata1- master UDMA33 Oct 17 12:30:37 triton kernel: acd1: DVDR at ata 1-slave UDMA33 Oct 17 12:30:37 triton kernel: ad4: 76319MB at ata2-ma ster SATA150 Oct 17 12:30:37 triton kernel: ad6: 381554MB at a ta3-master SATA150 Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device folk: provider ad1s1 detected . Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device folk: provider ad0s1 activate d. Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device folk: provider ad1s1 activate d. Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device folk: provider mirror/folk la unched. Oct 17 12:30:37 triton kernel: GEOM_LABEL: Label for provider ad1s2 is ufs/expor t. Oct 17 12:30:37 triton kernel: ad8: 381554MB at a ta4-master SATA150 Oct 17 12:30:37 triton kernel: ad10: 190782MB at ata5-master SATA150 Oct 17 12:30:37 triton kernel: pcm0: measured ac97 link rate at 22833 Hz Oct 17 12:30:37 triton kernel: WARNING: Expected rawoffset 0, found 63 Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device home created (id=4265962958). Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device home: provider ad6 detected. Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device home: provider ad8 detected. Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device home: provider ad6 activated. Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device home: provider ad8 activated. Oct 17 12:30:37 triton kernel: GEOM_MIRROR: Device home: provider mirror/home la unched. Oct 17 12:30:37 triton kernel: GEOM_LABEL: Label for provider ad10s1 is ufs/user s. Oct 17 12:30:37 triton kernel: SMP: AP CPU #1 Launched! Oct 17 12:30:37 triton kernel: cd1 at ata1 bus 0 target 1 lun 0 Oct 17 12:30:37 triton kernel: cd1: Removable CD -ROM SCSI-0 device Oct 17 12:30:37 triton kernel: cd1: 33.000MB/s transfers Oct 17 12:30:37 triton kernel: cd1: Attempt to query device size failed: NOT REA DY, Medium not present Oct 17 12:30:37 triton kernel: cd0 at ata1 bus 0 target 0 lun 0 Oct 17 12:30:37 triton kernel: cd0: Removable CD- ROM SCSI-0 device Oct 17 12:30:37 triton kernel: cd0: 33.000MB/s transfers Oct 17 12:30:37 triton kernel: cd0: Attempt to query device size failed: NOT REA DY, Incompatible medium installed Oct 17 12:30:37 triton kernel: Trying to mount root from ufs:/dev/ad4s1a > > > > Also, I use the new format where I have separate files for each script > > (/etc/rc.conf.d) and it causes a small error message: > > > > /etc/rc: WARNING: $dbus_enable is not set properly - see rc.conf(5). > > /etc/rc: WARNING: $polkitd_enable is not set properly - see rc.conf(5). > > > > This is because polkitd and hald use checkyesno where the variables > > > > dbus_enable - in /etc/rc.conf.d/dbus > > polkitd_enable - in /etc/rc.conf.d/polkitd > > > > They don't cause a problem since the daemons are started, but the errors > > are distracting. IMHO, this is a bug in checkyesno, but is there a > > workaround (besides putting them in /etc/rc.conf)? > > Probably not. Yes, that is what I expected. Oh well. Cheers, Sean