misc/118160: unable to mount / rw while booting 7.0-BETA3

[Bruce Evans]

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

From: Bruce Evans <brde at optusnet.com.au>
To: Yuri <yuri at rawbw.com>
Cc: Bruce Evans <brde at optusnet.com.au>, Yuri <yuri at tsoft.com>,
        freebsd-gnats-submit at freebsd.org, freebsd-bugs at freebsd.org
Subject: Re: misc/118160: unable to mount / rw while booting 7.0-BETA3
Date: Wed, 28 Nov 2007 15:19:12 +1100 (EST)

 On Tue, 27 Nov 2007, Yuri wrote:
 
 >>> While booting log says:
 >>> Starting file system checks:
 >>> <here goes the list of file systems that it reports, this is ok>
 >>> mount:  : Operation not permitted.
 >>
 >> This is probably a secondary problem.  You apparently have the root device
 >> mounted on "" or something like that.
 >> What does mount shouw for the root device?
 >>
 > No, when I get to shell after this failure during the normal boot process
 > mount shows:
 > /dev/ad12s1c    /   (ufs,local,read-only)
 > swapinfo shows that swap volume is /dev/ad12s1b
 
 Using the 'c' partition is normally an error.  Here it is a very large
 error.  ad12s1b overlaps ad12s1c, so if swap on ad12s1b is actually
 used then it will normally clobber the file system on ad12s1c.  It
 might be possible to make the clobbering harmless, e.g., by putting
 ad12s1b at the end of ad12s1c and not using all of ad12s1c for the
 file system, but this is harder to configure than a normal configuration
 and is supposed to be disallowed.
 
 > ...
 > Also I found that swapon and mount are related in my case. Once swapon is done
 > I can't remount root as r/w. And vice versa, when mount -uw is done swapon
 > returns EPERM.
 >
 > This happens when I boot as single user. When I do swapon consecutive
 > 'mount -uw ' fails. When I do 'mount -uw' consecutive swapon fails.
 > So I don't have swap at all since this command failed during boot.
 
 This misbehaviour seems to be a result of the disallowment not being
 complete.  Mounted file systems normally have exclusive write access
 to their device.  However, for early root mounts, while the mount is
 only r/o, exclusive write access is given up so that fsck can work.
 There seems to be no exclusivity at all, so swapon on a different but
 overlapping device is granted write access.  Then while swapon is on,
 it holds exclusive write access and r/w mounts of root are denied
 (correctly except for the wrong errno and other misleading things in
 the error message).  Also, after the root mount becomes r/w, swapon
 fails (correctly except for the wrong errno).
 
 Bruce