hal, ntfs, and 10.0-RC3

[Kevin Oberman]

On Mon, Jan 6, 2014 at 9:47 AM, Joe Marcus Clarke <marcus at marcuscom.com>wrote:

> On 1/6/14, 2:01 AM, Alberto Villa wrote:
> > 2014/1/6 Kevin Oberman <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