From owner-freebsd-gnome@FreeBSD.ORG Tue Jan 7 00:10:16 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 741DCB7B; Tue, 7 Jan 2014 00:10:16 +0000 (UTC) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E96619E4; Tue, 7 Jan 2014 00:10:16 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id rq2so19163936pbb.31 for ; Mon, 06 Jan 2014 16:10:15 -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=A+84ElJ+gDuHuEHwwWcqIIMBvVpZp5c9x1dbbGBNUOc=; b=yLydba4Pz3heXwLwCp7OcQ0X+/X3GLMEBgy3GLRWRwahBlM8hlgCTWuWi+Q+DEG1eM xh4p3jiEqlaZEOG4kRCJleYMa7HI1FKuiGNg/BQHGP9VGUOVtwzFgEh8UrBlmmHnovOP IClpuNGUzubzzKXwpqZV3cSnKcHKg1VSeb7djapUIvyIkrt0KoNUt6owlxjpvn38G4VH 86WNR3IgK9WEaJdSdzgwNwIZqeNGtkU4+2papZP0RBhgz3HCsx9oMVfh8B1/jEXnYeRS eVbp5J4grgk58UUKUp4bOpLjkWI+ypoAwKjUmOHfvDAqxbWFQ6sVrPOTtWz+pRKEF2GL 3FHQ== MIME-Version: 1.0 X-Received: by 10.66.242.17 with SMTP id wm17mr1404658pac.102.1389053415530; Mon, 06 Jan 2014 16:10:15 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.23.101 with HTTP; Mon, 6 Jan 2014 16:10:15 -0800 (PST) In-Reply-To: References: <52CAEC1E.2070908@marcuscom.com> <52CAFF4C.8020408@marcuscom.com> <52CB38FD.4050806@marcuscom.com> Date: Mon, 6 Jan 2014 16:10:15 -0800 X-Google-Sender-Auth: xbRl1ihFwN_Sl7IMmvtrfI13wvM 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: Tue, 07 Jan 2014 00:10:16 -0000 On Mon, Jan 6, 2014 at 3:23 PM, Kevin Oberman wrote: > On Mon, Jan 6, 2014 at 3:15 PM, Joe Marcus Clarke wrote: > >> On 1/6/14, 5:50 PM, Kevin Oberman wrote: >> > >> > >> > >> > On Mon, Jan 6, 2014 at 11:09 AM, Joe Marcus Clarke < >> marcus@marcuscom.com >> > > wrote: >> > >> > 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... >> > >> > Nope. I'm afraid I blew away my 9 backup yesterday to prep to update to >> > RC4. And, to make matters worse, after re-booting, I can no longer get >> > my network to run so my system is pretty useless until I can figure out >> > what I messed up. (Also had to fix a flat on my bike. Guess it's just >> > not my day.) >> > >> > Using confxml would make a lot of sense, but it does not look like HAL >> > has much of a future. Is it used on MATE? Pretty sure that it is not on >> > Gnome3. >> >> In hf-storage.c in hald/freebsd, go to line 431. Change this "if" block >> to: >> >> if ((! strcmp(fields[1], "LABEL") || >> ! strcmp(fields[1], "BSD") || >> ! strcmp(fields[1], "PART")) && >> (! strncmp(fields[2], "ufsid/", strlen("ufsid/")) || >> ! strncmp(fields[2], "ufs/", strlen("ufs/")) >> ! strncmp(fields[2], "diskid/", strlen("diskid/")))) >> >> Rebuild hal, and see if that helps. >> >> Joe >> > > Joe, > > Shouldn't there be an OR (||) after the next to last line? (I'm going to > assume so and build that way.) > > Thanks! > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > Well, it's better. lshal does list two volumes on the disk, but not the other two. Fortunately, I don't care about the other two. Unfortunately, even though they are now listed, they don't get mounted. I see that mounting the FAT32 volume requires the "-o large" option, but using mount_ntfs mounts the other just fine. Now that I understand where the data is parsed, I'll play around a bit and see if I can figure out what's wrong. Thanks again! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com