Date: Sun, 24 Jul 2011 15:55:43 -0700 From: Kevin Oberman <kob6558@gmail.com> To: Joe Marcus Clarke <marcus@freebsd.org> Cc: freebsd-gnome@freebsd.org Subject: Re: HAL issues Message-ID: <CAN6yY1s=pVJitwV0HxaiNnXpBEDpobbZiRZv0COR3zrhsqV_2A@mail.gmail.com> In-Reply-To: <CAN6yY1srFGCysNj7D9Vg4xxmB9LGW3gEKfPQFUA7GmD-RavM=A@mail.gmail.com> References: <CAN6yY1v%2BQSZfjsx11NO-ZC9pYPAgCGrxsJFfP_FGA-7qrWr%2Beg@mail.gmail.com> <4E25E739.2020301@freebsd.org> <CAN6yY1vm3_fviB1KzBAGZn=akXBD6rPeEGwpeu_8OS7V4cis7w@mail.gmail.com> <4E277870.8010506@freebsd.org> <CAN6yY1srFGCysNj7D9Vg4xxmB9LGW3gEKfPQFUA7GmD-RavM=A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 20, 2011 at 10:18 PM, Kevin Oberman <kob6558@gmail.com> wrote: > On Wed, Jul 20, 2011 at 5:53 PM, Joe Marcus Clarke <marcus@freebsd.org> w= rote: >> On 7/19/11 5:22 PM, Kevin Oberman wrote: >>> On Tue, Jul 19, 2011 at 1:21 PM, Joe Marcus Clarke <marcus@freebsd.org>= 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 o= n >>>>> a regular basis. >>>>> >>>>> As of the current ports (updated yesterday), it works pretty well, bu= t >>>>> 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=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.4.0 >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dugen0.4 >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.4.1 >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dusb/0.4.2 >>>>> +ugen0.4 at port=3D2 vendor=3D0x0bc2 product=3D0x2300 devclass=3D0x00 >>>>> devsubclass=3D0x00 sernum=3D"2GH5KM5P =A0 =A0" release=3D0x0130 on ug= en0.2 >>>>> !system=3DUSB subsystem=3DDEVICE type=3DATTACH ugen=3Dugen0.4 cdev=3D= ugen0.4 >>>>> vendor=3D0x0bc2 product=3D0x2300 devclass=3D0x00 devsubclass=3D0x00 >>>>> sernum=3D"2GH5KM5P =A0 =A0" release=3D0x0130 mode=3Dhost port=3D2 par= ent=3Dugen0.2 >>>>> !system=3DUSB subsystem=3DINTERFACE type=3DATTACH ugen=3Dugen0.4 cdev= =3Dugen0.4 >>>>> vendor=3D0x0bc2 product=3D0x2300 devclass=3D0x00 devsubclass=3D0x00 >>>>> sernum=3D"2GH5KM5P =A0 =A0" release=3D0x0130 mode=3Dhost interface=3D= 0 endpoints=3D2 >>>>> intclass=3D0x08 intsubclass=3D0x06 intprotocol=3D0x50 >>>>> +umass0 vendor=3D0x0bc2 product=3D0x2300 devclass=3D0x00 devsubclass= =3D0x00 >>>>> sernum=3D"2GH5KM5P =A0 =A0" release=3D0x0130 mode=3Dhost intclass=3D0= x08 >>>>> intsubclass=3D0x06 intprotocol=3D0x50 =A0at bus=3D2 hubaddr=3D2 port= =3D0 devaddr=3D4 >>>>> interface=3D0 vendor=3D0x0bc2 product=3D0x2300 devclass=3D0x00 >>>>> devsubclass=3D0x00 sernum=3D"2GH5KM5P =A0 =A0" release=3D0x0130 mode= =3Dhost >>>>> intclass=3D0x08 intsubclass=3D0x06 intprotocol=3D0x50 =A0on uhub3 >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dpass2 >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dda0 >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dda0s1 >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dda0s2 >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dda0s3 >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dmsdosfs/MUSICBA= CKUP >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dmsdosfs/MUSIC2B= CKUP >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dda0s3.eli >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dda0s3.elid >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dufsid/4bdb229f7= dfac54e >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dufs/Auxbak >>>>> >>>>> Then I attach the geli encrypted slice and devd reports: >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dda0s3.elid >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dufsid/4bdb229f7= dfac54e >>>>> !system=3DDEVFS subsystem=3DCDEV type=3DCREATE cdev=3Dufs/Auxbak >>>>> but lshal only shows: >>>>> udi =3D '/org/freedesktop/Hal/devices/volume_size_533779542016' >>>>> =A0 block.device =3D '/dev/da0s3.eli' =A0(string) >>>>> =A0 [...] >>>>> 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 1= 3: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 1= 65 >>> 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 x= t 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 =A0 =A0 =A0Mountpoint =A0 =A0 =A0 =A0 =A0 =A0 =A0FStype =A0Opt= ions =A0 =A0 =A0 =A0 Dump =A0 =A0Pass# >>> /dev/label/swap =A0 =A0 =A0 none =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0swap =A0 =A0sw =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 >>> /dev/ufs/root / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ufs =A0 =A0= rw =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 1 >>> /dev/ufs/temp /tmp =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ufs =A0 =A0 r= w =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >>> /dev/ufs/usr =A0/usr =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ufs =A0 =A0= rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >>> /dev/ufs/var =A0/var =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ufs =A0 =A0= rw =A0 =A0 =A0 =A0 =A0 =A0 =A02 =A0 =A0 =A0 2 >>> #/dev/ad4s2 =A0 /C =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ntfs =A0 = =A0ro =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 >>> #/dev/acd0 =A0 =A0/cdrom =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cd9660 =A0r= o,noauto =A0 =A0 =A0 0 =A0 =A0 =A0 0 >>> proc =A0 =A0 =A0 =A0 =A0/proc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 procf= s =A0rw =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 >>> fdescfs =A0 =A0 =A0 =A0 =A0 =A0 =A0 /dev/fd =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 fdescfs rw =A0 =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 >>> linproc =A0 =A0 =A0 =A0 =A0 =A0 =A0 /compat/linux/proc =A0 =A0 =A0linpr= ocfs rw =A0 =A0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 0 >>> rogue> ck-list-sessions >>> Session1: >>> =A0 =A0 =A0 unix-user =3D '9381' >>> =A0 =A0 =A0 realname =3D 'Kevin Oberman' >>> =A0 =A0 =A0 seat =3D 'Seat2' >>> =A0 =A0 =A0 session-type =3D '' >>> =A0 =A0 =A0 active =3D FALSE >>> =A0 =A0 =A0 x11-display =3D ':0' >>> =A0 =A0 =A0 x11-display-device =3D '/dev/ttyv8' >>> =A0 =A0 =A0 display-device =3D 'ttyv0' >>> =A0 =A0 =A0 remote-host-name =3D '' >>> =A0 =A0 =A0 is-local =3D FALSE >>> =A0 =A0 =A0 on-since =3D '2011-07-18T23:17:23.124124Z' >>> =A0 =A0 =A0 login-session-id =3D '' >> >> 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, alth= ough > 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. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1s=pVJitwV0HxaiNnXpBEDpobbZiRZv0COR3zrhsqV_2A>