HAL issues
Kevin Oberman
kob6558 at gmail.com
Sun Jul 24 22:55:45 UTC 2011
On Wed, Jul 20, 2011 at 10:18 PM, Kevin Oberman <kob6558 at gmail.com> wrote:
> On Wed, Jul 20, 2011 at 5:53 PM, Joe Marcus Clarke <marcus at freebsd.org> wrote:
>> On 7/19/11 5:22 PM, Kevin Oberman wrote:
>>> On Tue, Jul 19, 2011 at 1:21 PM, Joe Marcus Clarke <marcus at 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 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.
--
R. Kevin Oberman, Network Engineer - Retired
E-mail: kob6558 at gmail.com
More information about the freebsd-gnome
mailing list