Re: kern/52056: mount -u / causes a kernel assertion

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/52056; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/52056: mount -u / causes a kernel assertion
Date: Fri, 10 Mar 2017 19:33:32 +0700

     Date:        Fri, 10 Mar 2017 09:55:01 +0000 (UTC)
     From:        Martin Husemann <martin%duskware.de@localhost>
     Message-ID:  <20170310095501.23B457A2AA%mollari.NetBSD.org@localhost>
 
   |  (so I guess I should get rid of that old -u muscle memory and just use the
   |  former variant)
 
 Actually, this looks like a bug in mount that should be fixed (independant
 of what the kernel should, or should not, do when asked to transition from
 nolog to log while read-write.)
 
 mount(8) says ...
 
      -u      The -u flag indicates that the status of an already mounted file
              system should be changed.  Any of the options discussed above
              (the -o option) may be changed; also a file system can be changed
              from read-only to read-write or vice versa.  An attempt to change
              from read-write to read-only will fail if any files on the file
              system are currently open for writing unless the -f flag is also
              specified.  The set of options is determined by first extracting
              the options for the file system from the fstab(5) file, then
              applying any options specified by the -o argument, and finally
              applying the -r or -w option.
 
 Note:  "The set of options is determined by first extracting the options for
 the file system from the fstab(5) file, then..."   Since the "mount -u /"
 usage provides nothing else for the "then..." to catch, what should rule is
 the fstab line, which includes "log", so log should be (but clearly is not)
 set (or at least attempted to be set, and as this is a change from ro to
 rw,log it should really be able to work ... it is, or should be, the exact
 same change that happens during a normal multi-user boot with /etc/rc
 controlling everything.)
 
 kre