From owner-freebsd-gnome@FreeBSD.ORG Sun Jul 24 23:02:48 2011 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A60A1065780 for ; Sun, 24 Jul 2011 23:02:48 +0000 (UTC) (envelope-from marcus@freebsd.org) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.freebsd.org (Postfix) with ESMTP id 2CEF08FC13 for ; Sun, 24 Jul 2011 23:02:47 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6ON2lou018804; Sun, 24 Jul 2011 19:02:47 -0400 (EDT) Received: from fruit-rollup.marcuscom.com (jclarke-pc.cisco.com [172.18.254.236]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6ON2i9I015260; Sun, 24 Jul 2011 19:02:44 -0400 (EDT) Message-ID: <4E2CA494.9060202@freebsd.org> Date: Sun, 24 Jul 2011 19:02:44 -0400 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Kevin Oberman References: <4E25E739.2020301@freebsd.org> <4E277870.8010506@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-gnome@freebsd.org Subject: Re: HAL issues 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: Sun, 24 Jul 2011 23:02:48 -0000 On 7/24/11 6:55 PM, Kevin Oberman wrote: > On Wed, Jul 20, 2011 at 10:18 PM, Kevin Oberman wrote: >> On Wed, Jul 20, 2011 at 5:53 PM, Joe Marcus Clarke wrote: >>> On 7/19/11 5:22 PM, Kevin Oberman wrote: >>>> On Tue, Jul 19, 2011 at 1:21 PM, Joe Marcus Clarke wrote: >>>>> On 7/19/11 3:32 PM, Kevin Oberman wrote: >>>>>> I know HAL is probably on its last legs, but it still frustrates me on >>>>>> a regular basis. >>>>>> >>>>>> As of the current ports (updated yesterday), it works pretty well, but >>>>>> I am having a couple >>>>>> of annoying issues. One is with a filesystem that hald does not see. >>>>>> >>>>>> First is a geli encrypted UFS system that hald simply does not see. >>>>>> When I connect the >>>>>> drive, I see devd reporting: >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.4.0 >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=ugen0.4 >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.4.1 >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=usb/0.4.2 >>>>>> +ugen0.4 at port=2 vendor=0x0bc2 product=0x2300 devclass=0x00 >>>>>> devsubclass=0x00 sernum="2GH5KM5P " release=0x0130 on ugen0.2 >>>>>> !system=USB subsystem=DEVICE type=ATTACH ugen=ugen0.4 cdev=ugen0.4 >>>>>> vendor=0x0bc2 product=0x2300 devclass=0x00 devsubclass=0x00 >>>>>> sernum="2GH5KM5P " release=0x0130 mode=host port=2 parent=ugen0.2 >>>>>> !system=USB subsystem=INTERFACE type=ATTACH ugen=ugen0.4 cdev=ugen0.4 >>>>>> vendor=0x0bc2 product=0x2300 devclass=0x00 devsubclass=0x00 >>>>>> sernum="2GH5KM5P " release=0x0130 mode=host interface=0 endpoints=2 >>>>>> intclass=0x08 intsubclass=0x06 intprotocol=0x50 >>>>>> +umass0 vendor=0x0bc2 product=0x2300 devclass=0x00 devsubclass=0x00 >>>>>> sernum="2GH5KM5P " release=0x0130 mode=host intclass=0x08 >>>>>> intsubclass=0x06 intprotocol=0x50 at bus=2 hubaddr=2 port=0 devaddr=4 >>>>>> interface=0 vendor=0x0bc2 product=0x2300 devclass=0x00 >>>>>> devsubclass=0x00 sernum="2GH5KM5P " release=0x0130 mode=host >>>>>> intclass=0x08 intsubclass=0x06 intprotocol=0x50 on uhub3 >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=pass2 >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=da0 >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=da0s1 >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=da0s2 >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=da0s3 >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=msdosfs/MUSICBACKUP >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=msdosfs/MUSIC2BCKUP >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=da0s3.eli >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=da0s3.elid >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/4bdb229f7dfac54e >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=ufs/Auxbak >>>>>> >>>>>> Then I attach the geli encrypted slice and devd reports: >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=da0s3.elid >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=ufsid/4bdb229f7dfac54e >>>>>> !system=DEVFS subsystem=CDEV type=CREATE cdev=ufs/Auxbak >>>>>> but lshal only shows: >>>>>> udi = '/org/freedesktop/Hal/devices/volume_size_533779542016' >>>>>> block.device = '/dev/da0s3.eli' (string) >>>>>> [...] >>>>>> with no 'd' partition and no ufs entry. As a result, it does not get >>>>>> mounted. I can mount it >>>>>> manually fine, so there is no FS issue, I've even triggered a >>>>>> re-taste, but it still is missing. >>>>>> >>>>>> I'm probably going to have to build hald with debug to track this >>>>>> down, but I thought I'd >>>>>> ask for any suggestions of what to look for or how best to debug it. >>>>> >>>>> You need to provide the additional information documented at >>>>> http://www.freebsd.org/gnome/docs/halfaq.html#q4 . >>>> >>>> Sorry, Joe. Only the hald verbose log really looks interesting. It's >>>> attached. It >>>> sees all of the devd CREATE events, but seems to do nothing with the >>>> /dev/da0s3.elid one, though it does check on the status of the other >>>> file systems. >>>> >>>> hald was started at 13:56. At 13:57:06 I plugged in the USB drive. At 13:57:33 >>>> I attached the geli device (/dev/da0s3.eli). >>>> >>>> Here are the results of the other commands: >>>>> sysctl -b kern.geom.conftxt >>>> 0 DISK da0 750156374016 512 hd 255 sc 63 >>>> 1 PART da0s3 533779545600 512 i 3 o 216374215680 ty freebsd xs MBR xt 165 >>>> 2 ELI da0s3.eli 533779542016 4096 >>>> 3 PART da0s3.elid 533779533824 4096 i 4 o 8192 ty !0 xs BSD xt 0 >>>> 4 LABEL ufs/Auxbak 533779533824 4096 i 0 o 0 >>>> 4 LABEL ufsid/4bdb229f7dfac54e 533779533824 4096 i 0 o 0 >>>> 1 PART da0s2 136358691840 512 i 2 o 80015523840 ty !12 xs MBR xt 12 >>>> 2 LABEL msdosfs/MUSIC2BCKUP 136358691840 512 i 0 o 0 >>>> 1 PART da0s1 80015491584 512 i 1 o 32256 ty !12 xs MBR xt 12 >>>> 2 LABEL msdosfs/MUSICBACKUP 80015491584 512 i 0 o 0 >>>> 0 DISK cd0 0 2048 hd 0 sc 0 >>>> 0 DISK ada0 320072933376 512 hd 1 sc 63 >>>> 1 PART ada0s4 16777216000 512 i 4 o 303294316544 ty ntfs xs MBR xt 7 >>>> 2 LABEL ntfs/Lenovo_Recovery 16777216000 512 i 0 o 0 >>>> 1 PART ada0s3 188743661056 512 i 3 o 114550636544 ty freebsd xs MBR xt 165 >>>> 2 PART ada0s3f 177167400960 512 i 6 o 11136925696 ty freebsd-ufs xs BSD xt 7 >>>> 3 LABEL ufs/usr 177167400960 512 i 0 o 0 >>>> 2 PART ada0s3e 536870912 512 i 5 o 10600054784 ty freebsd-ufs xs BSD xt 7 >>>> 3 LABEL ufs/temp 536870912 512 i 0 o 0 >>>> 2 PART ada0s3d 5231345664 512 i 4 o 5368709120 ty freebsd-ufs xs BSD xt 7 >>>> 3 LABEL ufs/var 5231345664 512 i 0 o 0 >>>> 2 PART ada0s3b 4294967296 512 i 2 o 1073741824 ty freebsd-swap xs BSD xt 1 >>>> 3 LABEL label/swap 4294966784 512 i 0 o 0 >>>> 2 PART ada0s3a 1073741824 512 i 1 o 0 ty freebsd-ufs xs BSD xt 7 >>>> 3 LABEL ufs/root 1073741824 512 i 0 o 0 >>>> 1 PART ada0s2 113291296768 512 i 2 o 1259339776 ty ntfs xs MBR xt 7 >>>> 2 LABEL ntfs/Windows7_OS 113291296768 512 i 0 o 0 >>>> 1 PART ada0s1 1258291200 512 i 1 o 1048576 ty ntfs xs MBR xt 7 >>>> 2 LABEL ntfs/SYSTEM_DRV 1258291200 512 i 0 o 0 >>>> 0 MD md0 33927168 512 u 0 s 512 f 0 fs 0 l 33927168 t vnode file >>>> /usr/home/oberman/Desktop/Downloads/8auj09uc.iso >>>> 1 LABEL iso9660/8auj09us 33927168 512 i 0 o 0 >>>> rogue> cat /etc/fstab >>>> # Device Mountpoint FStype Options Dump Pass# >>>> /dev/label/swap none swap sw 0 0 >>>> /dev/ufs/root / ufs rw 1 1 >>>> /dev/ufs/temp /tmp ufs rw 2 2 >>>> /dev/ufs/usr /usr ufs rw 2 2 >>>> /dev/ufs/var /var ufs rw 2 2 >>>> #/dev/ad4s2 /C ntfs ro 0 0 >>>> #/dev/acd0 /cdrom cd9660 ro,noauto 0 0 >>>> proc /proc procfs rw 0 0 >>>> fdescfs /dev/fd fdescfs rw 0 0 >>>> linproc /compat/linux/proc linprocfs rw 0 0 >>>> rogue> ck-list-sessions >>>> Session1: >>>> unix-user = '9381' >>>> realname = 'Kevin Oberman' >>>> seat = 'Seat2' >>>> session-type = '' >>>> active = FALSE >>>> x11-display = ':0' >>>> x11-display-device = '/dev/ttyv8' >>>> display-device = 'ttyv0' >>>> remote-host-name = '' >>>> is-local = FALSE >>>> on-since = '2011-07-18T23:17:23.124124Z' >>>> login-session-id = '' >>> >>> Give this patch a shot. >>> >>> http://www.marcuscom.com/downloads/patch-hald_freebsd_hf-storage.c >> >> Thanks, Joe. That did it. All three file systems now mount as they should. >> Please feel free to commit. I'm sure that others have hit this, too, although >> it is a rather odd case. > > Joe, > > Looks like the commit is not right. Everything worked with the patched > hald, but after upgrading to the "latest" commit from two days ago, it > stopped working on the disk at all. It does not mount the FAT-32 > slices when I plug in the disk. > > I'll send more information shortly, but thought I'd provide a heads up > for others as well as give you a chance to see what the difference was > between what I installed and what I patched with. There are no differences. The patches are exactly the same (confirmed with md5). You may want to confirm hal is running properly. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome