From owner-freebsd-gnome@FreeBSD.ORG Mon Jan 6 19:09:02 2014 Return-Path: Delivered-To: gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E85EEFB; Mon, 6 Jan 2014 19:09:02 +0000 (UTC) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42096112B; Mon, 6 Jan 2014 19:09:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAOL+ylKtJXG+/2dsb2JhbABYgws4g1O2TYENFnSCJQEBAQQjVQEQCw4KAgIFFggDAgIJAwIBAgEPJQMBDQYNAQUCAQGHbAMRqUaVFA2EQheBKYtTGRWBZQeCb4FIBIlDgzCJOI5GA4U4g0se X-IronPort-AV: E=Sophos;i="4.95,614,1384300800"; d="scan'208";a="295575132" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jan 2014 19:09:00 +0000 Received: from dhcp-10-150-53-233.cisco.com (dhcp-10-150-53-233.cisco.com [10.150.53.233]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s06J90uh010444; Mon, 6 Jan 2014 19:09:00 GMT Message-ID: <52CAFF4C.8020408@marcuscom.com> Date: Mon, 06 Jan 2014 14:09:00 -0500 From: Joe Marcus Clarke User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: hal, ntfs, and 10.0-RC3 References: <52CAEC1E.2070908@marcuscom.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD GNOME Users X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 19:09:02 -0000 On 1/6/14, 1:55 PM, Kevin Oberman wrote: > On Mon, Jan 6, 2014 at 9:47 AM, Joe Marcus Clarke > wrote: > > On 1/6/14, 2:01 AM, Alberto Villa wrote: > > 2014/1/6 Kevin Oberman >: > >> Since I updated to 10.0-RC3 (from 9), hald no longer works with > my ntfs > >> partitions. I can mount them manually with ntfs-3g, but when not > mounted, > >> hal does not see them at all. > >> > >> Might this be fall-out of the removal of ntfs (read-only) > support? I have > >> not looked through the hald sources to see how it detects these > slices. I > >> do find it interesting that mounting one NTFS file system causes > all of the > >> other ones appear to hald. > > > > I've done some work on HAL in past months, so I have a view on the > matter. > > > > HAL uses sysctl for disks detection, so it's up to the system to list > > all the available drives. I'll try to have a look in next days, but my > > wild guess (since I've not been using ntfs-3g for years) is that > > ntfs-3g unloads its module when all mounts are removed, thus making > > the drives undetectable again. Is that correct? > > HAL uses libvolume_id to taste the volumes to determine the file system > type. It relies on sysctl to enumerate the disks and volumes as you've > pointed out. What does sysctl -b kern.geom.conftxt say? Each partition > listed there should go through libvolume_id detection. > > Joe > > > Joe, > > Looks good to me, but hald does not seem to see it: > > 0 DISK ada0 750156374016 512 hd 1 sc 63 > 1 LABEL diskid/DISK-WD-WX21A61N8718 750156374016 512 i 0 o 0 > 2 PART diskid/DISK-WD-WX21A61N8718s4 16833839104 512 i 4 o 733319528448 > ty ntfs xs MBR xt 7 > 2 PART diskid/DISK-WD-WX21A61N8718s3 241172480000 512 i 3 o 492147048448 > ty ebr xs MBR xt 15 > 3 PART diskid/DISK-WD-WX21A61N8718s5 241171431424 512 i 1 o 1048576 ty > ntfs xs MBREXT xt 7 > 2 PART diskid/DISK-WD-WX21A61N8718s2 490887708672 512 i 2 o 1259339776 > ty ntfs xs MBR xt 7 > 2 PART diskid/DISK-WD-WX21A61N8718s1 1258291200 512 i 1 o 1048576 ty > ntfs xs MBR xt 7 > 1 PART ada0s4 16833839104 512 i 4 o 733319528448 ty ntfs xs MBR xt 7 > 2 LABEL ntfs/Lenovo_Recovery 16833839104 512 i 0 o 0 > 1 PART ada0s3 241172480000 512 i 3 o 492147048448 ty ebr xs MBR xt 15 > 2 PART ada0s5 241171431424 512 i 1 o 1048576 ty ntfs xs MBREXT xt 7 > 1 PART ada0s2 490887708672 512 i 2 o 1259339776 ty ntfs xs MBR xt 7 > 2 LABEL ntfs/Windows7_OS 490887708672 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 > # lshal | grep ada0 > block.device = '/dev/ada0' (string) > freebsd.device_file = '/dev/ada0' (string) > > So hald sees the disk, but none of the partitions (slices). Could the "2 > PART ada0s5" be messing things up? The disk has only four slices (it's > MBR formatted). I think I will boot Windows and see wat it says about > the partitioning. > # gpart show ada0 > => 63 1465149105 ada0 MBR (699G) > 63 1985 - free - (993K) > 2048 2457600 1 ntfs (1.2G) > 2459648 958765056 2 ntfs (457G) > 961224704 471040000 3 ebr (225G) > 1432264704 32878592 4 ntfs (16G) > 1465143296 5872 - free - (2.9M) > Slice 1 is the weird SYSTEM_DRV, 2 is Windows7_OS, 3 is an exfat file > system named "Media", and 4 is the "Lenovo_Recovery" file system. But > geom sees a mysterious fifth one that it says is NTFS??? Still, a soon > as I mount the seconds slice, hald "sees" all of them. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com I don't suppose you have a 9.X output of the conftxt? This is one area where HAL could use an update to use confxml or the like. It's tied to the output of conftxt and thus the format of it. I have a feeling this format is different. I'll have to look over the code... Joe -- PGP Key : http://www.marcuscom.com/pgp.asc