Problems with gnome-mount and UFS volumes

Kevin Oberman oberman at es.net
Mon Feb 22 15:59:07 UTC 2010


> From: Joe Marcus Clarke <marcus at marcuscom.com>
> Date: Mon, 22 Feb 2010 01:09:50 -0500
> 
> On Sun, 2010-02-21 at 22:04 -0800, Kevin Oberman wrote:
> > > From: Joe Marcus Clarke <marcus at marcuscom.com>
> > > Date: Sun, 21 Feb 2010 19:47:19 -0500
> > > 
> > > On Sun, 2010-02-21 at 15:54 -0800, Kevin Oberman wrote:
> > > > > From: Joe Marcus Clarke <marcus at marcuscom.com>
> > > > > Date: Sun, 21 Feb 2010 16:17:29 -0500
> > > > > 
> > > > > On Sun, 2010-02-21 at 12:56 -0800, Kevin Oberman wrote:
> > > > > 
> > > > > > The partition was auto-mounted by nautilus. The is the ufsid device was
> > > > > > mounted. I, too, thought that this should not happen, but...
> > > > > 
> > > > > What does sysctl -b kern.geom.conftxt look like before the volume is
> > > > > mounted?
> > > > 
> > > > The disk in question is da0.
> > > > 0 DISK da0 40007761920 512 hd 255 sc 63
> > > > 1 PART da0s1 40007729664 512 i 1 o 32256 ty freebsd xs MBR xt 165
> > > > 2 LABEL ufs/WindowsVB 40007729664 512 i 0 o 0
> > > > 3 PART ufs/WindowsVBd 40007729664 512 i 4 o 0 ty freebsd-ufs xs BSD xt 7
> > > > 2 LABEL ufsid/4aa57672516741c2 40007729664 512 i 0 o 0
> > > > 3 PART ufsid/4aa57672516741c2d 40007729664 512 i 4 o 0 ty freebsd-ufs xs BSD xt 7
> > > > 2 PART da0s1d 40007729664 512 i 4 o 0 ty freebsd-ufs xs BSD xt 7
> > > > 0 DISK ad2 80026361856 512 hd 16 sc 63
> > > > 1 PART ad2s1 80023233024 512 i 1 o 32256 ty !12 xs MBR xt 12
> > > > 2 LABEL msdosfs/MUSIC 80023233024 512 i 0 o 0
> > > > 0 DISK ad0 80026361856 512 hd 16 sc 63
> > > > 1 PART ad0s4 8027873280 512 i 4 o 71995875840 ty !12 xs MBR xt 12
> > > > 1 PART ad0s3 41974571520 512 i 3 o 30021304320 ty freebsd xs MBR xt 165
> > > > 2 PART ad0s3f 38259786240 512 i 6 o 3714785280 ty freebsd-ufs xs BSD xt 7
> > > > 2 PART ad0s3e 536870912 512 i 5 o 3177914368 ty freebsd-ufs xs BSD xt 7
> > > > 2 PART ad0s3d 1595932672 512 i 4 o 1581981696 ty freebsd-ufs xs BSD xt 7
> > > > 2 PART ad0s3b 1045110784 512 i 2 o 536870912 ty freebsd-swap xs BSD xt 1
> > > > 2 PART ad0s3a 536870912 512 i 1 o 0 ty freebsd-ufs xs BSD xt 7
> > > > 1 PART ad0s2 4250050560 512 i 2 o 25771253760 ty !18 xs MBR xt 18
> > > > 2 LABEL msdosfs/SERVICEV001 4250050560 512 i 0 o 0
> > > > 1 PART ad0s1 25771221504 512 i 1 o 32256 ty !7 xs MBR xt 7
> > > > 
> > > > And now, back to the next meeting!
> > > 
> > > Try this patch:
> > > 
> > > http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi/~checkout~/ports/sysutils/hal/files/patch-hald_hf-storage.c?rev=1.14&content-type=text/plain
> > 
> > I had to hand patch as almost all of that patch was already in the
> > source. Only the addition of the test for PART seemed to be different
> > from the current source.
> > 
> > The disk still re-mounted immediately, first mounting as
> > /dev/ufs/WindowsVBd and then as /dev/da0s1d. Added unmounts just keep
> > toggling between these. After the unmount of /dev/ufs/WindowsVBd, the
> > /media/Windowsvb directory is not deleted, but after unmounting
> > /dev/da0s1d, it is, so I don't keep getting the added '_'s. Never more
> > than one.
> > 
> > Since /dev/ufs/WindowsVBd is also transitory, I don't see why it is
> > different from /dev/ufsid/... Both are entries that vanish when the
> > device is mounted and appear when it is unmounted.
> 
> Okay, then that's why.  In the same general space as the addition of
> "PART", add an OR condition to the ufsid strncmp:
> 
> ! strcmp(fields[1], "PART")) &&
> (! strncmp(fields[2], "ufsid/", strlen("ufsid/")) &&
>  ! strncmp(fields[2], "ufs/", strlen("ufs/"))))
> 
> See if that helps.

Arrgh! I really thought that this would do it, but, instead it got
weird.

When I plug in the drive, it mounts /dev/da0s1d, just as I expected, but
when I unmounted the partition, it still spit out the "Unknown error"
messages and promptly re-mounted the drive using /dev/ufsid/ instance.
Looks to me like an auto-mount of either /dev/ufs or /dev/ufsid should
not happen, but it does. I guess that there must be another path???

Here is what is in the code as I have edited it:
      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/"))))
        {
          g_strfreev(fields);
          continue;
        }
Looks to me like an auto-mount of either /dev/ufs or /dev/ufsid should
not happen, but it does. I guess that there must be another path?

Any other ideas? I have never looked at the hal code, but I think I'll
try to see if I can spot anything.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


More information about the freebsd-gnome mailing list