From owner-freebsd-gnome@FreeBSD.ORG Mon Jan 6 18:55:57 2014 Return-Path: Delivered-To: gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2F7D991; Mon, 6 Jan 2014 18:55:56 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C17171F51; Mon, 6 Jan 2014 18:55:56 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id fa1so18828893pad.24 for ; Mon, 06 Jan 2014 10:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1DEb8c8e02MhWPvYosb5dpWugS5dWQ7N4HX9hOuPzVo=; b=ySY8Spgs3eEDHzoHMmcAehY6OuqiCfqAaOmco2e1NLAEa5+b3Pr0RI7hFzth+HtM/T E42ZoVIvLeLIe77j94e0huylvazVdPx+L4etY0x1QKQSXrUxlUXxDVICzSKCJJiD6Erx hR9URN2WckagKmxSnpvl3yzTEyJHQd4/hvF4upWHBK4/sJ3jq6YqQXlQDHtmx3LFDiJg +Cb9g7Nb1VyfHb9KqKq6PvMPAwd7957cSPTO0AKrZeGMdjNooaRU0FUPHCFvaOtZ0urz edwBp8VrmJ3idUBTqfXhfM6+UXSRAXEgvpcb3rrA4r4gO0q0GYdLzijK5C+r4KHuIzLO IX3A== MIME-Version: 1.0 X-Received: by 10.66.242.17 with SMTP id wm17mr466431pac.102.1389034556458; Mon, 06 Jan 2014 10:55:56 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.23.101 with HTTP; Mon, 6 Jan 2014 10:55:56 -0800 (PST) In-Reply-To: <52CAEC1E.2070908@marcuscom.com> References: <52CAEC1E.2070908@marcuscom.com> Date: Mon, 6 Jan 2014 10:55:56 -0800 X-Google-Sender-Auth: kZBQBmHM8WG0Tr-pqn2wvVRDGI8 Message-ID: Subject: Re: hal, ntfs, and 10.0-RC3 From: Kevin Oberman To: Joe Marcus Clarke Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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 18:55:57 -0000 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