ports/149134: x11/gnome2 unable to unmount UFS file system

[Kevin Oberman]

> Date: Sun, 29 Aug 2010 13:49:34 -0400
> From: Joe Marcus Clarke <marcus at freebsd.org>
> 
> On 8/29/10 12:57 PM, Kevin Oberman wrote:
> >> Date: Sun, 29 Aug 2010 12:22:20 -0400
> >> From: Joe Marcus Clarke <marcus at freebsd.org>
> >> Sender: owner-freebsd-gnome at freebsd.org
> >>
> >> On 8/29/10 5:29 AM, Andriy Gapon wrote:
> >>> on 29/08/2010 01:18 Joe Marcus Clarke said the following:
> >>>> On 8/28/10 4:02 PM, Andriy Gapon wrote:
> >>>>> on 28/08/2010 22:28 Joe Marcus Clarke said the following:
> >>>>>>
> >>>>>> Try http://www.marcuscom.com/downloads/patch-hald_hf-storage.c
> >>>>>
> >>>>> Just wondering aloud... Would the same strange things (mentioned in the comment
> >>>>> in the patch) happen with labels for other filesystems like msdos/ cd9660/ ?
> >>>>> Or it's something specific to UFS?
> >>>>>
> >>>>
> >>>> Yeah, it could happen for other labels, I suppose.  The problem is that
> >>>> the labels that appear dynamically depending oh whether or not a device
> >>>> is mounted confuses hal.  If someone mounts /dev/cd0, unmounts it, then
> >>>> sees /dev/cd9660/FREEBSD appear, that will cause hal to think a new
> >>>> device was inserted.
> >>>>
> >>>> That said, I've only seen this happen with UFS.
> >>>
> >>>
> >>> BTW, there seems to be an exclamation mark missing in the following part of the
> >>> patch (hope you use monospaced font):
> >>>
> >>> +	  ! strcmp(fields[1], "PART")) &&
> >>> +          ! (strncmp(fields[2], "ufsid/", strlen("ufsid/")) ||
> >>> Here----------^
> >>> +	  !  strncmp(fields[2], "ufs/", strlen("ufs/"))))
> >>>
> >>>
> >>
> >> Ugh, you're right.  When I added "ufs/" to the list, I broke the logic.
> >>  It should be fixed now.
> > 
> > That explains some of the weirdness I've been seeing.
> > 
> > I'm really embarrassed as I found the error in the patch for 2.28 and
> > fixed it (somewhat differently as I demorganized the logic and changed an
> > || to an &&) and then THOUGHT I had confirmed that the patch to 2.30
> > included my fix. Don't know how I missed it. :-( And, yes, I did post a
> > note about the broken logic back on Feb. 23.
> > 
> > "I just actually looked at the patch above and I think the problem is
> > that the second line needs to end with || and not &&. I just re-built
> > hal with this and I will give it a shot after lunch."
> > 
> > Looks like I neglected to send a confirmation that it did work, though.
> > Thanks for catching it, Andriy.
> > 
> > I can confirm that it is working, now. I suspect that the logic error
> > was really the only problem and that the two lines you added to the
> > patch are superfluous. I have not seen any indication that they cause
> > any problems, but I have not done really rigorous testing, either.
> 
> No, the other patch can help as well as it will prevent unnecessary
> churn when those other device nodes show up.  Thanks for testing.

Joe,

All testing is complete. I see only one, non-critical issue. When I
dismount a geli encrypted FS, frequently I get an error that the
directory in /media could not be deleted. I suspect that this is an race
condition cause by the geli device vanishing on the dismount. (I attach
geli devices with '-d'.)

This is a minor annoyance that I have largely resolved by adding "sudo
/bin/rmdir /media/*" to my .xinitrc. It's only a problem if I need to
re-mount the same FS during the same Gnome session.
-- 
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