misc/118160: unable to mount / rw while booting 7.0-BETA3
brde at optusnet.com.au
Tue Nov 27 20:20:02 PST 2007
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).
More information about the freebsd-bugs