hal, ntfs, and 10.0-RC3

[Joe Marcus Clarke]

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>> 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>>:
>     >> 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>

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