hal, ntfs, and 10.0-RC3

Joe Marcus Clarke marcus at marcuscom.com
Tue Jan 7 00:01:11 UTC 2014


On 1/6/14, 6:23 PM, Kevin Oberman wrote:
> On Mon, Jan 6, 2014 at 3:15 PM, Joe Marcus Clarke <marcus at marcuscom.com
> <mailto:marcus at marcuscom.com>> wrote:
> 
>     On 1/6/14, 5:50 PM, Kevin Oberman wrote:
>     >
>     >
>     >
>     > On Mon, Jan 6, 2014 at 11:09 AM, Joe Marcus Clarke
>     <marcus at marcuscom.com <mailto:marcus at marcuscom.com>
>     > <mailto:marcus at marcuscom.com <mailto:marcus at 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
>     >     <marcus at marcuscom.com <mailto:marcus at marcuscom.com>
>     <mailto:marcus at marcuscom.com <mailto:marcus at marcuscom.com>>
>     >     > <mailto:marcus at marcuscom.com <mailto:marcus at marcuscom.com>
>     <mailto:marcus at marcuscom.com <mailto:marcus at marcuscom.com>>>> wrote:
>     >     >
>     >     >     On 1/6/14, 2:01 AM, Alberto Villa wrote:
>     >     >     > 2014/1/6 Kevin Oberman <rkoberman at gmail.com
>     <mailto:rkoberman at gmail.com>
>     >     <mailto:rkoberman at gmail.com <mailto:rkoberman at gmail.com>>
>     >     >     <mailto:rkoberman at gmail.com <mailto:rkoberman at gmail.com>
>     <mailto:rkoberman at gmail.com <mailto:rkoberman at gmail.com>>>>:
>     >     >     >> 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 at gmail.com <mailto:rkoberman at gmail.com>
>     <mailto:rkoberman at gmail.com <mailto:rkoberman at gmail.com>>
>     >     <mailto:rkoberman at gmail.com <mailto:rkoberman at gmail.com>
>     <mailto:rkoberman at gmail.com <mailto:rkoberman at 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.)

Whoops.  Yeah, add the ||.

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc


More information about the freebsd-gnome mailing list